llOverrideMass(float new_mass);
tracked
Atomic Infinity
The mass of objects is kinda messy. Measured by density and volume of the object, measured in Lindograms. Avatars have disproportionate mass compared to objects, and those objects report unusual results when child prims are involved (bug in recalculating mass that only resolves with unlink/relink), and mass does not take into account when parts are set with no physics. Overall volume is measured based on a bounding box, which may well be far larger than the visible mesh object.
Trying to influence mass by scripted changes to object volume and density don't work reliably due to the child prims issue, and once you sit an avatar on something its mass can be affected far more than it really should be, or not enough.
Obviously changing existing mass in the physics engine is likely out of the question so we don't break every mass-dependent object ever made, so how about we get a function to override it?
If we could use something like llOverrideMass(float new_mass); then the scripter can confidently use physical forces and functions with predictable results.
In objects it would define the mass of that object/linkset regardless of changes to its child prims or avatars sitting, and in attachments it could be used to stablise avatar mass to a known value independent of how tall they are.
edit : I guess a mass override in a sat-on object needs to take precedence over one in an attachment of the sitter.
Log In
Activity Feed
Sort by
Atomic Infinity
An update for anyone else out there who has been baffled by values given for mass in linksets adjusting density :
If you make a new two-prim object, and get it to report llGetMass() it will give you the correct result. If you then change the objects Density, either by script, or manually in the edit window, this is where the biggest problem lies. Density
should
be a single value for a whole linkset.Setting a new density actually only takes hold on the root prim. The child prims retain their previous density. So if you now again get it to report mass, the value is wrong. It will be the sum of the root prim mass at new density, plus the child prim mass at the previous density.
You can however force it to update. If you move, scale, or rotate a child prim (either by script or manually) this prompts the object to update, and all the child prims will adopt the density of the root prim.
Ask it llGetMass() again, and the number will make sense.
Then there is the "I'm sitting on it" problem. The act of sitting or standing from an object is enough to trigger the object to update, giving it one density throughout. BUT while sat avatars are child prims, they never change density. So if you want to know/modify mass with a sitter, bear in mind the mass of the sitter will be a further glitch in your numbers.
Knowing what is wrong with it makes it not that hard to workaround. It just took a while to figure what was wrong with it!
:D
Spidey Linden
tracked
Issue tracked. We have no estimate when it may be implemented. Please see future updates here.
Nexii Malthus
Being able to modify the center of mass would also be huge — llOverrideCenterOfMass
There are many inconsistencies in physical behaviour in many objects that could be resolved. Vehicles are specially sensitive to the mass center, we can already control the motor position, so makes sense to be able to change that too. I'm sure there are non-vehicle or adjacent fixes that could be made as well thanks to that.
Nelson Jenkins
Just curious, what's the use case here now that llSetVelocity and llSetAngularVelocity exist? The only thing I can think of is maybe the physics engine relies on mass for collisions?
Atomic Infinity
Nelson Jenkins Hi :) from experiments the mass of a physical object is taken into account along with the other material/gravity/bounce options when the physical object moves, whether it moves by applied forces, or by SL gravity. Objects with higher mass will dominate a collision with a lighter one.
From my own projects it is noticeable in vehicles (using the Vehicle system functions) as the mass influences the linear and angular motor reactions and decays in the 'momentum' of the object. We don't use the llSetVelocity llSetAngularVelocity in them as the vehicle system functions have more elaborate options.
We race vehicles, and when a large avatar has to re-size their bike to fit, they end up having a much higher mass and their bike behaves in a noticeably different way.