rotating a child prim which must keep its angle

[InternetHITS]

I am looking for a script which can rotate a child prim. physical and non physical. The child prim must keep its angle. 

e.q.

1 root prim

1 child prim rotated some angle

then I want to rotate the child prim 360  degees on its same position keeping its starting angle up or down. Like Earth Z axe doesnt change when it rotates the sun.

Headache of those 4d rotations...pfft 

 

 

 

 

[Rolig Loon]

I don't quite understand what you want to do.  Are you trying to figure out how to make the Earth rotate on a tilted axis?  See the example in llTargetOmega at http://wiki.secondlife.com/wiki/LlTargetOmega#Examples

[Madelaine McMasters]

If I understand what you want to do, I don't think it can be done well. llTargetOmega() on a child prim will rotate the prim around the child's local axis, but that axis will be in constant rotation with respect to the region because of the root prim's rotation. This is analogous to having a child prim remain region-stationary while the root prim is moved. It can be done, but it won't be smooth.

Edited October 14, 2019 by Madelaine McMasters

[Profaitchikenz Haiku]

A simple way of doing what the OP wants is to effectively forget about rotations, the child prim will be moved to a sequential series of positions which lie on  a circle centred on the root prim (but possibly above or below the root prim Z axis). If the movements are in 1 degree increments it shouldn't be too juddery, given that the maximum radius of the circle will be half the maximum possible link distance.

Since it's local positions, they are going to be relative to a central 0,0,0 so it's just trig functions. Assuming no variation will take place on the Z axis, the local Z offset is constant, therefore only X and Y are calculated.  At any angle theta around the centre of the root prim, the local pos for the child prim is < r * cos(theta), r * sin(theta), 0>. (It gets complicated if zoffset is not zero because R then needs to be reduced to be r * cos omega where omega is the angle between the horizontal plane and the radius going to the child prim above or below this plane.)

If you can get away with larger increments than 1 degree, say 5 or 10 degrees, it would be worth calculating these in advance and sticking them in a list of vectors to reduce the amount of script time.

Edited October 14, 2019 by Profaitchikenz Haiku

[Wulfie Reanimator]

43 minutes ago, Profaitchikenz Haiku said:

A simple way

Trigonometry was never my strong-suit.

vector angle = <0, 45, 0>;
llTargetOmega(<0,0,1> * llEuler2Rot(angle * DEG_TO_RAD), 1, 1);

Same effect, but making a child rotate from the root script:

integer  link  = 2;
list     data  = llGetLinkPrimitiveParams(link, [PRIM_ROT_LOCAL]);
rotation local = llList2Rot(data, 0);

llSetLinkPrimitiveParamsFast(link, [PRIM_OMEGA, <0,0,1> * local, 1, 1]);

This is my interpretation of what the OP wanted, anyway. "360 degrees on its same position while keeping its angle."

Edited October 14, 2019 by Wulfie Reanimator

[Rolig Loon]

43 minutes ago, Profaitchikenz Haiku said:

A simple way of doing what the OP wants is to effectively forget about rotations, the child prim will be moved to a sequential series of positions which lie on  a circle centred on the root prim (but possibly above or below the root prim Z axis). If the movements are in 1 degree increments it shouldn't be too juddery, given that the maximum radius of the circle will be half the maximum possible link distance.

Since it's local positions, they are going to be relative to a central 0,0,0 so it's just trig functions. Assuming no variation will take place on the Z axis, the local Z offset is constant, therefore only X and Y are calculated.  At any angle theta around the centre of the root prim, the local pos for the child prim is < r * cos(theta), r * sin(theta), 0>. (It gets complicated if zoffset is not zero because R then needs to be reduced to be r * cos omega where omega is the angle between the horizontal plane and the radius going to the child prim above or below this plane.)

Ah ... so you assume that what the OP wants to calculate in not the Earth's rotation around its own axis but its rotation around the Sun, allowing for no precession ( Edit: I assume that's what the OP means by "keeping its own angle")?   If that's the case, then I agree that he shouldn't use llTargetOmega for either the linkset as a whole or the child prim.  The calculations will be much easier in analytical form and then applied in steps.  It should be possible to do it all in a single script in the root.  At each step, he'll need to calculate the new position of the child prim, readjust the rotational axis of the child prim so that it continues to point in the same global direction, and calculate the child prim's new rotation around that axis.  I'm not as optimistic as you about keeping all of that from being jumpy unless he makes small steps, but I could be surprised.

Edited October 14, 2019 by Rolig Loon

[Profaitchikenz Haiku]

(Wulfie) OK, I read them differently, this is what I just trialed inworld, it moves a child prim around a root prim on a horizontal plane

 

/// simple movement around a root prim for a child
// rez a cube, shift-copy it along the X axis to make a child, link them
// (This is a cheat so that initial theta is zero and we don't have to calculate initial conditions)

key owner;

integer root = 1;
integer child = 2;

integer moving = 0;
float radius = 0.0;
float theta;

float oneDegree;

vector childPos;

setup()
{
    childPos = llList2Vector(llGetLinkPrimitiveParams(child, [PRIM_POS_LOCAL]), 0);

    radius = llVecMag(childPos);
    theta = 0.0;
}

default
{
    state_entry()
    {
        owner = llGetOwner();
        llSetTimerEvent(0.0);
        oneDegree  = PI / 180;
        if(llGetNumberOfPrims() < 2)
        {
            llOwnerSay("This ain't gonna work");
        }
        else
        {
            setup();
            if( radius > 0.0)
            {
                llSetTimerEvent(1.0);
                moving = 1;
            }
        }
    }

    touch_start(integer touches)
    {
        key toucher = llDetectedKey(touches - 1);
        if( toucher == owner)
        {
            if( radius > 0.0)
            {
                if( moving)
                {
                    llSetTimerEvent(0.0);
                }
                else
                {
                    llSetTimerEvent(1.0);
                }
                moving = !moving;
            }
        }
    }
    timer()
    {
        theta += oneDegree;
        if( theta >= TWO_PI) theta = 0;

        float newX = radius * llCos(theta);
        float newY = radius * llSin(theta);

        childPos.x = newX;
        childPos.y = newY;

        llSetLinkPrimitiveParamsFast(child, [PRIM_POS_LOCAL, childPos]);
    }
}

Rolig, I confess half the time I don't know what people want when they post here, probably senior moment time.

Edited October 14, 2019 by Profaitchikenz Haiku

[Rolig Loon]

8 minutes ago, Profaitchikenz Haiku said:

OK, I read them differently, this is what I just trialed inworld, it moves a child prim around a root prim on a horizontal plane

Hmmmm... I started to write something else, but have managed to get myself confused, so I have to wait until I can go in world to try an experiment that I can see with my own eyes.

Edited October 14, 2019 by Rolig Loon

[Profaitchikenz Haiku]

I just re-read the OP's post and I think Wulfie has understood what they wanted. I latched onto the earth going around the sun keeping it's inclination and went to work on that model.

Edited October 14, 2019 by Profaitchikenz Haiku

[Rolig Loon]

1 minute ago, Profaitchikenz Haiku said:

I just re-read the OP's post and I think Wulfie has understood what they wanted.

No, that's what I suggested initially, but it only rotates the child around its own axis.  If the OP is interested in replicating the sort of rotations in the Earth-Sun system, he has to get the child prim rotating around not only its own axis but also the root's AND he has to keep the child's axis pointed in the same global direction (that is, no precession of the child prim's axis).  If you don't also include that last constraint, you'll end up with a child prim whose axis is always tilted toward or away from the root prim as it travels around it.  If the Earth behaved like that, the northern hemisphere would always be in summer while the southern hemisphere was always in winter.  Trying to model that in my head is a little painful, which is why I deleted what I started to write a minute ago.  I need to see it in world.  I was a chemist, not an astronomer.  😊 

[Wulfie Reanimator]

3 minutes ago, Rolig Loon said:

If the OP is interested in replicating the sort of rotations in the Earth-Sun system

Until they come back to give clarification, I don't think they meant that they're literally going to be making something like a solar system.

It was just an example of how the tilt of the object (Earth) doesn't change as it rotates around its own axis. (Which, by the way, isn't even true about the Earth. 🤔)

[Profaitchikenz Haiku]

1 minute ago, Rolig Loon said:

If the OP is interested in replicating the sort of rotations in the Earth-Sun system, he has to get the child prim rotating around not only its own axis but

... circling the root, so in the case I have examined, adding omega to the child prim would accomplish that.

The distinction here is between "rotating about" and "rotating around", I think?

 

Still, it's interesting we're three blind people groping at an elephant here 

"It's rubbery"

"What's that hot smelly stuff?"

"It's got an enormous schwanstucker"

 

 

[Rolig Loon]

Just now, Wulfie Reanimator said:

(Which, by the way, isn't even true about the Earth. 🤔)

Yes, I know.  That's what precession of the Earth's axis means.  If you want to model that actual precession instead of forcing it to be zero, the problem starts to get truly messy.

[Rolig Loon]

1 minute ago, Profaitchikenz Haiku said:

Still, it's interesting we're three blind people groping at an elephant here 

Very true.  I like elephants but, yeah, trying to build one to ambiguous specifications is a parlor game, not scripting. 

[Madelaine McMasters]

I imagined the OP wanted something like an orrery. I tried building one a decade ago and gave up because of the judder caused at each change of the child prim's axis orientation. Every smooth orrery I've seen gets the rotations wrong. Tilted planets have their axes rotating about the Sun rather than being fixed to "galactic" coordinates. I was unable to script even the smallest axis corrections without breaking the smooth look of llTargetOmega().

[Rolig Loon]

6 minutes ago, Madelaine McMasters said:

I was unable to script even the smallest axis corrections without breaking the smooth look of llTargetOmega().

That's what I was afraid of:

55 minutes ago, Rolig Loon said:

At each step, he'll need to calculate the new position of the child prim, readjust the rotational axis of the child prim so that it continues to point in the same global direction, and calculate the child prim's new rotation around that axis.  I'm not as optimistic as you about keeping all of that from being jumpy unless he makes small steps, but I could be surprised.

But we are all guessing, as Prof says. 

[InternetHITS]

On 10/14/2019 at 9:24 PM, Profaitchikenz Haiku said:

(Wulfie) OK, I read them differently, this is what I just trialed inworld, it moves a child prim around a root prim on a horizontal plane

 

/// simple movement around a root prim for a child
// rez a cube, shift-copy it along the X axis to make a child, link them
// (This is a cheat so that initial theta is zero and we don't have to calculate initial conditions)

key owner;

integer root = 1;
integer child = 2;

integer moving = 0;
float radius = 0.0;
float theta;

float oneDegree;

vector childPos;

setup()
{
    childPos = llList2Vector(llGetLinkPrimitiveParams(child, [PRIM_POS_LOCAL]), 0);

    radius = llVecMag(childPos);
    theta = 0.0;
}

default
{
    state_entry()
    {
        owner = llGetOwner();
        llSetTimerEvent(0.0);
        oneDegree  = PI / 180;
        if(llGetNumberOfPrims() < 2)
        {
            llOwnerSay("This ain't gonna work");
        }
        else
        {
            setup();
            if( radius > 0.0)
            {
                llSetTimerEvent(1.0);
                moving = 1;
            }
        }
    }

    touch_start(integer touches)
    {
        key toucher = llDetectedKey(touches - 1);
        if( toucher == owner)
        {
            if( radius > 0.0)
            {
                if( moving)
                {
                    llSetTimerEvent(0.0);
                }
                else
                {
                    llSetTimerEvent(1.0);
                }
                moving = !moving;
            }
        }
    }
    timer()
    {
        theta += oneDegree;
        if( theta >= TWO_PI) theta = 0;

        float newX = radius * llCos(theta);
        float newY = radius * llSin(theta);

        childPos.x = newX;
        childPos.y = newY;

        llSetLinkPrimitiveParamsFast(child, [PRIM_POS_LOCAL, childPos]);
    }
}

Rolig, I confess half the time I don't know what people want when they post here, probably senior moment time.

Haiku,

Tx for your energy. But this is not what I was trying to accomplish. 

I will add more info.

Lets think about a tank turret and the turret points up to the sky.

Then the turret  rotates horizintal . I want the turret keeping up in any horizontal degree.

This must be the case for physical and non physical prims.

Its not my intention to confuse anyone. 

 

[InternetHITS]

On 10/14/2019 at 9:23 PM, Rolig Loon said:

Ah ... so you assume that what the OP wants to calculate in not the Earth's rotation around its own axis but its rotation around the Sun, allowing for no precession ( Edit: I assume that's what the OP means by "keeping its own angle")?   If that's the case, then I agree that he shouldn't use llTargetOmega for either the linkset as a whole or the child prim.  The calculations will be much easier in analytical form and then applied in steps.  It should be possible to do it all in a single script in the root.  At each step, he'll need to calculate the new position of the child prim, readjust the rotational axis of the child prim so that it continues to point in the same global direction, and calculate the child prim's new rotation around that axis.  I'm not as optimistic as you about keeping all of that from being jumpy unless he makes small steps, but I could be surprised.

That is right. So I was trying to find or produce a script for it. And therefore I was asking for help on this forum. Because the calculations turns me crazy.

[Rolig Loon]

10 minutes ago, InternetHITS said:

Lets think about a tank turret and the turret points up to the sky.

Then the turret  rotates horizintal . I want the turret keeping up in any horizontal degree.

This must be the case for physical and non physical prims.

Sorry.  That's even more confusing than the original explanation.  

[InternetHITS]

On 10/14/2019 at 9:19 PM, Wulfie Reanimator said:

Trigonometry was never my strong-suit.

vector angle = <0, 45, 0>;
llTargetOmega(<0,0,1> * llEuler2Rot(angle * DEG_TO_RAD), 1, 1);

Same effect, but making a child rotate from the root script:

integer  link  = 2;
list     data  = llGetLinkPrimitiveParams(link, [PRIM_ROT_LOCAL]);
rotation local = llList2Rot(data, 0);

llSetLinkPrimitiveParamsFast(link, [PRIM_OMEGA, <0,0,1> * local, 1, 1]);

This is my interpretation of what the OP wanted, anyway. "360 degrees on its same position while keeping its angle."

Tx a lot for your energy. But that intepretation is wrong. See my other posts today.

Anyway tx a lot I appreciate your energy trying to solve it for me. thumbs up!

[Rolig Loon]

2 minutes ago, InternetHITS said:

On 10/14/2019 at 2:23 PM, Rolig Loon said:

At each step, he'll need to calculate the new position of the child prim, readjust the rotational axis of the child prim so that it continues to point in the same global direction, and calculate the child prim's new rotation around that axis.  I'm not as optimistic as you about keeping all of that from being jumpy unless he makes small steps, but I could be surprised.

That is right. So I was trying to find or produce a script for it.

So, I was on the right track. If so, then Maddy's comment was a relevant addition to my own:

On 10/14/2019 at 3:12 PM, Madelaine McMasters said:

I imagined the OP wanted something like an orrery. I tried building one a decade ago and gave up because of the judder caused at each change of the child prim's axis orientation. Every smooth orrery I've seen gets the rotations wrong. Tilted planets have their axes rotating about the Sun rather than being fixed to "galactic" coordinates. I was unable to script even the smallest axis corrections without breaking the smooth look of llTargetOmega().

In other words, even if you can do the calculations, it's not likely to look at all smooth

[InternetHITS]

1 minute ago, Rolig Loon said:

So, I was on the right track. If so, then Maddy's comment was a relevant addition to my own:

In other words, even if you can do the calculations, it's not likely to look at all smooth

Thats fine with me if it isnt smooth. 

I would be so happy. If anyone had a script for it.

[Rolig Loon]

If you want to hire a scripter, the place to post is the InWorld Employment forum.

[InternetHITS]

Problem solved. Tx for your energy

[Profaitchikenz Haiku]

I'm doubly-confused now, not one of us could get what the OP was asking for?

What's really thrown me is the throwaway remark of a tank. The turret and the barrel are child prims, and so rotating the turret to a given angle as well as elevating the barrel and maintaining that elevation is a complicated exercise unless you do something clever like make the root prim a small prim with the turret on the same Z-axis. Rotating the turret is then trivial, rotating the barrel around the z-axis slightly less trivial, but still doable. It only gets really tricky if the OP then wants to emulate the Challenger 2 and Abrams "keep the barrel on the target no matter what the tank does" behaviour.

Next up I expect the OP might give as an example how a Dalek roams around with the suction cup and Zapper gun at precise angles?

It made more sense to me when the OP was talking about the earth in orbit around the sun