Velocity is borked for models


#1

Setting velocity for models results in a surge of speed at every change, making the velocity settings quite unworkable.

However the same script using and Box entity instead of a model, behaves perfectly.

To reproduce:

Make a script that sets an initial velocity in one direction, then have it change (reverse) at a point back and forth like a pong game.
Run the script with a Box entity then run the same script with a model, and note the difference in velocity behavior.

BTW it doesnt fault on the first leg which the velocity was set in the initiation of the model.
It begins to fal=ult after the first scripted change to the velocity.

Here is my example script

var START = {x: 1000, y: 1000, z: 1000};
var END = {x: 1000, y: 1000, z: 1030};
var turn = 0;
var speed = 30;
var properties = {
type: “Model”,
position: START,
color: { red: 0, green: 255, blue: 0 },
modelURL: “https://s3.amazonaws.com/hifi-public/marketplace/hificontent/Architecture/sketchfab/car.fbx”,
dimensions: {x: 2.7, y:1.6, z: 5.9},
lifetime: 160,
velocity: {x: 0, y: 0, z: speed},
damping: 0
};
var box = Entities.addEntity(properties);
var clear = true;
function move(){
var newProps = Entities.getEntityProperties(box);
if ((newProps.position.z >= END.z) && (turn == 0)){
newProps.velocity.z = -speed;
Entities.editEntity(box, newProps);
turn = 1;
}
else if((newProps.position.z <= START.z) && ((turn == 1))){
newProps.velocity.z = speed;
Entities.editEntity(box, newProps);
turn = 0;
}
}

Script.update.connect(move);


#2

It still sounds very much like the problem i see with my door. That’s only with soem luck open once. and after that you only hear by sound it’s doing something.

But moving, no ! So much broken in the last weeks. or months ?
Also other things are fixt ! Still, cannot do much right now.


#3

This sounds like a bug that I independently discovered today. I’m looking into it now.


#4

This bug should be fixed in PR-8133: https://github.com/highfidelity/hifi/pull/8113


Velocity behaves strangely
#5

Thank you @leviathan I look forward to testing this. (EDIT) Tested, it Works.

Meantime there is another issue related to velocity.

In and assignment client, if I run the same script, it does not update the position.
The object rezzes and travels in the direction of velocity forever and reading the position never changes from the initial position.
Even doing explicit “find” always finds the object and all its params but always returns the original position.

If I run a script that changes the position by hardcode, it will return the correct position, but it seems velocity does not register the new position to the AC.

Why does it not update the position?


#6

Adiran, the short answer is that the script-agent doesn’t run an entity simulation so it cannot integrate the object’s motion forward in its own data structure.

The longer answer…

It used to be (years ago now) that a naive integration of moving entities was done in the Octree data structure but when we added the Bullet physics simulation that logic was abstracted out into the EntitySimulation class interface . The interface-client got a PhysicalEntitySimulation (which wraps a Bullet simulation under the hood) and the entity-server (which is actually an assignment-client performing the entity-server role) got a SimpleEntitySimulation which can do simple kinematic integration but does not do any collisions or dynamics.

The script-agent (which is actually an assignment-client performing the script-agent role) does not yet have an EntitySimulation running in its main loop. So it gets the velocity property for an object but does not integrate the position over time. If we were to add a SimpleEntitySimulation to the script-agent then it could move kinematic entities just fine, but not dynamic entities with any reliability.

The entity-server will integrate dynamic entities forward as if they are kinematic, but relies on a present interface-client to “own” the simulation of such objects and to continually update their position/velocity whenever that info differs from the naive kinematic motion. Usually the interface-client will not try to own the simulation of regular kinematic objects since the entity-server and all other interface-clients can reliably integrate those forward. The script-agent is not currently equipped to “own” the simulation of any entity, which means the entity-server will reject position/velocity updates from the script-agent for any entity that already has a valid simulation owner… the script-agent would have to try to assert ownership before its position/velocity updates would be accepted.

We don’t have any definite short-term plans on fixing this, however in the long-term we’ll probably give the script-agent a SimpleEntitySimulation so it can move kinematic things and in the Glorious Future we would give it a real PhysicalEntitySimulation and also have it subscribe to the avatar-mixer so that it can fully own the simulation of dynamic entities – essentially a renderless interface-client.


#7

Thanks Andrew for the detailed reply, I love details even if its bad news. At least I can stop pulling my hair out now.

Sadly this kind of limitation is going to make it really hard to present any complex scripted animations in a real persistent sense. Using constant position updates is really hard on the system to a point of not scaling at all.

If the system never knows where an object is once its launched, then life just gets random. Oh well there goes our vehicle simulation onto the back burner. (aww just got the cars looking and moving nicely using velocity thanks to your fix)

Thanks again for the info.


#8

Hmm, something is telling me not to spend to uch time then on moving verhicle script, when i got the right mind for it.

A bit confused to, because i think you can perfect read the position. but i never worked AC based. My door read the position back.


#9

@leviathan, that was a great response, exactly the information and design choices that were made, which I needed to know to determine what to do next. I strongly urge fixing things so that untethered/unmanned vehicles/creatures, with their scripts having to run in an AC do have access to dynamic physics.

Now knowing the limitations of kinematic-only movement for a huge class of artificial life experiences, it means I will have to revert to doing unmanned vehicles (creatures, etc.) to the way I used to do it 2011 when there was no decent physics engine in the many OpenSim grids. I am going to have to do the movement dynamics kinematically with exponential ramping, decaying, pseudo collisions all scripted frame by frame. It looks pretty good at 10-20 simulated physics frames per second, just not the lush silky movements of 64FPS physics, and too, it tends to drive up the message rate of all the clients viewing such animated virtual creatures or autonomous vehicles.

This ancient script simulates exponential ramp/decay, vertical attractor, gravity, dynamic and static friction on a 10fps scripted simulated physics loop:

Flying creatures using frame by frame scripted physics at 20FPS:


#10

It turns out it is not that bad. I used to do frame by frame simulated physics. At 20 scripted steps per second the motion was decent enough, and the 20 messages per second was not at all difficult on the viewers.

I would prefer 64FPS physics engine simulation and the message optimization of interpolation, but I’d guess I could exploit velocity interpolation to reduce the message rate. It’s just a shame that the core physics engine is unreachable for all use cases.


Persisting scripted behaviors