Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

Shader Help

This topic is 5128 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

Ok, I''m in need of some desperate shader help, using Cg, OpenGL and Visual Studio 2002, my Rendering Path looks something like this: .............................................................. gluLookAt(...); Cg(Set_CameraView_Matrix); Cg(Set_CameraView_Inverse); Cg(Set_CameraView_Inverse_Transpose); glLightfv(light_pos); Cg(Set_Light_Pos); glPushMatrix(); Rotate_Translate_Model(); Cg(Set_ModelView_Projection_Matrix); Cg(Set_ModelView_Matrix); Cg(Set_ModelView_Inverse); Cg(Set_ModelView_Inverse_Tranpose); DrawGeometry(); glPopMatrix(); .............................................................. 1) What would a Cg (or not Cg) vertex shader look like, that would correctly render the above render path? 2) What does the Inverse_Transpose do? In Cg I obtain some acurate results using Inverse, but Inverse_Transpose allways messes up the results. I know that the Inverse grabs the matrix and produces an inverse of it, and that the Transpose is suposed to be the inverse of a rotation matrix, right? When would we want to use both in the same context? 3) In the above render path, when i rotate/translate my model, im actually adding another matrix to the matrix stack, right? and in that matrix stack already lies the camera transformation, created by gluLookAt, right? So gluLooAt just grabs the parameters I pass it and constructs another matrix, which gets "pushed" onto the matrix stack, right? 4) Does Vertex data arrive at the vertex shader already transformed by the active matrix stack? In other words, when DrawGeometry() gets called, and the vertex arrives at the shader, does it arrive as (Vertex * MatrixStack) or does it arrive exactly as was defined in the DrawGeometry call? I''ve been stuck on this for quite some time now... i know i''ve got something "on backwards", but i cant put my finger on it... Any and all help would be greatly apreciated Salsa cooked it, your eyes eat it!
[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

Share this post


Link to post
Share on other sites
Advertisement
*sigh*
Thanks, but that NeHe tut doesnt use Lights or Cameras, and IIRC it doesnt even implement a lighting model...

None the less, thanks for taking the time to reply

Just hope some graphics guru sees this thread, or someone wanting to gain some major karma points... im so lost...

Salsa cooked it, your eyes eat it!
[Hugo Ferreira][Positronic Dreams][Colibri 3D Engine][Entropy HL2 MOD][My DevDiary]
[Yann L.][Enginuity] [Penny Arcade] [MSDN][VS RoadMap][Humus][BSPs][UGP][NeHe]
"our stupidity allways comes back to bite us in the ass... in a white-shark sort of way..." - Prozak

Share this post


Link to post
Share on other sites
quote:
Original post by Prozak
2) What does the Inverse_Transpose do? In Cg I obtain some acurate results using Inverse, but Inverse_Transpose allways messes up the results. I know that the Inverse grabs the matrix and produces an inverse of it, and that the Transpose is suposed to be the inverse of a rotation matrix, right? When would we want to use both in the same context?



From the name I would guess Inverse_Transpose inverts the given matrix and then transposes it from an N*M matrix to an M*N matrix (or a switch from column major to row major or the other way around, if you like)
Transpose

quote:

4) Does Vertex data arrive at the vertex shader already transformed by the active matrix stack? In other words, when DrawGeometry() gets called, and the vertex arrives at the shader, does it arrive as (Vertex * MatrixStack) or does it arrive exactly as was defined in the DrawGeometry call?



No, to transform it by the current modelview-projection matrix you have to do the work (you've replaced the fix function pipeline remember), in GLSL the function ftransform() does the job, as does setting the output to the gl_modelviewprojectionmatrix * vertex position.
So, whatever Cg stuff does that work you have to do that.

quote:

3) In the above render path, when i rotate/translate my model, im actually adding another matrix to the matrix stack, right? and in that matrix stack already lies the camera transformation, created by gluLookAt, right? So gluLooAt just grabs the parameters I pass it and constructs another matrix, which gets "pushed" onto the matrix stack, right?



Not pushed, the current modelview matrix is adjusted by your rotate/translate commands, that matrix then has to be used in the vertex program to correctly transform the incoming vertex position along with the projection matrix.
gluLookAt() works out the matrix required and multiplies that by whatever the current modelview matrix is (thus the glLoadIdentity() calls you do every loop on teh modelview matrix to reset it).

quote:

1) What would a Cg (or not Cg) vertex shader look like, that would correctly render the above render path?


(note: its early, this bit could be balls )
I think i'm correct in saying you would have to generate a matrix to represent the translation and rotation you want to do, multiply that by the modelview matrix, multiply that by the projection matrix and then multiply that by the incoming vertex data to correctly generate the output.
Infact, page 102 of the Red Book 4th Ed gives an overview of the transformation that a vertex goes though, although my ordering is different i dont think the order matters a huge deal for the first 3 steps (if it did then multiplying a vertex by the modelviewprojection matrix in glsl wouldnt work )

If anyone can see any huge holes in the above, please correct me, its early and i think i'm right but ya never know



[edited by - _the_phantom_ on May 7, 2004 3:03:10 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

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

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!