Hi
I'm trying to find a place to hook the code where I synchronize the graphics and physics objects. My physics objects are kinematic, in the sense they follow the graphics using MoveTo. Would subclassing BroadPhase preUpdate be the best place? As I have many entities, I don't want to update them unnecessarily, only when physics is about to start a new frame calculation
PreUpdate
Re: PreUpdate
I would recommend creating a subclass of Updateable and using one of its four "stages;" during forces, before collision detection, end of update, and end of frame. Using the earliest "during forces" stage would perform the movement before the broadphase is run.
Re: PreUpdate
I'm not too sure how to proceed with this as the sample I see is using static groups or vehicles. I'm keeping things simple, just to have an Entity. So I presume
- I create a subclass of Updateable that holds the Entity
- Do I use Space.add (Updateable)? Do I still need to add the Entity to the Space too?
It seems that Space keeps a list of Updateable, so I presume I would need to manage the updateable ? e.g when I remove Entity, I must remove the Updateable too? How do I keep track of them together, my .tag is already used to bind to my graphics side.
- I create a subclass of Updateable that holds the Entity
- Do I use Space.add (Updateable)? Do I still need to add the Entity to the Space too?
It seems that Space keeps a list of Updateable, so I presume I would need to manage the updateable ? e.g when I remove Entity, I must remove the Updateable too? How do I keep track of them together, my .tag is already used to bind to my graphics side.
Re: PreUpdate
Architecturally speaking, Updateables are indeed added to the space using (Space).add(Updateable updateable). This will only add the updateable to the space, and not anything inside of it, so if you add an entity to some list inside of the Updateable and want it to be updated by the engine, you will have to also add it to the space using (Space).add(Entity entity). Updateables in the space have their methods called by the engine when the space.update method reaches the appropriate stage.
One possibility would be to make one updateable that can be thought of as a kinematic motion/animation 'player.' A single instance of this updateable would be added to the space. Entities, or maybe just a game object which contains an entity and any required motion information (a curve or continually updated path or goal), would be added to this updateable.
The updateable, during one of its update stages, could iterate over its managed entities and update their velocities/positions according to the path information associated with them. If one of these objects is no longer present in the world, you can remove it from the updateable. Any entities that should no longer be in the space (or that should be otherwise modified on 'removal') would need to be handled separately.
There's also another factor to keep in mind when moving kinematic objects. While an object can be used using (Entity).move and (Entity).moveTo, neither of these methods adjust the velocity of the object. They can be thought of as teleporting the entity. So, if you need collision response to be correct against a teleporting kinematic entity, you should assign velocities which are close to the velocity that would have been used to perform the motion.
One possibility would be to make one updateable that can be thought of as a kinematic motion/animation 'player.' A single instance of this updateable would be added to the space. Entities, or maybe just a game object which contains an entity and any required motion information (a curve or continually updated path or goal), would be added to this updateable.
The updateable, during one of its update stages, could iterate over its managed entities and update their velocities/positions according to the path information associated with them. If one of these objects is no longer present in the world, you can remove it from the updateable. Any entities that should no longer be in the space (or that should be otherwise modified on 'removal') would need to be handled separately.
There's also another factor to keep in mind when moving kinematic objects. While an object can be used using (Entity).move and (Entity).moveTo, neither of these methods adjust the velocity of the object. They can be thought of as teleporting the entity. So, if you need collision response to be correct against a teleporting kinematic entity, you should assign velocities which are close to the velocity that would have been used to perform the motion.
Re: PreUpdate
It seem to be that Updateable may not besuitable, since it's more like a container to hold Entity's. What I'm (hope to) looking for is a callback at BroadPhase before the forces are calculated. As I have a lot more kinematic objects than dynamic, I will just iterate over all the entities in Space, and adjust their positions to match. It seems performance and memory will be better than creating another Updateable to manage the sync.
Regarding the velocity part and moveTo, I read it in another post, and I have some question. Since kinematic do not calculate physics forces acting on it, so you mean the velocities are used when other objects colliding with it? I'm thinking why can't this velocity be calculated internally from the buffered position when MoveTo is called.
Regarding the velocity part and moveTo, I read it in another post, and I have some question. Since kinematic do not calculate physics forces acting on it, so you mean the velocities are used when other objects colliding with it? I'm thinking why can't this velocity be calculated internally from the buffered position when MoveTo is called.
Re: PreUpdate
Using Updateables would not have any additional meaningful overhead compared to using a Broadphase prePositionUpdate; there would be one instance of an Updateable which would give you access to a particular stage in the space update method. You can iterate through all of your entities within this Updateable's update method as if it were nothing but a callback from that stage in the pipeline. This is essentially equivalent to what you want from the broadphase pre-update, but the broadphase pre-update is likely in a less optimal location (as it comes before the entity position update, not close to where the frame begins).
Kinematic bodies can use velocities in two ways.
They can use it to move themselves (if you aren't overriding it by ordering them to move to certain locations). If you gave a kinematic body a linear velocity of (0,1,0), it would move up at the rate of 1 unit per second as expected.
Secondly, in a collision, the relative velocity at a contact point is necessary to resolve the collision. When an entity is only teleporting, this velocity could be stationary despite what appears to be continuous motion due to very small incremental teleports. A cube on such a 'stationary teleporting' platform would not be pulled along with the platform, but rather appear to slide off with no frictional forces. With a correct velocity, however, the cube would be pulled along by friction.
The only reason move/moveTo/setting centerPosition or internalCenterPosition don't change velocity is that they are intended to be teleportation only. Sometimes, you don't actually want to change the velocity, so it's good to have the option to not do so. Obviously there could be a different function or some parameter which could make this distinction (which might be added), but it's fairly trivial to overcome either way.
Kinematic bodies can use velocities in two ways.
They can use it to move themselves (if you aren't overriding it by ordering them to move to certain locations). If you gave a kinematic body a linear velocity of (0,1,0), it would move up at the rate of 1 unit per second as expected.
Secondly, in a collision, the relative velocity at a contact point is necessary to resolve the collision. When an entity is only teleporting, this velocity could be stationary despite what appears to be continuous motion due to very small incremental teleports. A cube on such a 'stationary teleporting' platform would not be pulled along with the platform, but rather appear to slide off with no frictional forces. With a correct velocity, however, the cube would be pulled along by friction.
The only reason move/moveTo/setting centerPosition or internalCenterPosition don't change velocity is that they are intended to be teleportation only. Sometimes, you don't actually want to change the velocity, so it's good to have the option to not do so. Obviously there could be a different function or some parameter which could make this distinction (which might be added), but it's fairly trivial to overcome either way.
Re: PreUpdate
Ah... I get it about the Updateable. Thanks for clear explanation.