Particles, child prims, and attachment from Inventory vs from rez'd-in-world

Would appreciate a sanity check before I post a jira about this. Here's what seems to be happening. If a particle system targets a child prim of an object, and that object is attached either by directly "Wearing" it from its rezzed state or by llAttachToAvatar, the particles seem to target a point relative to the avatar's origin (basically, the crotch), rather than relative to the attachment point where the child prim actually appears. In contrast, if the particles target the root prim, they go to the attached prim's location. Or, if the item is attached from Inventory and worn from there, a child prim can be properly targeted, too. (I believe the same effect obtains if the child prim is the origin of the particle system, too.)

Has anybody experienced anything like this before?

When an item is rezzed, it receives a new asset ID (UUID).


Also, Attachments do not know their relative position to the avatars position and there is no way for them to find out. Therefore they target the avatars position.

Well, no, particles are client-side effects, and indeed can target attached prims (otherwise, for example, "particle chains" like LockGuard and Lockmeister linking with attachments could never work, right?). (And, no, this isn't a problem with changed UUIDs.)

I finally devised a reasonably simple repro for this and posted it in the jira I created (http://jira.secondlife.com/browse/SVC-1765).

I honestly don't know what's underlying this... whether it could be related to the ever-popular "attachments rezzed at butt" problem, for example.

On a few occasions, when lag has been rather bad, I'd notice that attachments DO first rez themselves at the avatar's center, THEN jump to the positions of the attachment points they are supposed to occupy. I've always assumed that the "hair up the butt" thing was because the item failed to jump to the attachment point after the render, and in this case your problem may be caused by a failure of the simulator to update the position of the rezzed item properly, causing the sim to THINK it's still at the avatar's center.

actually that's pretty much how it always happens, attach defaults to the root before being fed the position of it's attach point, just normally you get the attch point before you see the object rezz so no big deal (and thus failing to get the attach point in a timely manner results in attachments where the sun don't shine). this may be the result of some type of race condition, where the object starts rezzing even if it doesn't have all the info (like the attach point). supposedly this is fixed in Nicholaz viewer as of BE-s, and I haven't seen it since then (but I rarely saw it before).

if I understand Qie's problem llAttachToAvatar and wearing from inworld (vs from inventory) the child prims attach relative position isn't being updated, only the root position. but if worn from inventory, the childs position IS being updated correctly.

at a guess the problem is that child positions only get updated once (global position to relative position), when they should update twice in qie's case (global to avatar global to relative position)... whether that's because the viewer isn't getting an update, or because the viewer isn't proccessing the second update from inworld attach events is anyones guess.

voted.

EDIT:
had a thought, perhaps it's not the child position that isn't updating, but the particle system, if you restart the particle system in the attach event does it still misbehave?

Good thought, but in fact the problem originally appeared in an attachment that generated the particle system only upon the attach() event. I even tried throwing in some llSleep between attachment and generating the particle system, but not surprisingly, it didn't help. The interesting thing is that the child prim's position in the viewer is quite correctly updated, just the particle system associated with that prim (either as emitter or target) doesn't move with it. (Hmmm... now that I've said that, this is almost certainly a VWR problem, not a SVC problem. Oh well.)

maybe not, since the viewer IS updating the visual position of the child (presumably) so it's still kind of up in the air.... it's as if the particle system is being treated as a seperate entity from the containing prim, yet particles are a prim property so you'd expect them to update with the prim.... all very odd.