Multiple PRIM Child Objects

[Zoraster Lunardi]

Are multiple prim child objects possible? Let’s say, for example, I constructed a Ferris wheel. The Base was made out of several PRIMS and the wheel was made out of several more. Can the multi prim wheel be made act as a single child object to the multi prim base? I would want to write a script to start and stop the wheel and still be able to move and rotate the entire Ferris wheel as a single Object. Is this possible?

[Honey Puddles]

no, sorry.

You can however parse every prim in a linkset and search it's name or description for the presence of a token word. Then each prim in that "group", matching that token word, can be manipulated individually

integer i;
for (i = 0; i <= llGetNumberOfPrims(); i++)
{ string data = llGetLinkName(i);
if (llSubStringIndex(data, "chair") != -1)
{ // do something to this chair prim
}}

Keep in mind also, that you can use llSay, llWhisper, llShout, and llRegionSay to communicate from one prim object to another. So for example, your base could say "wheelstart" when you click the base.. and the wheel could listen for that command, and act on it.

[Helium Loon]

Sorry, but as far as I know, any single prim can have only one prim as a parent.  Even if you were to link a bunch together as a single object, it still has a root.  If you select that object, then another prim, and link them, the root prim of the multi-prim object is the 'prim' selected in that object....and is what the other gets linked to.

 

Linking is a parent-child relationship between two prims.  Each prim can have one parent, but can have many child prims.  This allows heirarchies to be built....but one child prim cannot have two parent prims.

 

[Helium Loon]

However, rotating the 'wheel' of the build is possible.  The base could be a heirarchy of prims, with an 'axle' as the single prim that links between it and the 'wheel' prims (which would allow it to form a heirarchical chain of prims, maintaining the single-parent-to-any-number-of-children rule.

 

The script can then rotate THAT prim (requires some additional math work, since you have to calculate the rotations about the child, not the root) and the prims that are children of it will move with it as desired.

 

[PeterCanessa Oh]

---

Helium Loon wrote:

However, rotating the 'wheel' of the build is possible.  The base could be a heirarchy of prims, with an 'axle' as the single prim that links between it and the 'wheel' prims (which would allow it to form a heirarchical chain of prims, maintaining the single-parent-to-any-number-of-children rule.

 

The script can then rotate THAT prim (requires some additional math work, since you have to calculate the rotations about the child, not the root) and the prims that are children of it will move with it as desired.

 

---

Not so Helium.  All child prims in a link-set have the same, root, parent.  You cannot have a 'heirarchy of prims' - just root and children.

As Winter said, if you want to move/change only 'some' child prims you have to address them individually.  It may be possible to do that quickly enough using llSetLinkPrimitiveParamsFast() but for any realistic number of child prims there will be a visible delay between the first and last moving.

If there are fewer prims in the 'base' than the 'wheel' it may be more effective to move the whole thing and then move each base-prim back to their original position, rather than moving each wheel-prim.  The same visual delay is likely though, unfortunately.

[Helium Loon]

 

---

PeterCanessa Oh wrote:

Not so Helium.  All child prims in a link-set have the same, root, parent.  You cannot have a 'heirarchy of prims' - just root and children.

As Winter said, if you want to move/change only 'some' child prims you have to address them individually.  It

may

be possible to do that quickly enough using llSetLinkPrimitiveParamsFast() but for any realistic number of child prims there will be a visible delay between the first and last moving.

If there are fewer prims in the 'base' than the 'wheel' it may be more effective to move the whole thing and then move each base-prim back to their original position, rather than moving each wheel-prim.  The same visual delay is likely though, unfortunately.

---

 

You are absolutely right, Peter.  I stand corrected.....and somewhat dismayed.  That's a shortcut in the rendering/building pipeline that shouldn't have been taken, IMO.  Virtually all rendering engines support heirarchical linking for animation purposes......why would LL have deliberately taken a shortcut there?  The storage cost per prim?  That doesn't hold up, since link numbers (due to limits) for children don't add up to that many bytes.  Seems strange to me.  The computations for rotations?  That doesn't really hold up either, since those matrix ops have been highly optimized over the years.....I really do wonder why they did that.  The only reason I could possibly fathom was the database retrieval and parsing of objects would be simplified by having a single root with all other prims being children of that root.

 

Oh well.....means a few designs I have in my head simply won't work now.  I'll have to figure out some workarounds.....or wait for mesh to go live.

 

[Ceera Murakami]

Have the base send a message to the wheel on a non-zero channel, whenever the base is moved, and include the vector that the base was moved by, as well as any rotational changes. Then the wheel could act to move itself the same distance and rotation change. It remains as two linksets, so the wheel could still rotate on its axis. Likewise, the wheel could communicate with hanging cars on the wheel, each their own linkset, that would, as the wheel rotates, follow the rotation while remaining upright.

During the SL Kids 5th anniversary celebration, they had a ferris wheel in that sim that rotated, and that had cars that you could ride in that remained upright. Check with Marianne Mccann to find out who added that ferris wheel to the Kids5B sim displays. Those sims have been repurposed since then, but she can probably lead you to the person who built it.

[Void Singer]

Despite the fact that there is no hierarchical linking in objects, it can be faked.... but requires a script for each part that is not "parented" to the root. for smootheness (athough for non-smooth updates you might get away with  a script for each subset... a single script could do it very blockily)

an example of how that might work can be found here courtesy of Nexii Malthus.

[Fenix Eldritch]

A good point to remember is that in SL, real physics don't apply. In this case, consider that you don't have to link the ferris wheel to the base, nor the gondolas to the wheel. They could all be free floating (non-physical) with scripts in each object to non-physically reposition them relative the the wheel's rotation.

However... you could also consider creating each sub-object (base, wheel, gondolas) out of sculpted prims (or mesh when they are implemented). With each element being one prim, you could link them all together. Though I believe each gondola would need a script to control sit positions.