[osg-users] Polygon sorting

Paul Speed pspeed at progeeks.com
Wed Sep 5 21:20:39 PDT 2007

Zach Deedler wrote:
> Hi Michele,
> I had a similar problem with intersecting polygons.
> I fixed it by editing the model.  First, I broke up the polygon so that no
> polygon intersected.  This makes it so the depth sort will work for each
> polygon (ie. You don't have to depth sort pixels!).  Then, I strategically
> placed group nodes above polygons, so that the groups never overlap.  What
> this does, in affect, is really start sorting by polygon.

Just thought that I'd point out (to be pedantic) that making sure that 
the polygons don't intersect isn't enough to be sure that they sort 
properly.  It will help a lot but there could still be degenerate cases 
that don't sort right using the centroid of the triangle.

As an extreme example, imagine a triangle with the tip right about at 
your forehead and the base extending off in the distance.  Now, place a 
triangle just the other side of that one but near the top of your field 
of view.  It will sort in front even though it is behind.

These cases can come up even in closed convex figures... though in those 
cases one of them will at least be back-facing... and there are other 
ways to sort that out.

> I'm not sure if this is viable for you?  Are you dynamically intersecting
> objects?  In any case, adding more groups should improve the depth tests.
> If you can't modify the model, you could try to write a node visitor that
> inserts a group node above each polygon.  I'm not sure how difficult that
> would be, though.
> I think it would be great to add the option of polygon depth sorting to OSG,
> but I don't know what affect that would have on performance?

It would be interesting but definitely slower, I would think. 
Especially since spatial decomposition and/or bin ordering can be so 

I think all of this is why real transparency is a hard problem.  With 
limitations, you can make one or another method work well for a 
particular type of geometry but I don't think there is a good general 
solution.  At least not at this level.


> -----Original Message-----
> From: osg-users-bounces at lists.openscenegraph.org
> [mailto:osg-users-bounces at lists.openscenegraph.org] On Behalf Of Michele
> Bosi
> Sent: Wednesday, September 05, 2007 6:05 PM
> To: osg-users at lists.openscenegraph.org
> Subject: [osg-users] Polygon sorting
> Hello,
> I need to sort the polygons of my meshes in order to obtain decent
> transparencies for complex autointerstecting objects like 3d
> isosurfaces.
> I figured out that a very raw way to do so would be to subclass
> Viewer, reimplement frame(), and from there getting the viewMatrix and
> sorting my poligons based on their distance from the viewer (having
> disabled display list support for the node). The actual sorting would
> be done on the list of indices (osg::DrawElementsUInt) since I use
> indexed triangles.
> Since to get correct results I also have to take into account the
> transformation applied to my Geometry I was wondering if there was a
> more "clever" way to do all this mess, maybe there are already
> mechanisms that inform my Geometry that is going to be drawn so that I
> can react sorting my polygons appropriately at the correct moment and
> accounting for the currently active transformations, something similar
> to the VTK/pipeline system.
> Any idea?
> Regards,
> Mike
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

More information about the osg-users mailing list