Jump to content
  • Advertisement
Sign in to follow this  
meteorstorm42

Rendering pipeline debugging (z-buffering)

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

Hi guys, I've got a software rendering pipeline programmed, but I have a few weird things happening, (and I think they're related) 1) z-buffering doesn't work - stuff gets drawn over older stuff 2) after multiplying by modelview and projection matrices, my z and w values are REALLY close, always 3) after the homogeneous divide (division by w), my z values (and w values) are all around 1, if not exactly 1 4) I think this also messes stuff up when doing perspective-correct interpolation Does that sound wrong to you guys?

Share this post


Link to post
Share on other sites
Advertisement
I think #1 and #4 are manifestations caused by #2 and #3. Are you using canned matrix/vector classes or did you make your own? Perform some unit tests on the matrices to ensure that if you transform a known point by a given view matrix that it comes out the right way. I often perform the calculation on paper just to make sure it makes sense.

The same goes for your perspective projections - these are matrices designed to produce a specific output for a given input. So test them out and see if they are giving you what you expect them to. Then once you know they are working correctly you can start implementing z-buffering and perspective correct interpolation.

Share this post


Link to post
Share on other sites
Thanks :) Yeah, I made my own classes, though I've tested my rotation, translation, ModelView, PerspectiveProjection, and MVP matrices against OpenGL's. They turned out the same for the same input. Since I multiplied matrices together in the process, my class's operator* should be working too.
I'll try working out the transformations on paper and see how that goes.

Update: Multiplying the MVP matrix times vertices is giving me the same results as my program. Weird...

[Edited by - meteorstorm42 on October 29, 2009 10:04:58 PM]

Share this post


Link to post
Share on other sites
Like you have done already make a little test rig in OpenGL and use the debugger to interrogate values.

glGetFloatv() will allow you to get different matrices from OpenGL and see what values they have. Whilst very lazy I find this a lot easier than writing out the math myself ;-)


When you say new stuff gets drawn over the old stuff on your framebuffer are you clearing it each time you call your draw method? Looking at double buffering at this point may also be helpful.

Share this post


Link to post
Share on other sites
Quote:
Original post by meteorstorm42
Thanks :) Yeah, I made my own classes, though I've tested my rotation, translation, ModelView, PerspectiveProjection, and MVP matrices against OpenGL's. They turned out the same for the same input. Since I multiplied matrices together in the process, my class's operator* should be working too.
I'll try working out the transformations on paper and see how that goes.

Update: Multiplying the MVP matrix times vertices is giving me the same results as my program. Weird...

So if your matrix classes work as intended (or at least the same as OpenGL) then the next area to work through is to see if your culling code is working properly - are the objects that you render completely on screen and within the view frustum? If so, you could look into the parameters you use to create your projection matrix and ensure that there are reasonable values in there too.

If all that works out, then what you should see after performing a WVP transformation is the w-component will contain the view space depth of the vertex. Check if this is being calculated correctly (which it probably is since you already tested it...), and if so then you can do the w-divide and move on to rasterization.

Can you describe how you do your rasterization and z-interpolation? This may be the source of your errors too - how you store them and so on. If you post screen shots it may also be helpful to diagnose what is happening.

Share this post


Link to post
Share on other sites
Quote:
Original post by Jason Z
So if your matrix classes work as intended (or at least the same as OpenGL) then the next area to work through is to see if your culling code is working properly - are the objects that you render completely on screen and within the view frustum? If so, you could look into the parameters you use to create your projection matrix and ensure that there are reasonable values in there too.

If all that works out, then what you should see after performing a WVP transformation is the w-component will contain the view space depth of the vertex. Check if this is being calculated correctly (which it probably is since you already tested it...), and if so then you can do the w-divide and move on to rasterization.

Can you describe how you do your rasterization and z-interpolation? This may be the source of your errors too - how you store them and so on. If you post screen shots it may also be helpful to diagnose what is happening.


I'm doing this for the projection matrix:
setProjectionMatrix( fovy = 45.0, aspectRatio = 1.0, zNear = 0.1, zFar = 600 );
It gives me the same matrix as glutPerspective()

Yup, all triangles that even straddle the viewable volume are culled (keeping this part simple for now...)

By WVP, did you mean MVP? I'll try doing a few more matrix multiplies in octave, see if my program's doing it correctly...

I'm using a line-walking algorithm for rasterizing. Individual triangles are drawn fine (aside from the textures not being perspective-correct), but it looks like deeper triangles are going over closer ones.
My z-buffer starts out with float_max and then I check if the incoming fragment's z is less than where I'm trying to draw it.

I just started trying to implement perspective-correct interpolation, so I'm unsure how that part of it is working, but as I was debugging it, I noticed the equal z and w values (coming into the rasterizer).

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!