Jump to content
  • Advertisement
Sign in to follow this  
tcorbet

OpenGL Simple (Lambert) Lighting Shader Question

This topic is 2078 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Background/Context:  I am working with the Adobe AGAL in Actionscript.  So, it would be most helpful to get an answer to my question in that frame of reference.  That said, since the available sources for solutions using that SDK are quite limited, I have spent weeks trying to answer my own question from any OpenGL, DirectX, or any other source to no avail, so I will be very grateful for facts from any domain.

 

Basic Question:  Does GPU shading of the simple, diffuse sort from a single, directional light source require the dynamic updating of face normals or not?

 

My Exasperated Experience:  Almost every Stage3D/AGAL example from helpful folks who are not using one of the recommended Adobe frameworks, just using Actionscript and AGAL, fails to answer this question.  If the example/tutorial moves from the mandatory, tri-colored triangle without lights to something dealing with the effects of light, it usually does not include any change in the triangle, cube. sphere, or whatever over time -- no translation, no rotation, no scaling.

 

So, since whatever code they demonstrate for calculating the suface and/or vector normals, will result in a static/constant value for the normal vector using the model space, I fully understand, that will yield a correct result when the light directional vector is dot multiplied [dp3] by the nornal vecotor.  So, to take a cube, even more simply, a cube with no shared vectors between the 12 triangles describing its 6 faces, I can calculate and vizualize the six different normal vector values.  Now, given a single directional light, I can visualize the angle of intersection with each of those six possible results and my code and my visual results seem to behave perfectly -- gradual reduction in the perceived illumination directly proportional to the facing angles.

 

So now, if I apply some rotation to that cube, causing some face which was previously eliminated from the shader output by backface culling, to become visible, the normal for that face, when multiplied by the light direction must yield a negative value, and that is what I should see.  Assuming I just leave enough ambiant light that the face will not be entirely black, I should see a very darkened face.  Yet, with examples I can see running, but for which, unfortunately I have no access to both the GPU and CPU code that is running, it appears as though, somehow automagiacally, the vector normals have been transformed to account for the rotation of the mesh.

 

As far as I have been able to understand, given the usual simplest vertex shader which does expressly perform some variation of an M44 to transform each vertex position to the current state of the scene, the hardware is not responsible for, and is, indeed not able to, automatically perform the required, but separate transformation of the normal for that vertex.

 

Complete Questions:

 

A.  Does the program have to provide updated vertex normals to the GPU hardware at each render cycle?

B.  Assuming that the answer is, Yes, of course somehow the normalized normal of each vector has to be sent to the GPU whenever it changes, then the question is, is it better to perform that arithmetic on the CPU side or the GPU side of the engine?

Share this post


Link to post
Share on other sites
Advertisement

Typically you would transform your normals inside the vertex shader. Let's say you have a 4x4 matrix M which represents the model-to-world transformation, a 3 component vertex position p, and a 3 component vertex normal n. Then your transformed world position is M*[p.x,p.y,p.z,1] and your transformed world normal is M*[n.x,n.y,n.z,0]. Then you perform the lighting calculations in world space (which your normals are now in, having been multiplied by M).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!