emeiri/ogldev

Can't build tutorial 49

arielm opened this issue · 7 comments

arielm commented

Hello,

I'm on Ubuntu and here is what I get when I run /tutorial49/build.sh:

tutorial49.cpp: In constructor ‘Tutorial49::Tutorial49()’:
tutorial49.cpp:85:16: error: ‘class BasicMesh’ has no member named ‘GetOrientation’
   85 |         m_quad.GetOrientation().m_scale    = Vector3f(50.0f, 100.0f, 100.0f);
      |                ^~~~~~~~~~~~~~
tutorial49.cpp:86:16: error: ‘class BasicMesh’ has no member named ‘GetOrientation’
   86 |         m_quad.GetOrientation().m_pos      = Vector3f(0.0f, 0.0f, 90.0f);
      |                ^~~~~~~~~~~~~~
tutorial49.cpp:87:16: error: ‘class BasicMesh’ has no member named ‘GetOrientation’
   87 |         m_quad.GetOrientation().m_rotation = Vector3f(90.0f, 0.0f, 0.0f);
      |                ^~~~~~~~~~~~~~
tutorial49.cpp: In member function ‘bool Tutorial49::Init()’:
tutorial49.cpp:171:24: error: ‘class Camera’ has no member named ‘AddToATB’
  171 |         m_pGameCamera->AddToATB(bar);
      |                        ^~~~~~~~
tutorial49.cpp:179:20: error: ‘class DirectionalLight’ has no member named ‘AddToATB’
  179 |         m_dirLight.AddToATB(bar);
      |                    ^~~~~~~~
tutorial49.cpp: In member function ‘void Tutorial49::RenderPass()’:
tutorial49.cpp:249:25: error: ‘class BasicMesh’ has no member named ‘GetOrientation’
  249 |         p.Orient(m_quad.GetOrientation());
      |                         ^~~~~~~~~~~~~~

Strange, no?

emeiri commented

Not strange at all :-) I keep making API changes and often forget to run the script that builds all the projects.
I've just pushed a fix to the build problem. The dragons look OK but for some reason the terrain is gone. I need more time to debug it.

  • 👍1
arielm commented

Thanks!

I re-implemented tutorial 49 on Mac with my own C++/OpenGL framework and I have a question (I hope it's okay to ask here...)

I have an arcball-based camera that I use to orbit around a scene. At some point the scene starts to leave the light's visible frustum and the shadow is then badly affected (see attached screen-shot.)

Can CSM solve this problem?
CSM1

emeiri-intel commented

Is this a bug or simply a bad looking shadow? Can you please share an image just before the scene leaves the light frustum?

arielm commented

Sure... I'm also enabling cascade indicators. First image: debug-view of first shadow-map. Second image: debug-view of second shadow-map.
CSM2A
CSM2B

emeiri-intel commented

compare

Here's a comparison of the two images. The minor change on the box makes sense because the camera moved a bit. The change in the shadow map is not clear. Maybe track the changes in the shadow WVP? Possibly each component separately.

arielm commented

Thanks for your time Etay!

I think there is a misunderstanding: The two scenes are supposed to be the same (no camera movement between them...) It's just that the green box is rotating on the Y axis and that there is a little difference due to that (I took 2 separate screen-shots.)

Regarding the debug-view on the bottom-left: that is the only part that is supposed to be different between the 2 pictures. This is because I'm showing 2 different shadow maps. One for the first cascade, the other for the second cascade.

emeiri-intel commented

I forgot this was about CSMs. The following article may be useful: https://learn.microsoft.com/en-us/windows/win32/dxtecharts/common-techniques-to-improve-shadow-depth-maps. Specifically the section about tight projection. The light projection is probably missing the view frustum. I discuss this in this video: https://youtu.be/x2FHHU50ktQ.

  • 👍2