Polygon Offset Sucks

[mh]

Another thing to not do:

• The spec allows it to be implementation-dependent (clicky) so the same values may give different results on different hardware.
• You may encounter floating point precision problems when moving between 16-bit and 24-bit depth buffers.
• The depth buffer is non-linear so the same values will give different results at different depths.

[Sajt]

I know, right. #3 ruined it for me.

[Spike]

hence why its not supported in the minimal gl3 spec.

[andrewj]

How do you do decals or multi-pass rendering on older cards without polygon offset?

It may be a crappy tool, but the alternatives (glDepthRange or adjusting the coordinates of polygons directly) seem a lot worse.

[leileilol]

you don't. you don't wanna make this guy angry


look at those eyes don't piss him off






or you can use stainmaps for decals which really suck for bullets and really obstruct appearances of floors. i'm glad that was only a short time novelty but it doesn't need polygon offset as it just touches the lightmap


also - could decals be rendered in a separate pass from the world which is calculated by z after the render to peel away from the obstructed decals but the rendering of the decals themselves don't use an offset but a depth check after they're made while calculating an offset?!! i don't know what the hell i'm saying

[r00k]

His face is red because the card runs HOT without a cooling fan

[revelator]

got an ol vectra with twice the angry sli even.

[leileilol]

see? when you spend over $600 on the real deal, the slug RIVAl and pathATIc hardware are just small time. The ultra performance blazing at 1024x768 HIGH RESOLUTION with T-buffer and more game companies adopting Glide as the new industry standard... is why you should invest in TDFX today

[mh]

Multipass is easy, GLQuake, Quake II and Q3A already do it without needing to use polygon offset and without any trouble (look at R_BlendLightmaps for example). Invariance guarantees that this will work just fine. The only trouble happens when you have co-planar polygons that don't use the same vertexes.

For decals you can just tweak the projection matrix to get the desired result. Even Microsoft's software implementation will allow that. A quick search on Google for "polygon offset alternatives" throws up quite a few interesting candidates too.

[Spike]

Q3's clipped decals use polygon offset. Its a shader attribute to say 'push this nearer'.

But yeah, two polys drawn with the same vertex coords will have the exact same depth coords (different glsl/fixed-function might not!), which is how q3 gets away with the bulk of its multipass rendering.

Thus one way to do clipped decals is to use texture clamping and draw the decal the full size of each surface its superimposed upon (minecraft seems to do its blob shadows like this, for example).
Note that you do have to take care with your matricies. glLoadMatrix is more robust than recalculating the different matricies each time, I find...

[mh]

ftransform guarantees invariance, but then again ftransform is also deprecated. (It might also be slower as it sends the vertex through the same calculations as fixed, which presumably has a lot of extra generic baggage attached.) Still handy though if you're happy to aim at a lower version of the spec.

If you're using GLSL at all I guess you really should be using it for everything.

[Spike]

anything that 'supports' a deprecated ftransform doesn't have a fixed-function pipeline any more, so it'll match if your maths matches anyway, at least that's the theory. So long as you're using the same matricies.

[Sajt]

Yeah ftransform and fixed-function pipeline are deprecated together.

Thus one way to do clipped decals is to use texture clamping and draw the decal the full size of each surface its superimposed upon

OK I will do this from now on. Duhh.

[andrewj]

OK I will do this from now on. Duhh.

My reaction too -- so obvious now