Lighting behavior differences between orthographic and perspective cameras

[SherSpidey]

I'm developing a Pawn class that can switch between orthographic and perspective cameras, aiming to implement CAD-like camera controls. During development, I noticed that the lighting behavior seems incorrect when using orthographic camera mode compared to perspective mode.

The lighting appears correct when the model is at the center of the view, but the issue becomes apparent when the model moves towards the corners or edges of the viewport.

Here is an example of what I found:

Result with perspective camera:

After switching to orthographic camera:

The difference in lighting behavior between perspective and orthographic modes is quite noticeable. While the perspective view shows correct lighting, the orthographic view appears to have incorrect lighting calculations.

Questions

1. How does VSG's default shader handle view directions for lighting calculations?
2. Did I miss something to update when switching camera projection types?
3. Is there any additional camera information that needs to be passed to the shaders for proper lighting in orthographic mode?

[robertosfield]

At this point I am perplexed by what is going on. I have just tested the orthographic vsgExample and got the same odd banding result if I move the eye point in/out:

 vsgorth models/teapot.vsgt

The lighting positions are all transformed into a eye space by vsg::ViewDependentState and these are passed to the GPU as uniform. The shaders that will be used for the models/teapot.vsgt

https://github.com/vsg-dev/vsgExamples/blob/master/data/shaders/standard.vert
https://github.com/vsg-dev/vsgExamples/blob/master/data/shaders/standard_pbr.frag

The shaders are written and tested for perspective views so there must be assumptions when computing the light, eye position or angle between the light, surface and eye that is causing issues. It might be that we need to use slightly different maths to handle the oddities of the orthographic "eye" that is essentially at infinity.

I have other tasks to get on with right now so can't look further into this issue.

[SherSpidey]

Thanks Robert!

Just wanted to mention that in my pawn setup for orthographic camera, zoom works by changing the camera height and then adjusting the position based on the mouse position - there's no forward/backward movement. So zoom in/out on centered objects works fine in my case.

Even though I'm pretty new to Vulkan and VSG, I'll try to dig into this issue and see what I can find. Really appreciate you testing the vsgorth example and confirming the banding problem.

I'll take a look at those shaders you mentioned and see if I can spot where the orthographic projection might be messing things up with the lighting calculations.

Have a great day!

[SherSpidey]

Sorry for the late reply! I finally dug into it and found out it was indeed the viewDir causing all the fuss. I modified it as below, and now the lighting issues are fixed.

if(abs(pc.projection[2][3]) < 1e-6)
   viewDir = vec3(0.0, 0.0, 1.0);
else
   viewDir = - (mv * vertex).xyz;

[robertosfield]

Glad to found a fix. Once I've wrapped up my present work I'll apply something similar to the built in shaders.

FYI, uou don't need to need to load a model and then modify shaders, you can create a custom ShaderSet and pass this into the loader via vsg::Options. The vsgcustomshaderset example illustrates how this is done.

[SherSpidey]

Thanks for the heads-up. I'll check it out right away.

[robertosfield]

Knowledge of the way to customize is important.

For the particular issue with orthographic lighting, I'll update VSG + vsgExample master in this week.

[SherSpidey]

I think I finally figured out what's going on.

When importing a .vsgt model, it comes with its own built-in ShaderSet, so any preset “phong” ShaderSet I pass in just gets ignored?

For obj models, I found this in SceneConverter:

aiShadingMode shadingMode = {};
material->Get(AI_MATKEY_SHADING_MODEL, shadingMode);

bool phongShading = (shadingMode == aiShadingMode_Phong) || (shadingMode == aiShadingMode_Blinn);
bool pbrShading = (getColor(material, AI_MATKEY_BASE_COLOR, pbr.baseColorFactor) || hasPbrSpecularGlossiness);

The problem is that shadingMode defaults to 0, which is meaningless, and since OBJ/MTL doesn’t contain explicit shading model info, the material->Get() call always returns AI_FAILURE. This makes the code create a pbr shaderset instead of phong, ignoring preset "phong" shader.

That's why I ended up having to replace the shader stages after importing 😢

[AnyOldName3]

That's arguably an AssImp bug as .mtl files are explicitly using the Phong reflection model unless they contain PBR data from an unofficial extension.

[SherSpidey]

Yes, makes sense. Thanks for pointing that out.