Hopping flexibly to target? (feature suggestion)

Flexiprims are way cool, but we could use some additional improvements to make them really scream.

Since they are completely clientside and we don't have joints anymore, I assume it wuold be quite difficult to make prims that "attach" to the flexible end of flexyprims. (Picture the fur at the end of a feline tail, you'll understand what I mean)

Well, we have particles that can travel to a target. Why not make flexiprims that can be "attached" to another prim? They would act as if both of their ends are fixed but the body is flexible and can swing to the wind/velocity/whatever.

Both of these are good ideas, and ones that have been discussed.

1. In order to attach objects to the end of a flexible object, we need complete hierarchy. This is a separate feature which we're not currently working on, but should happen sometime in the future and which will enable attaching things to the end of flexible objects automatically.

2. Flexible objects are currently not elastic (that is, they maintain their initial length). To make both ends fixed creates a problem either with excessive elasticity or instability, and these are issues which were not in the scope of "Flexible Objects 1.0". (hint, hint)

I want this in the worst way, attaching flexies to flexies (or even non-flexies, so we can have rounded tail ends again by attaching a sphere) would result in some of the most beautiful tails. However the deeper the flexiness goes, the more calculating the client has to do. Imagine having 20 flexible fur tufts off of a longer flexible tail, with a sphere on the end. As the tail sways (smoothly I might add) all the 21 linked prims on the sides and end have to be rotated and translated to match the correct position.

But this is a cat's tail, it's meant to be a single width. What about foxes where their tails have to get thicker towards the center and then taper off at the end? That's two flexies for the tail (one on the other), and then fur tufts on both. So you have to recalculate flexies on flexies on flexies. It's doable, but I imagine it'll be computationally expensive to go too far.


Regardless of this, I would at least like LL to TRY to get this to work. Limit the amount of linked objects on a flexible object to 16 or something. ^.^

Addendum:
Oop! A Linden got in before me. ^.^;
Yeah, the hierarchy would be required too. But what confuses me is I would have thought the linking system would need to be a hierarchy.

A linkset isn't a hierarchy. Joints were an attempt to make a linkset into a hierarchy, but it wasn't well done and has been removed.

I know, I've been told in the past that linking doesn't use a hierarchy, but it's just.... I can't picture how you'd go about making and updating a linked set of objects without them all being in a hierarchial structure.

You don't. There's no "link set of objects", there's just "objects". Each object is one linkset. When you link two objects, all the information about which prims were in which object is lost... the new linkset is a flat collection of the prims from both previous linksets.

Miswording, sorry. Link set of prims. Though by definition I was right as prims are objects in their own right. More to the point, I was wondering how you can have child prims of a root prim without having them in a hierarchy.

The "parent-and-children" mindset is a bit misleading.

You could just as easily (and perhaps a bit more accurately) refer to the root prim as "The Yellow-outline Prim" and the children as "The Blue-outline Prims" (or whatever colors you want, if you customize the config files).


On a conceptual level, anything can be considered a hierarchy, even a single prim (it has a number of physical characteristics like location and color and shape, plus some hidden properties like asset id and looping sound and hovertext, plus an arbitrary content list, all of which can be considered components in a gestalt that we call "the prim", and some of which can be nested, such as a vendor that contains a box that contains a scripted vehicle).

But conceptual hierarchies are not going to help you script or build anything that you couldn't script or build already. The hierarchy has to be supported by the software.

It's just, with some thought I COULD come up with a non-hierarchial system, but my first natural thought when learning about link sets was a chain of pointers.