Avi Bar-Zeev (cyranose++at++realityprime.com)
Mon, 15 Feb 1999 20:01:54 -0800
>Unless something has recently changed, state sorting does
>not happen across DCSs in the same bin (due, iirc, to an
>old design decision comparing the relative costs of common
>state changes vs. matrix pushes and pops).
[By the way, in case that was confusing, performer _does_
(depending on the sort mode) state sort _under_ a DCS. What
I'm saying is that the geosets under each DCS are only
sorted with each other and not from DCS to DCS. Sorting all
geosets together either requires a potentially large number
of matrix pushes and pops or requires some custom libpr-
level draw code, which is not for the faint of heart.]
In the code snipped, leaving the override on (=1) in the post
function is unnecessary unless you want to prevent anyone
else in the tree from highlighting. You can minimally get
away with turning on the override after you turn highlighting
on and turning _off_ the override _before_ you subsequently
turn highighting off.
As a related idea, if you really want to highlight a pfPath,
you can add some extra highlighting niceties. First, you can
draw connecting 3D lines from each DCS's origin to it's
parent's origin. That makes a cool 3D tree. Second, you can
draw a representation for all bounding spheres in the pfPath,
which also looks kind of cool. Since the pfDCSs and pfGroups
don't have any visuals, this makes the structure pretty
evident. I wouldn't recommend drawing these as mesh spheres,
but rather as thining circles oriented towards the camera.
Hope this helps.
Avi
This archive was generated by hypermail 2.0b2 on Mon Feb 15 1999 - 19:57:09 PST