OpenGL Wireframe rendering (how to?)

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

Recommended Posts

I've tried a few different methods of wireframe rendering, and I can't seem to find one that works nicely, even just for debugging purposes.

Simply setting glPolygonMode causes Z-fighting like nobody's business (and as a bonus point against it, it's not OpenGLES-compatible).

In general, I've just had issues using "built-in" lines because of Z-fighting; I haven't specifically tried creating a separate "wireframe bufer" here, but at the very least, there would be a lot of duplication in the buffer (or lots and lots of calls to glDraw*).

Trying to use clever shaders and discarding fragments in the middle of triangles can work, but only the triangles that would be visible in non-wireframe are rendered, because of the depth buffer. It's also annoying because geometry shaders aren't very well-supported, either in OpenGLES or even just by my own graphics drivers.

Any other ideas out there?

Thanks!

Share on other sites

I use glPolygonMode(GL_FRONT, GL_LINE), which works perfectly without z-fighting issues. Have you tried to combine it with a pre-z-pass ?

Share on other sites

If you're rendering wireframe on top of your regular geometry, GLEQUAL depth test should be enough. ie, wireframe will be at the same depth as the existing geometry (because it IS the existing geometry), and lines will overwrite fragments with same depth. Draw it with some bright color like green, pink or yellow.

EDIT: BTW, calling glPolygonMode with GL_FRONT is deprecated. You must call it with GL_FRONT_AND_BACK, then use glCullFace to select which face will be culled.

Edited by TheChubu

Share on other sites

I use glPolygonMode(GL_FRONT, GL_LINE), which works perfectly without z-fighting issues. Have you tried to combine it with a pre-z-pass ?

Z pre-pass will probably help though. I'll try and report back.

If you're rendering wireframe on top of your regular geometry, GLEQUAL depth test should be enough. ie, wireframe will be at the same depth as the existing geometry (because it IS the existing geometry), and lines will overwrite fragments with same depth. Draw it with some bright color like green, pink or yellow.

EDIT: BTW, calling glPolygonMode with GL_FRONT is deprecated. You must call it with GL_FRONT_AND_BACK, then use glCullFace to select which face will be culled.

I'm not rendering overtop of existing geometry (because I also want to display "hidden" triangles), but I suspect this will combine nicely with the Z pre-pass mentioned above!

And thanks for the note about GL_FRONT, I was about to ask, since I get a GL_INVALID_ENUM error using GL_FRONT, and https://www.opengl.org/sdk/docs/man3/xhtml/glPolygonMode.xml says GL_FRONT_AND_BACK is the only valid value.

Edited by Ben Foppa

Share on other sites

I'm not sure, but I think a double-post is appropriate for a "report back" sort of scenario?

I changed my render function to this:

      gl::Clear(gl::COLOR_BUFFER_BIT | gl::DEPTH_BUFFER_BIT);
gl::DepthFunc(gl::LESS);
gl::PolygonMode(gl::FRONT_AND_BACK, gl::FILL);

draw();

gl::Clear(gl::COLOR_BUFFER_BIT);
gl::DepthFunc(gl::EQUAL);
gl::PolygonMode(gl::FRONT_AND_BACK, gl::LINE);

draw();


Some scattered pixels render (particularly far-away ones), but definitely not anywhere near the expected result. It's worth noting that draw() binds all the normal shaders and whatnot; I'm not sure if that might cause issues. Also, I'm pretty sure this will cause some Z-fighting still, since lines that touch one another would fight over that pixel, no? (assuming I'm not drawing them all in the same color, which I'm not - I'd like to be able to distinguish things somewhat based on their color).

Edited by Ben Foppa

Share on other sites

I'm not rendering overtop of existing geometry (because I also want to display "hidden" triangles), but I suspect this will combine nicely with the Z pre-pass mentioned above!

A z-prepass with polygon fill mode will set depth values for the entire faces. So a sub-sequent GL_EQUAL depth test will not let pass fragments of triangles behind.

EDIT: Or did you mean it plays nice with rendering some feature edges like intern ones?

BTW: In a z-prepass it is better (performace-wise) to disable rendering to color buffer(s); this also saves you the need to clear the color buffer(s) a 2nd time.

Edited by haegarr

Share on other sites

I'm not rendering overtop of existing geometry (because I also want to display "hidden" triangles)
Then just disable face culling (ie, glDisable(GL_CULL_FACE) ) and draw like regular geometry with LEQUAL depth test and GL_LINE for polygon mode. That's how my wireframe pass is set up.

Share on other sites

I'm not rendering overtop of existing geometry (because I also want to display "hidden" triangles), but I suspect this will combine nicely with the Z pre-pass mentioned above!

A z-prepass with polygon fill mode will set depth values for the entire faces. So a sub-sequent GL_EQUAL depth test will not let pass fragments of triangles behind.

EDIT: Or did you mean it plays nice with rendering some feature edges like intern ones?

BTW: In a z-prepass it is better (performace-wise) to disable rendering to color buffer(s); this also saves you the need to clear the color buffer(s) a 2nd time.

GOOD point. Clearly I didn't think that one through..

Is there a performant way to do that besides just re-writing all my shaders without outputting/calculating fragment colors? I kind of assume if I just use glColorMask, the fragment shader will still run for everything anyway..

I'm not rendering overtop of existing geometry (because I also want to display "hidden" triangles)
Then just disable face culling (ie, glDisable(GL_CULL_FACE) ) and draw like regular geometry with LEQUAL depth test and GL_LINE for polygon mode. That's how my wireframe pass is set up.

I'm still getting "flickering", which I assume is because lines that intersect will still be fighting for the same pixels. Although.. maybe it has to do with the fact that I'm rendering textures with a GL_LINE polygon mode?

Edit: Okay, it's not because of texturing.. It might have to do with the lighting though - I'm noticing the polygons with flat lighting don't seem to be flickering..

Edited by Ben Foppa

Share on other sites

Simply setting glPolygonMode causes Z-fighting like nobody's business (and as a bonus point against it, it's not OpenGLES-compatible).

Taking a rough guess, but I imagine this is because you can achieve the same effect with just shaders? (just make sure to do it after the transformations though so they affect the transformed Z value)

EDIT: er I was thinking about the function that lets you offset the Z value, sorry >_< But that idea still should work I suppose. Just modify the Z value a bit after you transform it.

Edited by Sik_the_hedgehog

Share on other sites

Simply setting glPolygonMode causes Z-fighting like nobody's business (and as a bonus point against it, it's not OpenGLES-compatible).

Taking a rough guess, but I imagine this is because you can achieve the same effect with just shaders? (just make sure to do it after the transformations though so they affect the transformed Z value)

EDIT: er I was thinking about the function that lets you offset the Z value, sorry >_< But that idea still should work I suppose. Just modify the Z value a bit after you transform it.

Modify it in what way? Won't two vertices in the same position still produce the same output Z values..?

Edited by Ben Foppa

1. 1
2. 2
Rutin
19
3. 3
4. 4
5. 5

• 9
• 9
• 9
• 14
• 12
• Forum Statistics

• Total Topics
633302
• Total Posts
3011272
• Who's Online (See full list)

There are no registered users currently online

×