The loss of accuracy should not affect 'normal' users with terrains that are roughly square (say up to 100:1 aspect ratio) and where the Z range is comparable to the X-Y range. Retested with Pauls data, amalric's strange polygon constraint and the standard test constraints.
I also added 2 tests for routines with a NULL argument passed to them (no-one would usually pass a NULL pointer to these routines unless - as I did in testing- you remove some of the constraints but still pass their pointer to the routine). And I removed 3 tests for triangles which are already removed when generating the geometry.
NB Paul - the previous delaunay triangulator fails under VS8 IF it has any constraints as it attempts to use some vertices that have already been deleted when applying the constraints to edges. Under VS6 and less rigorous compilers it works as the deleted vertices are still in the points stl::Vector; however any added vertices would replace one of the supertriangle vertices with non-disastrous but wrong results."
Note, merged with latest name changes in CVS.
as osg::GraphicsOperation. Unpdated parts of OSG depending upon these.
Added a virtaul bool valid() method to osg::GraphicsContext to allow apps to
test whether a valid graphis context has been created or not.
Performance tests on big models did not indicate any performance penalty in using doubles over floats,
so the move to doubles should mainly impact precision improvements for whole earth databases.
Also made improvements to osgUtil::PlaneIntersector and osgSim::ElevationSlice classes
created local to RenderStage and passed on to rendering code which populated
the RenderInfo UserData, but without the restoring the new UserData to the
main RenderInfo. The local RenderInfo UserData is now passed back to the main
RenderInfo.
handle scenes with multiple views with elements that need coordinating on a per view basis.
Added beginings of new osgText::FadeText class (not functionality yet).
"I've made some changes to osg which I think make it easier to control
the render order of CameraNode's. Instead of using the built-in orders
(PRE_RENDER, POST_RENDER, NESTED_RENDER), you can specify an integer
order. Values less than zero are pre rendered in order. Values greater
than zero are post rendered in order. And a value of 0 is equivalent
to NESTED_RENDER.
The changes should be fully backward compatible. Also, I changed the
RenderStageList type from a vector to a list because I needed to be
able to insert values anywhere in the list.
The reason I made these changes was because I wanted to be able to set
the render order of a CameraNode at runtime without having to reorder
it in the scenegraph."
and later in the final submission message (relating to what has been finally been merged) :
"I've rethought my implementation and came up with something a little
better. The setRenderOrder will continue to take an enum, but will
have an optional orderNum parameter which can be both positive and
negative. I think this method is more intuitive and flexible."
