How would you marry Zay-ES and the jME3 physics API? I just want the basics of having a terrain(heightmap) as a RigidBody and CharacterControl for the players. Basically, I just want to have ground collision, gravity, step height and jumping.
I thought of just attaching a CharacterControl to my spatial but then it would override the Movement system which uses the position component since the CharacterControl directly controls the spatial.
How to implement jME physics in an entity system architecture? or do I have to make my own physics system? (don’t really want to, but if I have to, any advice on implementation is welcome)
The physics system becomes the movement system, basically. It takes inputs, applies them to the rigid bodies, integrates, and then publishes the results as components.
…the only question is how efficient you want the publishing of position to be.
In Mythruna, I publish position two ways… one as a regular Position component containing location + rotation. Another into a mutable component that keeps a thread-safe recent history that can be easily interpolated. The second I update once a frame and the first I only do once a second or so.
For many applications, just publishing a Position component every frame is probably good enough.
You are right. I can have a PhysicalMovement system which gets entities with Position, Velocity, and PhysicalBody components. (Which is different from NormalMovement system for projectiles which is kinematic)
So this is how I would do it:
initialize - create physical bodies
takes input - check for changes of Velocity component (can come from user input or AI)
applies them to the rigid bodies - body.setWalkDirection(Vector3f)
(I guess I have to ditch CharacterControl and go straight to physical bodies (PhysicalCharacter?) since Controls in jME directly access the spatial which is I think very anti-ES.)
integrates - ???
publishes the results as components - creates a new PositionComponent based on location of the physical body (which is then picked up by the Model system that should move the spatial around and not Controls)
Is this right?
I don’t understand about the “efficiency of publishing position”. Is this concerned about network latency? Maybe I will get there someday.
@pspeed said:
The physics system becomes the movement system, basically. It takes inputs, applies them to the rigid bodies, integrates, and then publishes the results as components.
…the only question is how efficient you want the publishing of position to be.
In Mythruna, I publish position two ways… one as a regular Position component containing location + rotation. Another into a mutable component that keeps a thread-safe recent history that can be easily interpolated. The second I update once a frame and the first I only do once a second or so.
For many applications, just publishing a Position component every frame is probably good enough.
ARe ther any reason you decided to go that way? I currently have a interpolation System running, that takes those raw values, and createds a interpolated position component out of it, once per frame. (Taking into account network delay, velocities ect)
@Empire Phoenix said:
ARe ther any reason you decided to go that way? I currently have a interpolation System running, that takes those raw values, and createds a interpolated position component out of it, once per frame. (Taking into account network delay, velocities ect)
The things are completely decoupled and running at their own rates. So one thing is pumping state into a (relatively short) buffer potentially with drops, etc. and then the visualization side is once a render frame requesting position and orientation as a particular time (at some adjustable delay) and then that’s interpolated before being applied to the spatial.
It’s a lock free design. Each FrameBufferComponent has a lock free round-robin data structure for some amount of history. One writer, potentially many readers. This way also seemed the most ES friendly without adding even another component.
You are right. I can have a PhysicalMovement system which gets entities with Position, Velocity, and PhysicalBody components. (Which is different from NormalMovement system for projectiles which is kinematic)
So this is how I would do it:
initialize - create physical bodies
takes input - check for changes of Velocity component (can come from user input or AI)
applies them to the rigid bodies - body.setWalkDirection(Vector3f)
(I guess I have to ditch CharacterControl and go straight to physical bodies (PhysicalCharacter?) since Controls in jME directly access the spatial which is I think very anti-ES.)
integrates - ???
publishes the results as components - creates a new PositionComponent based on location of the physical body (which is then picked up by the Model system that should move the spatial around and not Controls)
Is this right?
I don’t understand about the “efficiency of publishing position”. Is this concerned about network latency? Maybe I will get there someday.
integration is what the physics engine does to turn position + velocity + acceleration into new position + velocity.
The “efficiency of publishing position” is that you will be creating a lot of objects per second just to give everyone updates. It’s generally fine but Mythruna can have any number of objects so I need to make sure I can handle them efficiently. In my case, I avoid creating a new PositionComponent() per moving object every frame. What I’ve done is considerably more complicated, though. I even had a second opinion on my threaded data structures from a smart guy I used to work with because I do some strange things with volatile piggy backing and such.
best to just push new components if you can get away with it.
I wrapped the interpolated buffers into my Sim-Math library found here:
Specifically these classes:
It is used by my budding Sim-Ethereal networking library to provide position/rotation interpolation.
It’s virtually undocumented except internally but one other jMonkeyEngine user has managed to figure it out and use it. I think there was a thread here where I gave him hints along the way.