[Solved] Sim-eth-es position vs. bodyposition (model vs. mob container)

User Code & Projects zay-es
1

Hi

Was wondering, how you keep the players position vs. bodypositon seperated. You write in the ModelViewState that care should be taken if entities exists in both the Mob container and the Model container. And since you use BodyPositions on the players, as well as enter them into the game with a Position, then they are in both containers - Is therer any way I can get around this? Did you get around it by initiating the ships with components in some specific order? I’m seeing hiccups in the graphics due to this issue (when I’m creating bombs/bullets).

The BodyContainer in SimplePhysics is based on Position, Mass, Shape, then adding a body. Wouldn’t that make all physical objects appear both in Mob and Model container in the view?

Kind regards,
Asser

2

To be more specific, the hiccup is happening at the very start of some physical moving entity appearing. As if the position is first shown, then adjusted once physics has been calculated. This may be the case, but I’m unsure how to get around it.

3

What kind of a hiccup? describe it?

position vs bodyposition just deals with static vs moving objects.

I create alot of bullets/mines and have had no issues with hiccups unless I’m overlapping physics when pieces are created. Like if you create something and place it ontop of another something one of them will bump around when they start colliding with each other.

Mithrin

4

Its like its not moving at first (and we’re talking perhaps 100 ms). Perhaps its the clamping from the PositionTransition buffer - because there are no buffers back in time…

5

I can get rid of the bug if I disable updating the mobs based on transitions (then the modelviewstate only uses the Model-container to update positions). This just to show, but of course that wrecks the physics based movement.

I logged spatials and positions. Seems my Position and BodyPosition is not the same.

Pasted image1681×953 99.5 KB

I’ll dig deeper and see why they are not in sync…

6

I have not experienced any problems related to this.

Mithrin

7

I’m guessing im not synchronzing correctly. Will be back.

8

Part of the problem is that position and body position are not supposed to syncronized.

Position is for static objects is static it never updates your only supposed to set it once. It will never match bodyposition unless your hack some stuff on to make it.

9

Yea. I know. I’ve just been getting ahead of myself :slight_smile:

10

I thought the code already took care of not displaying mobile objects until they were visible. It’s been a while, but all mobile objects will also have a position but the model view state should see these both right away. You are right that it will take 100 ms or so before the mobile objects start seeing their first updates.

There is some trick for making them invisible until the first updates come but I don’t remember exactly what it is. Visibility is part of the state built into the transition buffers, though. So it might just be making sure things initialize to invisible.

Edit: I left out that the model view state should also be detecting the case where they are in both containers… since you are right that mobile objects always will be.

11

Yea. Thanks both.

I had messed up the physics system though, so i’ll go over it again.

12

Solved it by re-implementing the Dyn4j framework, check thread here: [Solved] Dyn4j physics integration, and Zay-ES

13

Small bug left. Can’t seem to get rid of it, perhaps you can shed some light on it for me @pspeed:

The first three iterations of PositionTransition returns the same position for my physical objects. Is that because the BodyPositionCache is initialized with size 3, and the data is just all the same in that initialization?

13:20:19,180 INFO [ModelViewState] PositionTransition (bomb:EntityId[90]): (-1.6395035, 32.77743, -4.5776367E-5), (2.4425983E-4, 2.4425983E-4, 0.025152683, 0.9995117)
13:20:19,196 INFO [ModelViewState] PositionTransition (ship:EntityId[65]): (-1.4791609, 29.565338, -4.5776367E-5), (2.4425983E-4, 2.4425983E-4, 0.025152683, 0.9995117)
13:20:19,196 INFO [ModelViewState] PositionTransition (bomb:EntityId[90]): (-1.6395035, 32.77743, -4.5776367E-5), (2.4425983E-4, 2.4425983E-4, 0.025152683, 0.9995117)
13:20:19,213 INFO [ModelViewState] PositionTransition (ship:EntityId[65]): (-1.4848785, 29.677406, -4.5776367E-5), (2.4425983E-4, 2.4425983E-4, 0.025152683, 0.9995117)
13:20:19,213 INFO [ModelViewState] PositionTransition (bomb:EntityId[90]): (-1.6395035, 32.77743, -4.5776367E-5), (2.4425983E-4, 2.4425983E-4, 0.025152683, 0.9995117)

It becomes really obvious when my player entity is moving and firing at the same time, because the projectiles stands still the first 50 ms and the player is moving.

Edit: Printout is entity name, position and orientation

14

Well, I can get logs of five update-loops in ModelViewState that returns the same PositionTransition buffer, so its not because of the intialization (which I found out was set to null on init). Perhaps because of the timeframe that’s called and the ‘lag’ between updates of server/client EntityDate?

15

It’s because you are viewing history and haven’t caught up to the events that are moving that object yet. That’s why I suggested that when the object is first created, it needs to be invisible. The first real movement event will then make it visible.

The model view state then needs to make sure to obey the visibility flag from initialization. (It may already, I don’t remember.) That way the object doesn’t appear until that point in history.

16

Is that what you are referring to in SharedObjectUpdater ?

/**
 *  Updates the entities local position from network state.
 *  Requires that the entity have the BodyPosition component
 *  to accumulate state history for some backlog.  Updates to
 *  entities without a BodyPosition will be ignored... the alternative
 *  would be to cache a BodyPosition in advance until we finally
 *  see the entity.  This will be necessary if strict starting visibility
 *  is ever a requirement as the message that updates the entity's component
 *  may come some time after we've been recieving valid updates.  Enough that
 *  we'll be missing some history.  (For example, a missile might look like
 *  it starts a bit down its path.) 
 *
 *  @author    Paul Speed
 */

I have no idea on how to cache a BodyPosition in advance though :slight_smile: I guess I can live with it for now.

17

No, that’s referring to the complete opposite case… where you’ve been receiving history over UDP before you’ve ever seen the TCP BodyPosition component. You would lose that history.

I was pretty sure the sim-eth-es example already handles this case though there is no test for it. I copied most of the code from a 2D space game that actually did handle this (the visibility flag was put into the transition buffer precisely for this use-case). I haven’t looked at the code in a while, though… and as said, missiles were never added to sim-eth-es so there is not way to see it working.

It’s possible I never migrated the support for it.

ModelViewState is already setup for it:

Fixing this could be as simple as making BodyPosition.initialize() add a time=0, visibile = false frame. (Positions will interpolate strangle up until real history starts but they will be invisible until then.) Glancing through the code really quickly, I can’t see how the initial visibility state is ever properly setup so I may have not migrated that code.

18

Allright, thanks for checking.

All I can see is that visible = true is set in updateBody in BodyPositionPublisher, with no regard for a parameter.

I’ll try your suggestion.

19

BodyPositionPublisher’s updates are only used on the server… so if you had AI or something then it could get accurately interpolated positions, too.

The thing that takes physics data and publishes it over the network is:

It doesn’t deal with visibility directly but it’s generally assumed that objects moving in the zone are visible. That’s why (in theory) adding an invisible starter frame on the client’s transition buffer will mean that it will be automatically invisible until the first real event comes in (that will make it visible again).

It’s about making BodyPosition’s history accurate. So if you ask for “give me the visibility of time t” and t < firstRealEvent… then it will return false.