Jump to content

Polygon Offset


photo

Recommended Posts

Hello,

We are observing non-identical behavior for Polygon Offset with DirectX and OpenGL.

Test scene: just a ground plane and a Text on it at origin, at Z=0 (so coplanar with the ground). Deactivate TAA.

Set the polygon offset to 0 ("Default") on the text. With Direct X or OpenGL, the text vanishes or z-fight. Increase the polygon Offset gradually. With Direct X, higher values results in the text having a higher chance of being visible. In OpenGL, it's the contrary. The higher the value, the less the text is visible (up to never being able to see it again).

With TAA turned ON, we found that with DirectX we had to increase the Polygon Offset up to the max value to avoid all chances of z-fighting.

As our application will need to work both for OpenGL and DirectX with the same scene, is there a way to have this fixed?

And by the way, there is a typo in the combobox: it says "246" instead of "256".

Link to comment

Hello Stephane,

Current Polygon Offset realization is API and GPU dependent. Turning it to a universal solution will require time, we have this task in our schedule.

May I ask you what content you're assembling? Have you tried decals instead? Actually, decal material with alpha blend preset should grant your better result with TAA and thin lines.

Thanks.

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

I agree Decal could be a better solution but the goal is to draw a lot of (potentially dynamic) text. So the text object seems a perfect fit. We are trying to migrate an aircraft dashboard visualization tool from OSG to Unigine. The text objects would be small labels on the dashboards. Using decals would mean hand crafting a hell lot of different labels into texture. Now that I think of it, maybe Decal could use a dynamic texture generated from a Text object (best of both world!) Can this be achieved? Sample code?

Thanks!

Link to comment

Hello Stephane,

Unfortunately these textures and API for font rendering are not exposed. The task is still doable with any 3rd party software which can generate a bitmap from a text and a font. Please consider attached example using stb_truetype.

Untitled.png

AppWorldLogic.cpp

  • Like 2
Link to comment

Thanks Andrey! That's a great sample!

Performance-wise, what would be the cost of drawing a thousand decals compared to a thousand text (with a fixed polygon offset, hopefully)?

Link to comment

Hi Stephane,

I did a brief test in an empty scene with 1000 decals and 1000 text objects. For decals I used ortho projection and Alpha Blend material with 1024*1024 texture with a text sample.

Decals were faster: 3-4ms versus 7-8ms in the same scene with 1000 unique ObjectText instances. It was GTX 780, probably, on a newer GPUs the difference wouldn't be that noticeable.

As for the polygon offset - fixing will require complete rewriting of this feature. If you want to stick with poly offset I can suggest using custom logic that will switch material depending on the used API.

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

Thanks for the benchmark, that's interesting!

Switching material depending on the API would be a possibility, but the problem is not that the "scale" of the offset is different between GL/DX, the problem is that it looks like for GL the "way" of the offset is wrong (as if there is a missing or extraneous minus sign somewhere in the equation). (do I express it correctly?) so changing material would not help. As it is, GL polygon offset is useless :(   (OR: I missed something completely and needs to be corrected!)

Link to comment

With GL you should change polygon offset for the underlying material. For instance, you have a plane and text, for both Z=0.

When using DX you should increase offset for the text material, BUT for OpenGL you should change the polygon offset value for the plane.

offset.PNG

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

Indeed. Applying it to the under layer is a workaround. But in the case of our dashboard, this leads to other artifacts, as other parts poke through then. That's why I'm insisting. Are you sure you couldn't pass some negative factor to PolygonOffset instead for GL mode? Thanks again :)

Link to comment

Polygon offset depends on the GPU model and API. It works as is and we can't provide other generic solution at the moment.

I see three options:

 

How to submit a good bug report
---
FTP server for test scenes and user uploads:

Link to comment

Thanks for pointing out the shader option, we'll look into it. About using a real offset offset, we tried it but for sideway panels it kinda add a small parallax we don't want. Anyway, we have a lot of option to try now. Thanks again for the suggestions. Keep us posted if you plan to make Polygon offset evolve :)

Link to comment
×
×
  • Create New...