Michael Jones (mtj++at++babar)
Wed, 21 Sep 1994 21:51:44 -0700
:>>
:>> /\
:>> / \
:>> / \
:>> / \ ________ ________
:>> /\ /| / / /| / /|
:>> / \ / | / / / | / / |
:>> / \ / | / / / | / / |
:>> /______\/ | /___/___/ | /_______/ |
:>> | | | | | | | | |
:>> | | / | | / | | /
:>> | | / | | / | | /
:>> | | / | | / | | /
:>> |______|/ |______|/ |______|/
:>>
:>> high detail intermediate low detail
:>> model model model
:
:Aren't the high and intermediate detail models above identical
:topologically.
Yes, they are. The high-detail model has the mediation (linear
morph parameter) of 1.0 and the "intermediate model" has the
mediation parameter of 0.0, so for this case Performer would:
use the higher model with parameter 1.0 out to say 500m;
move the parameter from 1.0 to 0.0 over the range 500m to 1500m;
instantly switch without fade to the lower model at 1500m;
use the lower model at all greater ranges.
This is a very simple case of a much more powerful mechanism.
:Seems to me when morphing from the high detail model to
:the low detail model, you could just start with the high model, morph
:the vertices of the roof ridgeline til they match the positions shown
:in the intermediate model, then switch LOD nodes. Why would you need
:the extra intermediate model?
As you say, it's not necessary. Jim was just showing the two
extremes of interpolation as an example.
:Of course somewhere you'd need to store
:the starting (higher detail) and ending (lower detail) vertex, normal,
:color, etc. info for those attribute elements that get changed during
:morphing. But, wouldn't it depend on how many attribute elements need
:to be morphed as to whether you need a whole extra model (node), or
:just some user data stashed in shared memory? Am I missing something?
The amount of memory is fixed by the model itself in that it's possible
to have initial and final values for vertices (v0 and v1), as one way
of using the new features.
:Perhaps the "morph release" of Performer could support a partitioning
:of pfGeoset primitive attributes (for the PER_VERTEX case) into static,
:dynamic-begin, and dynamic-end sets (or, more generally, just any
:number of partitions and let the user choose which partitions to morph
:between). Then, for your example above there could be, say, 10
:vertices in the user's shared memory data (similar for normals, colors,
:etc.), and 8 indices into that data for static attributes, 2 indices
:into that data for dynamic-begin data (the high detail version), and 2
:indices into the dynamic-end data (low detail version). Performer
:could then automatically interpolate between the respective pairs of
:data for the begin/end (high/low) versions of the morphed attributes.
:Seems like this can be done in v1.2 in the CULL or DRAW callbacks if a
:user just manages his/her own index lists for dynamic attribute
:elements.
Yep. It could certainly be made to work just as you describe. ;-)
: Lew
:
:P.S. Have you thought about how to morph vertex normals when they're
: composed from face normals of static (non-morphed) tri's and tri's
: with morphed vertices, e.g., the four bottom vertices of your
: house roof (if you had a Gouraud shaded house (:-))? -- maybe just
: linearly interpolate between the starting and ending normals?
As a matter of fact, we've thought about it quite a bit. There are several
choices, of which simple interpolation is one reasonable approach. One
other extreme is to compute face normals from vertex positions after
morphing and to subsequently compute vertex normals from explicitly
indicated sets of face normals. Simple interpolation (with and without)
normalization can be made to work quite well in many cases actually
encountered in practice.
--Be seeing you, Phone:415.390.1455 Fax:415.390.2658 M/S:8U-590 Michael T. Jones Silicon Graphics, Advanced Graphics Division mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:33 PDT