Any difference in bandwidth etc. between moving by changing position or linear velocity?


#1

Is there really much difference in network bandwidth when you move a entity by changing the position. Or using the linear or angular velocity setting ?

Or are both options sending or reciecing the same amount of date.
Is there any other difference between moving by updating the position or anguler or linear velocity in terms of resources ?


#2

If you’re setting the position, each time you do so is an explicit packet you’re sending. However, if the object is being controlled via physics (i.e. linear or angular velocity) then it’s up to the physics subsystem to determine how often packets should be sent to update something about the entity.

I don’t know how often the physics system will send though. If it’s more frequent than a script would, then it would be more bandwidth consumed, otherwise less. I’m also unsure what triggers a physics property packet. In theory an object that’s moving linearly wouldn’t need any update packets at all for the current viewers because they’d all be executing basically the same simulation up until it collided with something else. However, since anyone can enter or leave a domain at any time, the physics system has to be updating the server position with the new entity data at some regular interval. I just don’t know what it is. Seth or Andrew would probably be able to be more informative.

However, there’s one other thing to consider… with physical properties, everyone will be doing their own local physics calculations, even though only one person will be considered the owner of the physics for that object and will be responsible for sending packets. That means that in theory, everyone should actually see the object smoothly updated every frame, whether they’ve received an update from the server or not.

If you want an object to smoothly follow a curve, then the best thing to do is probably to use a combination of physics properties and script updates. Setting a starting velocity and doing relative infrequent updates to acceleration should be able to give everyone viewing the object a nice smooth curve.


#3

Yes, there is a huge difference. It’s always more efficient to set the physics properties. You should never ever implement linear velocity or angular velocity in a script, that will always be less efficient then allowing the system to do the work for you.

In the case of linear and angular velocity, the property is set once. We remember where it was when it was set, and what time it was set (in a shared clock) this allows the server to tell all of the clients about this once… and all clients are able to perfectly simulate where the object is or what angle it is rotated at without sending/receiving more information.

If you are trying to simulate linear or angular velocity with a script, you will be setting the position and rotation constantly at a given frame rate… that will require an potentially infinite amount more network traffic.


#4

For the specific case that Richardus asked about… linear or angular velocity… It’s definitely going to be less.

The physics system will send a packet to “edit” the position whenever it determines that the ballistic trajectory simulated on the entity server is “far enough out of sync”. This usually only happens in the case of a collision, since the server doesn’t do collision detection (it only simulated ballistic trajectories. It’s also possible for the client to determine that ballistic trajectory of the server is slightly incorrect due to issues like friction and other subtleties not included in the servers trajectory calculations… but the headline is these changes are extremely rare.

So in general… you would expect to see approximately 1 update per collision event. This is far far fewer edits then would be required for a script to manually implement ballistic trajectories.

Actually - the fact that viewers come and go does not have any bearing on the frequency of physics updates. All viewers are all locally simulating, so they all know where the physical objects should be… they also know which of them is the “simulation owner” – if the simulation owner leaves then one of the other viewers will pick up the simulation.

There is a small window where multiple viewers will be bidding to become the simulation owner where you’ll see a slight increase in the number of edit packets (because each bidder is sending a packet to announce that they would like to be the owner). But this increase in packets is negligible and is certainly far less than the packets required to simulate a ballistic trajectory in a script.


#5

So that ruke is the same as i expected. But that make things more complicated.

How can i make the object make curve with dimension you choice ? Registration point is not working, because it’s limited.

Right now the only way i know to make nice curve is by using math and update it by changing the position. But i do not like the idea.

Or can we set the registration point below 0 and above 1.0 in the script. That would solve lot’s of problems.

I need this by physics, the distance from center would be more the 0.0 or 1.0


#6

here’s how you can do that…

To make a 0.1 radius sphere rotate cleanly from a center point that is 0.5 meters from it’s center, do the following…

  • Create a “box” (or sphere) - make it’s dimension {1.0, 1.0, 1.0}
  • Create your sphere and places it’s position on the corner of the box. (e.g. box positioned at 0,0,0, sphere positioned at 0.5,0.5,0.5)
  • Make the sphere a “child of the box” – get the ID for the box, copy it, paste it in the “parent” property of the sphere
  • now the sphere will stay attached to that corner of the box, and anywhere the box moves or rotates, the sphere will remain in that position relative to the box.
  • Give the BOX an angular velocity. The sphere will now appear to move in an arc staying fixed on the corner of the box.
  • You can make the box invisible and collisionless and it will be as if it’s not there at all.

#7

OK…

That sounds like a pile of extra javascript code. and reallt parent and child stuff i first need to read about. Also i need to move the child on the fly from left to the right side. depends on the curve.

This is going to be a very slow idea to deploy now :worried: Nah, the wheater is against me too. I finaly will figure it out. Not sure how fast.

I hope i can find some examples.
http://jsref.docs.highfidelity.com/docs/entity-properties


#8

You can also do individual edits… but it will always mean more network traffic and more load on your servers.

There are trade offs to everything.

The technique I’ve described gives you the specific feature you requested… it basically gives you “registration points outside of the bounds of the object”…

Of course, we will continue to look for more ways to allow easier techniques for more complex interactions… but I wanted to give you an answer you could use today.


#9

Thanks, tried the parent / child setup inworld.
Why did i not done testing with it sooner :slight_smile:
Now it’s possible to implement it script side now i understand it.


#10

Here’s an example of a script that creates a sun and the first 5 planets, along with a moon for earth:

http://s3.amazonaws.com/DreamingContent/scripts/SolarSystemBuilder.js

Note that it creates the sun at 1/10th its actual scale, and the child boxes used for rotation are set to visible here, but you could easily tweak that.


#11

I did this on Earth domain. Go look at the The London Eye.


#12

Yes, frame by frame positional movement can be expensive although I did find it OK at 20FPS, but that is not high fidelity physics movement.

@ZappoMan and others, I encourage you to view this video which shows the complexities of high fidelity virtual physics. I just made this in the InWorldz grid which uses PhysX and my vehicles grid code. There is a ton of message optimization, taking advantage of the client viewer’s velocity and acceleration interpolation. Optimizations are critical but, nonetheless, a lot of messages are sent anyway.

It is only in rare cases that an object’s velocity will be constant or its acceleration will be constant for a long time. For constant velocity, the movement is quite unreal (low fidelity). For constant acceleration it is when an object is falling in a gravity field. Since decent physics engines simulate friction, damping or ramping force adjustments in exponential time, there will be some messages being sent most of the time. We live in a world of variable acceleration which should be mimicked virtually.

Now, yes, since each client runs local simulations of objects, the only time that corrective messages need to be sent is when the simulation owner physics engine detects DV or DA changes (collisions or other hyper-acceleration effects). It has to do that because the non-owners are simulating without collisions and without knowledge of other changes. Also consider that the clocks of the clients are running independently and that other thread activity can perturb the clients’ physics stepping rate (this is not hypothetical - I had to deal with it in another grid). So, the simulation owner needs to send out position, velocity, acceleration corrections at some minimum rate to ensure everyone stays in sync. It also has to send position, velocity, and acceleration corrective messages to all non-owners whenever collisions or any DV/DA changes occur.

So, how often would this happen?

  • free space fixed velocity - minimally, enough to keep clients in sync
  • rolling along a terrain mesh - often, 20+ per second, myriad collisions, bumps, skids along the surface mesh
  • flying - moderately - wind effects, collisions

Also, HF totally lacks some basic higher level physics abstractions that require tons of javascript programming. This really needs to be addressed to make physics in High Fidelity really high fidelity.


#13

My brain started to run on low clock speed. That happens sometimes.

I try to figure out how to change parameters of the child entiry.
I would say use the ID from the child and change the required parameters.
Except that am not sure how t retrieve the ID from the child, the script is running in the parent.


#14

@Richardus.Raymaker There’s a new JavaScript method, Entities.getChildrenIDs() which may be of use.


#15

Nice, except that there’s no documentation on the docs page about this command. And without some documentation it’s hard to know how to correct implement it.

I want to modify my findentities example, because thats close to how Entities.getChildrenIDs() work. Except i do not have the paramneters Entities.getChildrenIDs() need and give.

Properties list for Entities.getChildrenIDs() would be nice to have.
@ctrlaltdavid, it’s not Entities.getChildrenIDsOfJoint ?


#16

@Richardus.Raymaker

childrenIDs = Entities.getChildrenIDs(parentID);

Pass in the UUID of the parent entity and you’ll get a list of its children. (But like other Entities operations, you’ll only get the IDs of children that have been loaded into your local copy of the entity tree, i.e., that you have “viewed”.)

Note: Is available in dev builds 4992 and later; isn’t in latest “release” build 4970.


#17

Ohh, ok. i changed the code. But ill need to wait for the next beta. hope it comes soon.


#18

Functional example:

let’s suppose I have lights you’d find at a night club. In English these are called “can lights” because they look like soup cans. I want those can lights to ya know, rotate and move around on a pivot, etc… is it ok to set their initial rotation velocity via script at the time the show begins? I wouldn’t want them rotating prior to, and subsequently after, the showtime.

I’d like to get coding on this sometime next week, so let me know how you would go about this.


#19

@KevinMThomas had revolving lights working till something changed


#20

They still do. But they revolve automatically. Initial rotation is set on the entity. I’d like to control that via script. But it might be against recommendations. Hence the question @ZappoMan I am actually anticipating a “greenlight go ahead” for a simple initial velocity. What I think he is referencing is setting and updating such values on an update event. That could lag out an event as it is essentially the exact opposite of what you want to integrate.