Difference between revisions of "User talk:Dora Gustafson"

From Second Life Wiki
Jump to navigation Jump to search
Line 29: Line 29:
  First in newly created prim:
  First in newly created prim:
  Box cut in 1/4, non-physic: 0.000000 // primposition returned for center of mass, NOT correct
  Box cut in 1/4, non-physic: 0.000000 // primposition returned for center of mass, NOT correct
  Physic box cut in 1/4: 0.706897 // square root(2), correct
  Physic box cut in 1/4: 0.706897 // square root(0.5), correct
  Physic box cut in half: 0.500004 // 0.5, correct
  Physic box cut in half: 0.500004 // 0.5, correct
  Box cut in half, non-physic: 0.500000 // saved value, correct
  Box cut in half, non-physic: 0.500000 // saved value, correct
Line 36: Line 36:
  Second run:
  Second run:
  Box cut in 1/4, non-physic: 0.500000 // saved value, NOT correct
  Box cut in 1/4, non-physic: 0.500000 // saved value, NOT correct
  Physic box cut in 1/4: 0.706915  // square root(2), correct
  Physic box cut in 1/4: 0.706915  // square root(0.5), correct
  Physic box cut in half: 0.499993 // 0.5, correct
  Physic box cut in half: 0.499993 // 0.5, correct
  Box cut in half, non-physic: 0.500001 // saved value, correct
  Box cut in half, non-physic: 0.500001 // saved value, correct

Revision as of 04:44, 17 December 2010

llGetCenterOfMass

You seem to have done some testing for llGetCenterOfMass. I'm curious, if you change the shape of the object in ways that should change the center of mass while it's non-physical, but after it has been physical (so that there is a cached value for the center) does it invalidate the cached value? So if you call llGetCenterOfMass does it then return the invalid value or the value of llGetPos? If you move the entire object does it return a position adjusted cached value for CoM? -- Strife (talk|contribs) 18:32, 3 December 2010 (UTC)

The answer to the first question is: no. The 'cached' value remains unchanged in non-physical mode.
The answer to the second is that llGetPos() is only assumed in a newly created prim, one that was never made physical and never computed the center of mass in physical mode.
When the non-physical virgin prim is moved around llGetCenterOfMass() returns the updated llGetPos() for the new positions.
When the non-physical prim where llGetCenterOfMass() was computed at least once in physical mode, the cached value persist.

Here is a script I used for testing: <lsl>default {

   touch_end(integer num)
   {
       llSetPrimitiveParams([PRIM_SIZE, <2.0, 2.0, 2.0>, PRIM_TYPE, 0, 0, <0.125, 0.375, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>]);
       llOwnerSay("Box cut in 1/4, non-physic: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetStatus( STATUS_PHYSICS, TRUE);
       llSleep(0.5);
       llOwnerSay("Physic box cut in 1/4: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetPrimitiveParams([PRIM_TYPE, 0, 0, <0.375, 0.875, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>]);
       llSleep(0.5);
       llOwnerSay("Physic box cut in half: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetStatus( STATUS_PHYSICS, FALSE);
       llSleep(0.5);
       llOwnerSay("Box cut in half, non-physic: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llSetPrimitiveParams([PRIM_TYPE, 0, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>]);
       llOwnerSay("Full box, non-physic: "+(string)llVecDist(llGetCenterOfMass(),llGetPos()));
       llResetScript();
   }

}</lsl> Output from above script:

First in newly created prim:
Box cut in 1/4, non-physic: 0.000000 // primposition returned for center of mass, NOT correct
Physic box cut in 1/4: 0.706897 // square root(0.5), correct
Physic box cut in half: 0.500004 // 0.5, correct
Box cut in half, non-physic: 0.500000 // saved value, correct
Full box, non-physic: 0.500000 // saved value, NOT correct

Second run:
Box cut in 1/4, non-physic: 0.500000 // saved value, NOT correct
Physic box cut in 1/4: 0.706915  // square root(0.5), correct
Physic box cut in half: 0.499993 // 0.5, correct
Box cut in half, non-physic: 0.500001 // saved value, correct
Full box, non-physic: 0.500001 // saved value, NOT correct

Third run:
Box cut in 1/4, non-physic: 0.500001
Physic box cut in 1/4: 0.707092
Physic box cut in half: 0.500009
Box cut in half, non-physic: 0.500001
Full box, non-physic: 0.500001

...
The results are unchanged in 2. 3. 4. ... run except for minor rounding differences

I have not tested other prim types and not linked sets, just a single BOX_TYPE prim --Dora Gustafson 13:05, 16 December 2010 (UTC)