Rezzing Object in Right Landscape Position

[Prokofy Neva]

So I am reviewing this thread:

 

And I am still struggling to get a flat painting in landscape orientation to come out right, trying all kinds of numbers.

So there are four positions in this particular as follows:

rotation DIRECTION = <-1.0, 1.0, -1.0, -1.0>; //Change the numbers here to change 
                                           //the direction that the prim rezzed 
                                           //from your rezzer will face.

Having the numbers as I've indicated here, with negative and positive, makes the painting face away from me, and tilted 90 degrees.

Having this: 
rotation DIRECTION = <1.0, 1.0, -1.0, 1.0>;

makes the painting now face me, but tilted 90 degrees to the left.

and so on. So I have been trying by trial and error but there are a zillion combinations and I'm not hitting the right one.

How can this be done scientifically. So if you face the rezzer prim, you want the painting to rez above the prim and face you, with the right landscape orientation.

I realize there aren't degrees like on obects, 90, 180, 270 etc. So what do the integers 1,2,3,4 mean, and what are the negatives and positives?

1.0, 1.0, 1.0, 1.0 is not what does that -- that gives you a flat item like a map on a table, rezzing parallel to and facing away from you.

 

Edited March 7, 2019 by Prokofy Neva

[steph Arnott]

23 minutes ago, Prokofy Neva said:

So I am reviewing this thread:

 

 

Think you are wanting this http://wiki.secondlife.com/wiki/LlSetRot

[Prokofy Neva]

Thanks, but no, I saw that, and it says "one degree change" but that can't be right because this doesn't seem to work by the usual degrees like "90" or "180" but by smaller numbers.

[steph Arnott]

18 minutes ago, Prokofy Neva said:

Thanks, but no, I saw that, and it says "one degree change" but that can't be right because this doesn't seem to work by the usual degrees like "90" or "180" but by smaller numbers.

EH? llSetRot(0.0, PI, 0.0); //PI_BY_TWO   first is 180 degrees second 90 degrees. Even still it works if you type the value of 180 or 90. But you need to get its rezzer rotation first.

Edited March 7, 2019 by steph Arnott

[steph Arnott]

22 minutes ago, Prokofy Neva said:

Thanks, but no, I saw that, and it says "one degree change" but that can't be right because this doesn't seem to work by the usual degrees like "90" or "180" but by smaller numbers.

Try this as it seems the fastest for you http://wiki.secondlife.com/wiki/Builders_Buddy_v1

[Wulfie Reanimator]

I can explain this in much greater detail and even help you inworld once I get home (very soon), but in short, "rotation" in LSL is also known as a quaternion. They are Infamously mind-bending to use directly to describe a specific rotation (besides 90 degree increments), so it is better to use a regular "vector" with 3 values instead if you wanted to define a set rotation. We'd also need to know what the "upright" rotation is, among other minor details.

Edited March 7, 2019 by Wulfie Reanimator

[Prokofy Neva]

1 hour ago, Wulfie Reanimator said:

I can explain this in much greater detail and even help you inworld once I get home (very soon), but in short, "rotation" in LSL is also known as a quaternion. They are Infamously mind-bending to use directly to describe a specific rotation (besides 90 degree increments), so it is better to use a regular "vector" with 3 values instead if you wanted to define a set rotation. We'd also need to know what the "upright" rotation is, among other minor details.

I'm glad you mentioned that because I was puzzled -- why do objects inworld have only three positions for direction, X, Y, and Z, which could be at 0,0,0 or 0, 90, 0 or whatever. But this script has four positions. So what is that fourth position? the back of the prim, i.e. the face facing away from you? The fourth dimension...?

@steph so apparently I mixed up the fact that you need integers under 10 for the first thing (how far above or to the left or right the item rezzes, which is going to be 1,2,3 or eve 0.5 -- and this other thing which you say you can use 90, 180 etc. for.

Still baffled why it doesn't work.

This isn't about builder's buddy or rez faux or anything like that.

This is the script once discussed at enormous length, and acrimonously by some, which is "Rez object on touch" so you can "summon a spirit" or "make a rabbit come out of a hat" and so on.

I kept noticing that no matter how you put the object inside the other prim with the right orientation, it doesn't matter, it will rez it automatically some other way. Which means you have to change the position. It's easy to change the position to get it further or closer to the original rezzing object. But this other bit just escapes me.

So the rezzing prim has an orientation like this for the XYZ numbers: 0,0.90.

So I want the prim rezzed out to have this: 0,0,270.

I don't know why they are different -- I'm just reporting what the numbers say inworld if you orient both the rezzer and the rezzed object to be how you want them, facing you.

So...what numbers go in the script here to make it do that??? What must be changed here:

rotation DIRECTION = <-1.0, 1.0, -1.0, -1.0>; //Change the numbers here to change 
                                           //the direction that the prim rezzed 
                                           //from your rezzer will face.

 

0,0,270 -- the orientation of the prim as you want it inworld -- doesn't work. That leads the object to rez out a prim perpendicular to it. 0,0,0,270 doesn't work. And so on.

I just don't get the principle of how this works.

These photos show how I want it to be; how it comes out:

https://3dblogger.typepad.com/second_thoughts/2019/03/why-is-rez-object-on-touch-orientation-so-hard.html

 

Edited March 7, 2019 by Prokofy Neva

[steph Arnott]

2 minutes ago, Prokofy Neva said:

 

Because the maths includes a sphere diameter factor. the formula used is x, y, z, s. The back ground maths is far more complicated because it uses dot products. The script page i gave you a link will do what you want. You can study those scripts while you have a working set. The base script is the recorder and the other the data passer.

[Fenix Eldritch]

As a sidenote regarding the understanding of quaternions, there is a thread in the LSL Library forum which links to a video about them. I've been meaning to watch it, and I hear it's pretty good at explaining how they work.

 

[Wulfie Reanimator]

23 minutes ago, Prokofy Neva said:

So what is that fourth position? the back of the prim, i.e. the face facing away from you? The fourth dimension...?

Let's just say "the fourth dimension" to keep it simple. (It's not actually a rotation in 4D space, but it might as well be.)

Here's a little "visualization" (kind of):

default
{
    state_entry()
    {
        rotation direction = llGetRot();        // original rotation, "quaternion"
        llOwnerSay("rotation: " + (string)direction);

        vector euler = llRot2Euler(direction);  // converted to "euler angles"
        llOwnerSay("euler: " + (string)euler);

        vector degrees = euler * RAD_TO_DEG;    // convert "radians to degrees"
        llOwnerSay("degrees: " + (string)degrees);
    }
}

If I put this script into an object that is rotated (in the edit window) like: X = 0,   Y = 0,   Z = 90
The output from the script is:
rotation: <0.00000, 0.00000, 0.70711, 0.70711>
euler: <0.00000, 0.00000, 1.57080>
degrees: <0.00000, 0.00000, 90.00000>

For X = 0,   Y = 0,   Z = 270 (or Z = -90):
rotation: <-0.00000, 0.00000, -0.70711, 0.70711>
euler: <0.00000, 0.00000, -1.57080>
degrees: <0.00000, 0.00000, -90.00000>

So there's also your answer I guess, if you really want to stick to "real" rotations and bang your head again later.
A much simpler way to set the rotation to something you actually want goes something like this...

vector degrees = <0, 0, 270>;

// convert degrees back to radians
rotation direction = llEuler2Rot(degrees * DEG_TO_RAD);

llSetRot(direction);

vector degrees = <0, 0, 270>;
llSetRot(llEuler2Rot(degrees * DEG_TO_RAD));

llSetRot(llEuler2Rot(<0, 0, 270> * DEG_TO_RAD));

(They all do exactly the same thing, pick the one you prefer and put it anywhere in the script where rotation needs to be set.)

P.S. I'm online inworld in case you want personal help.

Edited March 7, 2019 by Wulfie Reanimator

[steph Arnott]

4 minutes ago, Wulfie Reanimator said:

 

' Let's just say "the fourth dimension" to keep it simple. (It's not actually a rotation in 4D space, but it might as well be.) ' NO, that comment is laughable. Clearly shows you have no idea what the last value even does.

Edited March 7, 2019 by steph Arnott

[Prokofy Neva]

Thanks to Wulfie I got this to work on one script, but now not on another. 

I don't know if the "touch to start" is an issue.

So if you read this old thread, you see the various options and possible errors.

If you see the attached basic "rez object on touch" script, it has a way to control for the height above the rezzing object, but doesn't seem to have a way to control the degree of rotation at which the object comes out.

Plugging in lines suggested in the old thread don't work, nor the ones in this thread -- maybe I'm missing a line or something.

default
{
    touch_start(integer total_number)
    {
        llRezObject("OBJECTNAME", llGetPos() + < 0.0, 0.0, 0.5 >, ZERO_VECTOR, ZERO_ROTATION, 42); // edit object-name and change relative coordinates of rezzed object if desired - default: .5m above rezzer object
    }
} 

The thing about "ZERO_VECTOR" doesn't work at all if you try to change anything there.

 

[steph Arnott]

8 hours ago, Prokofy Neva said:

default
{
    touch_start(integer total_number)
    {
        llRezObject("OBJECTNAME", llGetPos() + < 0.0, 0.0, 0.5 >, ZERO_VECTOR, ZERO_ROTATION, 42); // edit object-name and change relative coordinates of rezzed object if desired - default: .5m above rezzer object
    }
} 

The thing about "ZERO_VECTOR" doesn't work at all if you try to change anything there.

 

It is for physical objects such as bullets. Basically it trys to produce  Newton's third law. No matter what value you use it will do nothing if a non physical object is rezzed by the rezzer.

Edited March 21, 2019 by steph Arnott

[Profaitchikenz Haiku]

Prokofy, In your snippet ZERO_VECTOR is the initial velocity the object is to be given. Changing the entry just beyond it from ZERO_ROTATION to something like llEuler2Rot(<0.0, 0.0, 90.0>*DEG_2_RAD) should rotate the object through 90 degrees on the Z axis

 

Edited March 21, 2019 by Profaitchikenz Haiku

[Prokofy Neva]

6 hours ago, Profaitchikenz Haiku said:

Prokofy, In your snippet ZERO_VECTOR is the initial velocity the object is to be given. Changing the entry just beyond it from ZERO_ROTATION to something like llEuler2Rot(<0.0, 0.0, 90.0>*DEG_2_RAD) should rotate the object through 90 degrees on the Z axis

 

I tried putting that in, inserting the object name, with or without the "42" but then the "touch" ceases to work, it doesn't rez at all.

default
{
    touch_start(integer total_number)
    {
        llRezObject("OBJECTNAME", llGetPos() + < 0.0, 0.0, 0.5 >, ZERO_VECTOR, llEuler2Rot(<0.0, 0.0, 90.0>*DEG_2_RAD), 42); // edit object-name and change relative coordinates of rezzed object if desired - default: .5m above rezzer object
    }
} 

 

[Rolig Loon]

That's because there's a minor typo:

default
{
    touch_start(integer total_number)
    {
        llRezObject("OBJECTNAME", llGetPos() + < 0.0, 0.0, 0.5 >, ZERO_VECTOR, llEuler2Rot(<0.0, 0.0, 90.0>*DEG_TO_RAD), 42); // edit object-name and change relative coordinates of rezzed object if desired - default: .5m above rezzer object
    }
} 

[Prokofy Neva]

6 hours ago, steph Arnott said:

It is for physical objects such as bullets. Basically it trys to produce  Newton's third law. No matter what value you use it will do nothing if a non physical object is rezzed by the rezzer.

It works whether or not you put it on physical, though.

[steph Arnott]

Just now, Prokofy Neva said:

It works whether or not you put it on physical, though.

Does not. The parameter vel is for physical objects. It uses the formula based on Newton's third law.

[Prokofy Neva]

@Rolig Loon -- thank you, that did it!

[Prokofy Neva]

Just now, steph Arnott said:

Does not. The parameter vel is for physical objects. It uses the formula based on Newton's third law.

You might want to revise your opinion on that. Try it in world, as I have, with an object, that is not on physics, but only temporary, with the script as revised.

default
{
    touch_start(integer total_number)
    {
        llRezObject("OBJECTNAME", llGetPos() + < 0.0, 0.0, 0.5 >, ZERO_VECTOR, llEuler2Rot(<0.0, 0.0, 90.0>*DEG_TO_RAD), 42); // edit object-name and change relative coordinates of rezzed object if desired - default: .5m above rezzer object
    }
} 

I seldom put these items on physics (which works, too, but doesn't HAVE to be so) because they bounce around, and even if on temp, they fall through skyboxes, roll off the property etc and are annoying.

[steph Arnott]

Just now, Prokofy Neva said:

You might want to revise your opinion on that. Try it in world, as I have, with an object, that is not on physics, but only temporary, with the script as revised.

default
{
    touch_start(integer total_number)
    {
        llRezObject("OBJECTNAME", llGetPos() + < 0.0, 0.0, 0.5 >, ZERO_VECTOR, llEuler2Rot(<0.0, 0.0, 90.0>*DEG_TO_RAD), 42); // edit object-name and change relative coordinates of rezzed object if desired - default: .5m above rezzer object
    }
} 

I seldom put these items on physics (which works, too, but doesn't HAVE to be so) because they bounce around, and even if on temp, they fall through skyboxes, roll off the property etc and are annoying.

DOES NOT. VEL USES NEWTON'S 3RD LAW. AN OBJECT HAS TO BE PHYSICAL FOR THE HAVOC ENGINE TO WORK.

[Prokofy Neva]

5 minutes ago, steph Arnott said:

DOES NOT. VEL USES NEWTON'S 3RD LAW. AN OBJECT HAS TO BE PHYSICAL FOR THE HAVOC ENGINE TO WORK.

Well, call me when you log on and actually go inworld and try it because I have an item here (the "Hand of Glory" -- click and it produces the "Hand of Glory Aflame" on temp -- check and you'll see it is not checked off for physics), that rezzes just fine. Just like all the items using similar scripts that are NOT on physics.

Guess not for the first time, Second Life violates Newton's Laws. 

Edited March 22, 2019 by Prokofy Neva

[steph Arnott]

Just now, Prokofy Neva said:

Well, call me when you log on and actually go inworld and try it because I have an item here (the "Hand of Glory" -- click and it produces the "Hand of Glory Aflame" on temp -- check and you'll see it is not checked off for physics), that rezzes just fine. Just like all the items using similar scripts that are NOT on physics.

Guess not for the first time, Second Life violates Newton's Laws. 

Do not need to. The object using vel uses the Havok engine. All agent are physical by default.

[Prokofy Neva]

1 minute ago, steph Arnott said:

Do not need to. The object using vel uses the Havok engine. All agent are physical by default.

Then the box would check off by default but it isn't checked.

[steph Arnott]

8 minutes ago, Prokofy Neva said:

 

Good for you. Clearly you wish to argue about something you clearly do not understand.

Edited March 22, 2019 by steph Arnott