Painters algorthium must go

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Place a cube on the screen
2. Place a plane on an angle beside the cube so that is stretchs both in 
front and behind the cube.
3. Watch the polys overlap.

What is the expected output? What do you see instead?
The cube sitting cleanly in front of the plane.

What version of the product are you using? On what operating system?
2.0.883 Vista 64 Ultimate

Please provide any additional information below.
There are ways around this and on small jobs it's not a problem. On big 
jobs the amount of time it takes to get around the problem is MASSIVE.

Original issue reported on code.google.com by d...@dev01.co.uk on 6 Apr 2010 at 11:13

[GoogleCodeExporter]

it's both a problem of polygon sorting and a native problem of 3D rendering.
plane and cube are not really plane and cube they are 6 plane*2 triangle for 
cube and
1 plane*2 triangle.

When you create a cube or plane by default you create to triangle per faces.
a 3D motor has to choose which triangle is behind or in front of each others.
depending on the angle you put the plane a triangle can sit at the same time in 
front
or behind a cube's triangle. Papervision can't never chose the correct sorting,
neither any 3D motor even if it's coded in C++.

to fix that you have too way: 
1 increase the number of triangle of your plane or cube, which can consumme a 
lot of
memory 
2 create a DAE with 3DsMax or blender that integrate the plane, and do it in the
manner that any triangle can hit each other...

The fact is that papervision is not really good a sorting triangle but first, 
your
trouble comes NOT from papervision (I have had the same) and secondly there is 
method
provided to fix sorting problem (wich will NOT solve your trouble) but it's 
processor
and memory consuming. And you have to be realist papervision is written in 
flash not
in C++ and we face limitations that NOT depend on papervision, it's a flash
limitation : Flash is interpreted.

Original comment by damien.miras on 18 May 2010 at 10:57

[GoogleCodeExporter]

Yes I know :0)

But ideally at render time you would sort the scene using something like a BSP 
tree and split the triangles 
where the intersection occurred. Then there would be no overlapping polygons.

In my particular case the whole scene is generated in code not from imported 
models. (In case you haven't 
noticed I'm the same guy with the hit detection memory leak issue - a very work 
in progress version can be 
found here: http://www.xind.co.uk/wip/ShedVis/)

For instance if two triangles went through each other then the scene would 
arbitrarily split the two triangles 
into say 9 or more depending on where the intersection occurred. Then the 
centroids would never be out of 
sequence.

I wrote a 3D engine in AS2 that used the same sorting engine that you use now. 
Lazyness prevented me from 
doing a better job :0)

The main reason for me bringing the issue up was that I've just used 
papervision for a commerical project and 
this issue has put me a month over budget. That's not your fault of course - I 
should have done better 
research on papervision before I started - I'm just saying that you're probably 
killing your own adoption rate 
because of this fundamental issue. Other than that you guys have doe a great 
job!

Original comment by d...@dev01.co.uk on 18 May 2010 at 3:39