Request: Allow Avatar Physics to be turned off via Script


Been trying to dig information on this, but havent been able to find -any- info on this:
Its one of the few things thats stopping me in my script experimentation rush on vehicles and seats.:

Basically, If an Avatar is connected to an Entity (via MyAvatar.setParentID(uuid) ), and has a MyAvatar.getParentID() allow MyAvatar Collisions and Physics to be turned off via script. This would allow for avatars to be attached within a physical hull of a vehicle, and wouldn’t need consistent re-calculation of the avatar’s position and rotation (Just set positions and take over controls, thats it).

Entities clearly have a turn off Collisions with MyAvatar, but what if there are multiple users of that entity, but youd still want to collide with anyone not parented with this entity?

Of What is possible - Vehicles

Actually no, you do not want that. What you want is that when things are parented to other things, the composite hull is treated as a unit for the purposes of physics and generally collision. Nonetheless the individual parts still need to be passed collision events so that scripts in them can still react properly.


The only down side to locking it to the composite hull, is that if there is a moving platform, say a subway or an elevator, the avatars on the train cannot collide or move around as the object is moving about. Youd be “forced to sit down”. There wouldnt be any allowance to move about.

I think it should be the script’s possibility to either make the “user to sit (aka not able to move)”, or allow them to move around at their leisure (until they fall off it) This allows one to sit in a large moving vehicle, or move around within it. As soon as they stop colliding with the vehicle, then they can be considered to be off it.

If it is forced to behave as a single unit, then my gravity sphere wouldnt really work anylonger (as if you are parented to an object, and the object moves, you move with it)


In that case (and many others) sitting/parenting is not the proper way to go. What you want there is stiction. We implemented that in InWorldz. Ana avatar simply stands on an object and when it moves so do they.

Here is one example. The avatar is NOT sitting on that moving buoy, just standing. Ride-on is stiction that transfers momentum to a weak linked object. That should be implemented here in HF. That is how sldiewalks etc can be done.


The thing about stiction is that someone needs to implement it into the client if bullet supports it, and considering HiFis focus on HMD it is unlikely for them to add a new Physics Feature.

A simple toggle for allowing toggling of Avatar physics is a much quicker solution until that is implemented, while still supporting the ability to make stuff, such as my gravity sphere.

Right now the issue for just making a simple sit script is to avoid child avatars from colliding with the parent entity and be affected by the ‘gravity’ of anything else around them . Because if you put a cube that near a floor, and have a “sit” script in it there are issues: Set your position once, you will still fall onto the ground if the seat is ignoring your physics. If the seat has physics and it is rotated, you will slide off your seat even if parented to it…

When the avatar is parented to the object and the relative position is set to 0, and with avatar collisions off, the avatar will move when the object is moved.

I want to avoid having to set ones position every single frame, which is not the way to go. Easiest method I can think off is just to be able to turn off the avatar Physics via script, if they are parented to an object.

Server side the above can be mitigated by simply allowing specific objects to have child avatars via AssignmentClients.


I think what you are seeing are simply the lack of bug support for anything other than the MVP. We all just have to wait until that Occulugasm is over.

Stiction is seriously important, a first class feature.

Here’s another example of stiction (just watch the about 20 seconds):


I agree that is simpler, though what are the chances of anything being implemented right now that is not MVP related?


Smaller effort for the third party devs :slight_smile:


nice example vid. one question, are the pistons being pushed to make the crank shaft rotate? or is the crank shaft rotating and making the pistons move?


At the time that was done, there was a problem with object interpenetration when strong impulse forces happened. Though much better than the Havok engine in SL, that version of PhysX couldn’t handle a piston jamming into the crank shaft without sometimes punching through. So, in that segment, the crank is turning and dragging the pistons. It works well, and definitely does not work in SL. Truly would be nice if it worked in HF, though I do not know if Bullet can handle dealing with limiting interpenetration under extreme circumstances.


(see this thread for images )

Anyway, this is what now happens if you just happen to update the position once, and parent the avatar with the entity: with without updating position and rotation information ever after it starts moving. You can move around as longs the object doesnt rotate, but the avatar goes into “flying mode” (probably due to it estimating that in the next frame below is nothingness, which is another physics bug) and occasionally walking mode.

If youd want to make a seat on the moving object, youd have to turn off the collisions to allow the avatar to be on the relative position point, without being pushed off by the physics hull. otherwise needs to update the rotation and position constantly, which causes the stuttering seen in the “quick vehicle example”

Side note: if you go out of bounds of the domain, your client crashes (beyond ± 16km), because the entity disappears from underneath you, and when the parent entity goes missing, the avatar doesnt null parent.

It works if one parents their avatar to an entity, it actually works without stuttering. The issue rises from when you have to update the position and rotation if the collisions are turned on. Id just want to turn off the collisions so


Woohoo! @Menithal and I were in the sandbox domain having wild rides with entities :slightly_smiling:

He went off to sleep, so I’ll write up what we discovered, but the nature of he bugs are such that small targeted fixes can open up the ability to sit, ride, and have complex physical assemblies.

The first experiment was to see how an assembly of entities parented to another behave when physical. The first problem is that when you have such an assembly, the child objects do not inherit the parent’s physical properties, so very strange results occur. Second, when this is manually rectified (all entities of the assembly are made physical) they still interact, with respect to collisions and interpenetration, as if they were individual entities. But since they are linked, that too is observed in the simulation. The result is that two entities that are interpenetrated, when linked via parenting and then made physical, go into a never ending jitter spasm bouncing around constantly. When that assembly hits an avatar it packs quite the wallop.

Here again is the bug, linked entities must not have interpenetration or collision simulation between themselves.
A general case of this issue is that the linking relationship between a child and parent entities and/or child and child entiries requires parameters to define the interaction. It should range from no-interactions to some spring force & dampening factor for each local axis.

Do that and all of a sudden you get some very nice vehicle possibilities: the child tires of the parent car body will jiggle up and down slightly as the vehicle moves along the surface - all handled by the physics and physics framework code. But if that is too much then at the very least there needs to be a no-collision, no-interpenetration set of switches that apply to child entities.