[osg-users] Current state of osgTDS

Paul Martz pmartz at skew-matrix.com
Mon Jul 7 12:23:11 PDT 2008


> I'm directing these questions mainly at Paul Martz, but I'd 
> be interested in hearing from anyone else who has relevant experience.

Hi J-S -- I'll help as much as I can.

> Regarding building osgTDS: I saw a few posts from 2007 in the 
> archives regarding osgTDS, but there doesn't seem to be a 
> definitive answer to whether it will build for OSG 2.x and on.

Hm. It builds with 2.x. Most recently, I built it against an SVN head of
approximately mid-June.

> Regarding using it run-time: I understand osgTDS does its 
> processing at load time. Would it be hard to modify it so 
> that when we decide that an object is resting, it does the 
> processing locally for that object and updates the terrain 
> immediately? What kind of time does that processing take? 
> (say for example on a 100,000 polygon terrain, just for the 
> sake of discussion)

It's designed as a load-time deformer. In essence, there is a config file
that configures the osgTDS plugin to intercept certain files at load-time
and deform them as necessary. The deformation itself is simply a
NodeVisitor.

With some non-zero effort, osgTDS could be redesigned and reorganized so
that the NodeVisitor and its controls are exposed as a separate class,
rather than hidden inside the plugin. This would allow the NodeVisitor to be
ran against any arbitrary subgraph.

As currently implemented, the deformation would probably not be
instantaneous. The deformation uses the osgUtil: DelaunayTriangulator to
create a triangle mesh out of a cloud of points corresponding to the
newly-deformed surface, and this is a fairly sluggish operation. There's no
reason why you couldn't substitute a faster triangulator, if you have one
available. (Delaunay triangulation isn't required, it was just conveniently
available at the time osgTDS was being implemented.)

In order to avoid a frame stall during the deformation, you'd want to run
this NodeVisitor in a separate thread. To avoid a thread collision, you'd
need some type of locking or handshaking to ensure the NodeVisitor modifies
the scene graph (swaps out data/node pointers) only outside the render
traversal.

Let me know if I can assist further with your evaluation of osgTDS.
   -Paul




More information about the osg-users mailing list