Server weight recalculated wrong
needs info
Vent Sinatra
When resizing, and possible other changes, the server weight of an object gets recalculated incorrectly. Making an object smaller can increase the server weight. It seems that each script counts for 0.25 except the first. After resizing the first script counts for 0.25.
At hand I have a mesh object consisting of 2 prims, and 2 scripts. Server weight is initiatially 1.2(5), but this jumps to 1.5 after a change such a resize. The land impact goes from 1 to 2 .
Log In
Maestro Linden
Vent Sinatra can you clarify what your test setup is, so we can evaluate if the weight calculations appear to be erroneous?
I wrote a quick and dirty LSL script which reports the weights across a series of scales (0.1 to 10m per side), which is shown below.
With a default cube prim, I'm not seeing any variance in weights or land impact over the scale range:
Default cube prim:
Scale: <0.10000, 0.10000, 0.10000> LI: 1 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 0.050000 PHYSICS WEIGHT: 1.000000
> Scale: <0.20000, 0.20000, 0.20000> LI: 1 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 0.050000 PHYSICS WEIGHT: 1.000000
...
Scale: <10.00000, 10.00000, 10.00000> LI: 1 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 0.050000 PHYSICS WEIGHT: 1.000000
Script source:
string showLIWeights()
{
list d = llGetObjectDetails(llGetKey(), [OBJECT_PRIM_EQUIVALENCE,
OBJECT_SERVER_COST, OBJECT_STREAMING_COST, OBJECT_PHYSICS_COST]);
return "LI: " + llList2String(d, 0)
+ " SERVER WEIGHT: " + llList2String(d, 1)
+ " STREAMING WEIGHT: " + llList2String(d, 2)
+ " PHYSICS WEIGHT: " + llList2String(d, 3);
}
default
{
state_entry()
{
float sizeScale = 0.1;
integer multiplier;
for(multiplier = 1; multiplier <= 100; multiplier++)
{
vector scale = <sizeScale, sizeScale, sizeScale> * multiplier;
llSetScale(scale);
llSleep(1);
llOwnerSay("Scale: " + (string)scale + " " + showLIWeights());
}
}
}
Maestro Linden
With a mesh object that uses non-convex physics, there is quite a large variation in LI over scale. For example, I imported duck.dae from https://github.com/KhronosGroupArchives/glTF-Sample-Models/tree/main/sourceModels/Duck and switched it to use the 'low LoD' model as its physics shape.
The range in LI is dramatic, with small scales either being very cheap (because the object is too small to simulate as a mesh, and instead treated as a basic box by the physics engine) to very expensive:
Duck mesh (prim physics, using low LoD render model):
Scale: <0.10000, 0.10000, 0.10000> LI: 8 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 8.141192 PHYSICS WEIGHT: 0.100000
Scale: <0.20000, 0.20000, 0.20000> LI: 8 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 8.158104 PHYSICS WEIGHT: 3.760000
Scale: <0.30000, 0.30000, 0.30000> LI: 8 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 8.187765 PHYSICS WEIGHT: 3.760000
Scale: <0.40000, 0.40000, 0.40000> LI: 8 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 8.229289 PHYSICS WEIGHT: 3.760000
Scale: <0.50000, 0.50000, 0.50000> LI: 547 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 8.282680 PHYSICS WEIGHT: 546.851700
Scale: <0.60000, 0.60000, 0.60000> LI: 456 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 8.347935 PHYSICS WEIGHT: 455.709700
Scale: <0.70000, 0.70000, 0.70000> LI: 391 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 8.425052 PHYSICS WEIGHT: 390.608300
...
Scale: <9.70000, 9.70000, 9.70000> LI: 47 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 46.544910 PHYSICS WEIGHT: 28.188230
Scale: <9.80000, 9.80000, 9.80000> LI: 47 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 47.082040 PHYSICS WEIGHT: 27.900590
Scale: <9.90000, 9.90000, 9.90000> LI: 48 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 47.624680 PHYSICS WEIGHT: 27.618770
Scale: <10.00000, 10.00000, 10.00000> LI: 48 SERVER WEIGHT: 0.750000 STREAMING WEIGHT: 48.172820 PHYSICS WEIGHT: 27.342580
We can see that while the streaming weight is small for small scales and gradually grows as the object grows, the physics weight starts off as very expensive, due to the triangle density issue I mentioned, and gradually gets cheaper as it increases in size. The net effect on LI is a U-shaped curve.
Maestro Linden
updated the status to
needs info
Maestro Linden
Hi Vent Sinatra, land impact for mesh objects is comprised of 3 different weight components, which are described here:
While a component like download weight should generally downscale as an object decreases in size, the physics weight can actually increase. This increase is because a higher density of triangles in the collision shape makes physics calculations more computationally intensive. An (approximate) formula for physics weight is shown at https://wiki.secondlife.com/wiki/Mesh/Mesh_physics - the "volume of bounding box" value decreases when you shrink the object, causing the weight to increase.
While you might be seeing expected behavior, we can investigate your particular object. Please let us know where we can find a copy of it, or send a copy over to me.
Vent Sinatra
Maestro Linden the effect happens on a prim cube as well, and I looked at the server weight individually, not only on the LI itself. Happy to send you test object though.
Vent Sinatra
The error shows in your output already. The server weight should be a constant 0.5 with only one script in the object ? In fact that is the case before llScale is called:
string showLIWeights()
{
list d = llGetObjectDetails(llGetKey(), [OBJECT_PRIM_EQUIVALENCE,
OBJECT_SERVER_COST, OBJECT_STREAMING_COST, OBJECT_PHYSICS_COST]);
return "LI: " + llList2String(d, 0)
+ " SERVER WEIGHT: " + llList2String(d, 1)
+ " STREAMING WEIGHT: " + llList2String(d, 2)
+ " PHYSICS WEIGHT: " + llList2String(d, 3);
}
default
{
state_entry()
{
float sizeScale = 0.9;
integer multiplier;
vector scale = llGetScale();
llOwnerSay("Scale: " + (string)scale + " " + showLIWeights());
llSetScale(scale*0.9);
llSleep(1);
llOwnerSay("Scale: " + (string)scale + " " + showLIWeights());
llSetScale(scale);
llSleep(1);
llOwnerSay("Scale: " + (string)scale + " " + showLIWeights());
}
}