Lew Hitchner (hitchner++at++netcom.com)
Tue, 20 Sep 1994 12:14:35 -0700
>> You could implement these features on top of Performer right
>> now, or wait. But in either case, if you're modeling new
>> databases, you might want to construct extra LOD models with
>> the vertex correspondence required for morph LOD, e.g. when
>> modelling a house with 2 LOD's you need an extra intermediate
>> model for the morphing:
>>
>> /\
>> / \
>> / \
>> / \ ________ ________
>> /\ /| / / /| / /|
>> / \ / | / / / | / / |
>> / \ / | / / / | / / |
>> /______\/ | /___/___/ | /_______/ |
>> | | | | | | | | |
>> | | / | | / | | /
>> | | / | | / | | /
>> | | / | | / | | /
>> |______|/ |______|/ |______|/
>>
>> high detail intermediate low detail
>> model model model
Aren't the high and intermediate detail models above identical
topologically. 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? 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?
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.
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?
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:33 PDT