Two newbie questions
|
|
Luki Ronmark
Registered User
Join date: 18 Jun 2007
Posts: 8
|
06-18-2007 12:15
The first, and one that it seems I should have been able to find elsewhere, if its possible ... is there an easy way to change the root of a link? I'm guessing no, that a link of objects functions like a linked list, so swapping items isnt as easy as one might hope. The second ... i read the post discussing the problems with local rotation if the root is rotating. I tried to use the fix suggested by Lex Neva here ( /54/c1/94705/1.html). But it didn't seem to work for me. Perhaps a portion of the problem is that I am trying to apply this to the entire link at once, rather than to just one child. Code here: rotation rot = <0.0,0.0,0.0,4.0>; rotation rootRot = llGetRootRotation(); llSetRot(rot/rootRot); llSetLinkPrimitiveParams(LINK_SET,[PRIM_ROTATION,(rot/rootRot)/rootRot]); the result I want is for each member of the link to rotate around its own z axis. The link is non-physical, if that matters at all. And a third question perhaps ... is there anyway to apply a llTargetOmega to the members of a link after the link is formed? Ideally, i'd like to get the continuos rotation here rather than the jerky thing the timer is giving me at the moment.
|
|
Anti Antonelli
Deranged Toymaker
Join date: 25 Apr 2006
Posts: 1,091
|
06-18-2007 13:21
On the first one:
Yes you can change the link order; when linking prims the last prim selected is always the root. If it's a relatively simple object you can just select the entire object then Unlink under the Tools menu, then select the individual prims *making sure to select your intended root prim last*, then relink using Tools... Link.
If it's a more complex item, it might be easier to edit the object, in the edit window check Edit Linked Parts, then carefully select only the intended root prim before Unlinking. This will leave all the other pieces linked, and then it's a simple matter to select the linked "chunk", then the intended root prim, then re-Link with the same results.
|
|
Luki Ronmark
Registered User
Join date: 18 Jun 2007
Posts: 8
|
06-18-2007 13:40
Thanks! I discovered this to ... can't even remember where I found it now, seems it took quite some digging ... but Cntrl+Shift+L while selecting a linked object delinks the entire thing, which is what I needed there. However, I am still unable to get the script to work correctly in the way I want - namely, to allow each of the items in a link to rotate separately around its own Z axis.
Is this because theres the posibbility that this would move objects out of the link range? That wouldnt be a concern in my particular application, but I suppose I can see why they might not allow the behavior I want for that reason. As it is, the best ive managed is to get the central prim as the root, thus causing the entire construct to rotate, which is NOT the behavior I was seeking.
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
06-18-2007 13:49
Oh... I was guessing that the OP may have intended to use a script to change the root prim of a linkset. This too is do-able with llBreakLink() and llCreateLink(), but a couple things to keep in mind: calling scripts need PERMISSION_CHANGE_LINKS; the llCreateLink() will need to run from the individual prims (well... at least in the new root prim, I guess), and there may be lots of side-effects as every script in the linkset with a CHANGED_LINK handler wakes up.
Skipping #2 cuz you really want to do #3 (and #2 is harder) -- yes, child prims can run llTargetOmega() for exactly the desired effect. Omega isn't a property that can be set with llSetLinkPrimitiveParams(), though, if that's what you mean, so if you wanted to start and stop the spinning, you'd need to llMessageLinked() to the scripts in the individual prims. (Note, however, that llTargetOmega() is rich in folklore, and surprises may ensue.)
And yes, if you try to set the position of a child prim beyond its (sometimes unexpected) maximum distance from the rest of the linkset, it will just silently do nothing, but as you say, that shouldn't be a problem with what you're doing.
|
|
Luki Ronmark
Registered User
Join date: 18 Jun 2007
Posts: 8
|
06-18-2007 16:56
I don't know if this is part of the local rotation/targetomega folklore or not ... but I continue to have this issue, where I am unable to cause the child prims of my link to each rotate about their own personal axis of symmetry, which in this case is aligned with the z axis by design. Perhaps I suffer from some confusion about the way rotations work here ... are they, in fact, rotating about a corner rather than their center/axis of symmetry?
A clarification ... Ideally, the root prim would perform this same rotation. However, when it does so, I want all of the other prims to maintain their original positions, spacially. That is, I do not want them to move in such a way, as to maintain their position with respect to the root; I want them to maintain the same absolute position.
I have managed, now, when I construct it such that the root prim does not rotate, to achieve the effect I want. However, it is not quite the effect I want ... because I want all the prims to rotate.
|
|
Shadow Subagja
Registered User
Join date: 29 Apr 2007
Posts: 354
|
06-18-2007 17:02
One thing to keep in mind (at least it seems this way to me) is that prims with path cuts and such still roate around the axis of the original fully shaped prims. Does that help explain anything?
For example if you take a sphere and hollow it out, then path cut it so you have a rounded wedge.. good luck trying to rotate that on anything that resembles its own axis, its still a sphere I think.
|
|
Luki Ronmark
Registered User
Join date: 18 Jun 2007
Posts: 8
|
06-18-2007 17:47
Thats interesting, but in this case im working with the original prims, not even size-modified. And, I am now able to rotate them about their own axis of symmetry (huzzah!). However, i cannot get llTargetOmega to allow me to have the prims of the link rotate in place, if the root is rotating ... it appears to be mandatory that they maintain their spacial relation to the the root. Although I wish I could get entirely the effect I wanted, I think amybe I've gotten close enough ... coming soon to a storefront near you! heh.
|
|
Qie Niangao
Coin-operated
Join date: 24 May 2006
Posts: 7,138
|
06-19-2007 03:53
Don't seem to be getting the same results. If I put llTargetOmega() in two prims and link them together, the child rotates with the root *and* spins on its own axis, too. Or is something else sought? (Since it's a client-side effect: 1.17.0.12 Linux ATI 8.37.6)
[edit: perhaps the root is supposed to spin at a different rate than the objects circling it--or not at all. *that* won't work, although you could have an invisible root prim that spins (or not) the other children, and have the central prim, concentric with the new invisible root, spin on its own--possibly inverse of the root's omega in order to stay still--I hope.]
|
|
Tiarnalalon Sismondi
Registered User
Join date: 1 Jun 2006
Posts: 402
|
06-19-2007 11:24
Well, 2 things on this. One, be careful when changing the root prim in a linked set. My suggestion is to change the root prim only after unlinking the entire object. The easiest way is to select the link set, ctrl+shift+L, and then shift+click the prim that you want to be the root. You can even combine linksets this way - the root of the whole being the root of the linkset last clicked. Again I stress to unlink the set that will be losing its root prim though. You won't notice a lot of issues on simpler builds, but this increases a phenomenon known as Prim Drift. If you try adding a new root prim to a linkset without unlinking a few times you'll quickly understand how/why when you see all of the prims in the linkset sort of jump when you link. There is usually some small rotational/position changes as a result. The other thing is that linkset movement and rotation is dependent on the root prim and any changes to it will affect the entire set as one object. The easiest way around this is as was mentioned before to add an invisible prim to the linkset and make it the root prim. You could then have it do whatever you wanted in respect to the entire set if you wanted to make everything rotate, etc...could even put an alpha cube right on top of the center part so that the rest would still function the same, but not be affected by what the old root prim is doing.
|
|
Shadow Subagja
Registered User
Join date: 29 Apr 2007
Posts: 354
|
06-19-2007 11:34
From: Luki Ronmark Thats interesting, but in this case im working with the original prims, not even size-modified. And, I am now able to rotate them about their own axis of symmetry (huzzah!). However, i cannot get llTargetOmega to allow me to have the prims of the link rotate in place, if the root is rotating ... it appears to be mandatory that they maintain their spacial relation to the the root. Although I wish I could get entirely the effect I wanted, I think amybe I've gotten close enough ... coming soon to a storefront near you! heh. Well you could probably try to fudge it by rotating them in space, AROUND the root if you tracked the root's original position and rotation. You can physically move them within 10m of the root. The problem is that if the root moves they all move, this is no different than your skirt attachment rotating with your avatar, which it is a child prim of. There are many example scripts to have an object orbit another. If you got reallly tricky you might be able to sweep the prims around the root in an arc to exactly undo any movement due to the root's rotation. It may look choppy though? Could be done though I think?
|
|
Luki Ronmark
Registered User
Join date: 18 Jun 2007
Posts: 8
|
06-19-2007 16:50
The behavior I wanted was for the child prims to not move at all in space (i.e. to NOT orbit the root, as the root rotates). However, I think that considering the huge prim count of what im making already, adding an invisible root prim that does NOT rotate wouldn't be so bad. At first I balked at the idea, because I was constructing the final object based on copies of sub-objects (that had been linked together, and that I wanted to each have the rotation behavior I've described). This would entail an additional exponential number of invisible prims, which seemed wasteful ... but I'm already up against the link limit, and may have to resort to channels rather than link messages to coordinate the rotation ... in which case there's really no reason to link and each prim can rotate in its absolute z anyway.
Thanks for the help all ... i think *this* problem is solved!
|