BSP and creen dust

Hi All,

Please give a look to the following picture:

Do you see the pixels of different color (lighter)?

This is the result of the BSP partitioning that need to split the scene for correct sorting.

Is there any trick to reduce this visual defect?

Thanks,

Alberto

Can you post same image with wireframe on top?

As you expected there are many “T” vertices but it is difficult to avoid them with BSP.

Thanks,

Alberto

The problem is, that you loose precision when you split your polygons.

I think one solution would be to reuse the same vertex (on the GPU) for polygons that have been split. So if you split polygon A into B and C then B and C will share two vertices at their split-border. If you then render B and C, both should index the same vertex in the vertex-buffer array. Because when you use the exact same vertex then two adjacent polygons should not produce such missing pixels.

Jan.

PS: Well, T-vertices are of course a bigger problem. Hm, no idea right now.

Hi Jan,

Unfortunately we are not using vertex-buffer array here but simply passing triangles with their own vertices.

By the way I am not sure that “T” vertices would render correctly even doing as you suggested.

What do you think?

Thanks,

Alberto

You must avoid T-junctions in geometry.

``````
A
*
/ \
/   \
/     \
/   T   \
B*----+----*D
\   |   /
\  |  /
\ | /
\|/
*
C

``````

Here is 3 faces… ABD, BCT, TCD. T lies between B and D. Due rasterization errors, when rasterizer process BD line in first triangle, mid point in line BD will not be exactly equal to vertex T. You have to split ABD in two faces using additional vertex T.
It is not too difficult to detect and remove T junctions…
http://www.flipcode.com/archives/Merging_Polygons_And_Sub-Pixel_Gaps.shtml
http://www.cs.miami.edu/~visser/home_page/CSC_329_files/BSPTrees.pdf

Two really nice docs Yooyo, just printed and ready to be read bofore sleeping this evening!

Still skeptical on the speed of fixing T junctions BTW.

Thanks,

Alberto

Well… dont remove them… do not generate them.

Do you believe it can be faster avoiding to generate them?

We collect triangles (cloning them) within our scene from totally different objects. When we process the split for a triangle we can only know the owner, nothing else. This is the reason why I am so skeptical to find a reasonable fast approach.

BTW I still need to read carefully the docs you suggested.

Thanks,

Alberto