[sldev] Future plans for hierarchy / constructive solid geometry?

[Dale Mahalko]

I'm interested to know what else LL may have in the pipe for future
projects. Voice is here, Havok is in process, and Mono will probably
come after that. Are there any plans for also eventually implementing
CSG?


For CSG to really work properly, it would require a hierarchy of
stacked operations combining prims of different shapes and sizes. The
hierarchy for a single built-up shape can be quite ridiculously
complex.

It would require something more than the visual-only editing method we
must use right now, where objects can only be linked by direct
highlighting and pressing a keystroke. Individual
join/subtract/difference operations in the list would need to be
controllable from an editor window that allows editing the settings
for each object in that list.


I think there's probably a way to keep it simple, if the hierarchy is
considered to be nothing more than a list of lists, or more in line
with the SL design, representing a link-set with a GUID key, and then
making a list of GUID keys that itself has a GUID key. The client side
renderer just requests all the separate lists represented by the keys,
and internally walks the hierarchy to build up the object.

This would allow for fast loading since a person need only build a
common shape or part a single time, and then that defined shape can be
reused anywhere it is needed in other builds just by referencing the
key for it, in the same way that textures can be reused anywhere they
are needed by referencing its GUID key. A vehicle linkset with four
wheels only needs to reference the wheel linkset subkey four times,
rather than having to contain all the individual prims which build up
each separate wheel.

Allowing for overall resize, rotation and mirroring options for an
entire linkset would further enhance network loading speed since whole
linksets could be recycled in fast-loading ways. Building a robot is
simplified because only one arm and one leg needs to be constructed.
The opposite arm is simply a mirror of the original, and so only one
list needs to be downloaded from the server to represent both of them.
The same is possible for building vehicles, where only the left half
the car needs to be built and the other side is just a mirror
operation of the first linkset.


If permission controls were applied to CSG-list reuse, it might be
possible to sell individual components which other people could then
use to assemble in their own hierarchies of complex objects.

Imagine a car performance-parts store that sells custom rims that can
be individually applied to cars you buy from anyone else. Changing the
hubs and/or wheels is as simple as changing the single key
representing each of the wheels and resizing the entire wheel linkset
as a unit, to properly fit the car body.


SL already supports lists of lists of objects, but only to a very
limited extent -- avatars "wear" objects, and those attachments on the
avatar represent a one-level list of lists. Currently it is not
possible for a list of 255 linked objects to also contain a reference
to another sublist of up to 255 objects, but it could be done.

Perhaps making lists of lists might need to involve some sort of
overarching prim-count limitation, to prevent people from building a
ridiculoudly deeply nested and overly complex hierarchy that takes a
very long time for the client to assemble and render.

The current mechanisms for editing linked prim-lists are very limited
and would have to be improved to deal with adding and removing
individual keys that link to other lists. Right now, it is not
possible to open a window that directly shows the names of all
sub-objects and their ordering in a link list, or to just remove or
edit a single object in the group without having to completely unlink
and relink everything.


It seems like lists of lists might go along well with Havok 4, since
at some point if Havok is to become really useful and usable, we as
end users are going to need flexible joints to return to our builds,
and having a hierarchy of joints on a single object would be even more
useful. This just isn't going to work with the current linkset model
that cannot go more than one level deep.

- Scalar Tardis / Dale Mahalko