`Bwana' Bob Buckley (bbuckley++at++ctaeng.com)
Thu, 11 May 1995 11:08:37 -0600
However, when multiprocessing you MUST multi-buffer your pfGeoSet data. When
updating vertex, normal, and texture coordinates in the app process you don't
want the draw process to render in the midst of an update. We just spawned a
separate rebuilding process and let the visuals continue to run typically at
60Hz.
>
> One important choice is what type of geoset you decide to use. If you use
> indexed geosets then typically each vertex is represented once in a neat
> list with connectivity information held in an index list. This reduces
> the bandwidth required to update vertices and makes for a neater
> implementation. Non indexed geosets can be slightly faster to draw
> but typically hold multiple copies of each vertex making it trickier to
> update an individual vertex.
>
When performing Continuous Terrain Level of Detail it allowed for very efficent
seamless updates. Actually very little updates and more of data movement in
memory (pfGeoSets were dynamic in their location). When dealing with the
Dynamic Terrain it made no difference due to the fact that we would build the
effected areas from scratch on the fly. The updating being done was not on a
per vertex basis but rather on a group of verticies at a time. So we kept the
non-indexed method to ensure the whole terrain surface was t-meshed and
updating was efficient and easy.
>
> Changing connectivity is a different kettle of fish and I've never needed
> to try this, clearly indexed geosets have further advantages for this type
> of dynamic update.
In my Masters Thesis we ran up against this and the chronology of how we dealt
with it is documented. Lance mentioned that it and a number of
supporting/related documents are avaialble at IST's Web Site at
http://www.vsl.ist.ucf.edu/~deg, the Digital Environments Group (DT).
>
> There's a cute SigGraph 93 paper "Modeling Soil: Realtime Dynamic Models
> for Soil Slippage and Manipulation" . I noticed that Lance Marrou got an
> acknowledgement at the end (he mails the group). Maybe he has aquired some
> 'soil specific' experience with performer.
>
I'm not so sure I'd quantify a paper of this complexity (with real-time working
model) as 'cute'. It's not the easiest thing to get a paper into SIGGRAPH nor
get your Ph.D.
We built this capability as an OOPs object and were very successful at using it
in other applications by just inserting two calls. One thing that we did not
address at the time was a blending effect when 'morphing' one terrain topology
to the next. A higher resolution soil model could have been used to smooth the
terrain transitions or a geometry morphing algorithm could have been used. I
believe that a new pfMorph type construct in Performer V2.0 is really going to
assist in Dynamic Terrain as well as a new and improved technique of dealing
with LODs in general. The Performer group might be looking at creating more
capabilities in the dynamic geometry area.
Elke, just yell if you have any questions.
===========================================================================
'Bwana' Bob Buckley CTA, Inc.
Sr. Software Engineer 5670 Greenwood Plaza Blvd
Visual Systems Englewood, CO 80111
(303) 889-1207 (303) 889-1200
bbuckley++at++ctaeng.com (303) 889-1398 Fax
===========================================================================
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:51:29 PDT