call to event entity.PositionUpdated

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
PSVWizard
Posts: 11
Joined: Fri Aug 02, 2013 11:57 am

call to event entity.PositionUpdated

Post by PSVWizard »

Hi there,

I've registered an event handler to the event entity.PositionUpdated.
However, while calling the update method once a frame like this: World.Update(dt); where World is my Space. The event is fired for the same object where the object does have very slightly different positions. As I do recreate shadow volumes for those object dependend on their position I would perform unnecesary stuff. I had assumed this event is fired when the final position of the object is known.

However the question would be: Is there a similar option to know the physics update has finished and the position is finally updated to trigger dependent actions?

BR PSVWizard
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: call to event entity.PositionUpdated

Post by Norbo »

I had assumed this event is fired when the final position of the object is known.
This is correct; the event fires when the state of an object is known. The position update occurs once per time step.

The Space.Update(dt) tells the space to simulate as many time steps of length Space.TimeStepSettings.TimeStepDuration as it can to simulate the accumulated time. So, one call to Space.Update may cause multiple time steps. In contrast, Space.Update() without a parameter always simulates exactly one time step.
However the question would be: Is there a similar option to know the physics update has finished and the position is finally updated to trigger dependent actions?
In this case, because the PositionUpdated event is fired from a multithreaded context, I would recommend just waiting until after Space.Update finishes. Then, update the graphics by reading the position/orientation from entities. This gives you complete control over when the logic happens, avoids doing extra work for internal time steps, and avoids any asynchronous access issues.
PSVWizard
Posts: 11
Joined: Fri Aug 02, 2013 11:57 am

Re: call to event entity.PositionUpdated

Post by PSVWizard »

Hi,

thanks for clarification.

However, I'd assumed in case I'm not able to guarantee a fixed update timing. I should use the Update(dt) method to ensure the physics engine steps exactly the time forward the rest of my game engine steps as well. In case I would set Space.TimeStepSettings.TimeStepDuration to dt and after this call Update() should than do the trick, only updating once?

From a performance point of view I would not like to run through all physics bodies that might be active to check whether position was updated and update attached drawables as well. I like the eventing updating the positions of the drawables only if the physics object really has changed its position or orientation.

BR PSVWizard
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: call to event entity.PositionUpdated

Post by Norbo »

However, I'd assumed in case I'm not able to guarantee a fixed update timing. I should use the Update(dt) method to ensure the physics engine steps exactly the time forward the rest of my game engine steps as well.
Update(dt) is indeed used to handle variable time steps. You can still use it.

You can hook to the Space.EndOfTimeStepUpdateables.Finishing event to know exactly when a time step completes within a multiple-timestep Update(dt) call, but it's usually easier to only update graphics after the full Space.Update completes.
In case I would set Space.TimeStepSettings.TimeStepDuration to dt and after this call Update() should than do the trick, only updating once?
The TimeStepDuration should not be changed every frame to handle variable time stepping. Doing so will introduce instability. There are ways of doing this is a semi-safe manner through careful management of the timestep length over multiple frames, but it's probably not worth the effort.
From a performance point of view I would not like to run through all physics bodies that might be active to check whether position was updated and update attached drawables as well. I like the eventing updating the positions of the drawables only if the physics object really has changed its position or orientation.
The time it takes to iterate over the entities updating graphics is likely irrelevant. Before exposing your code to the dangers of asynchronous access caused by the PositionUpdated event, it would be a good idea to verify that the performance boost exists and is sufficient to care about.
PSVWizard
Posts: 11
Joined: Fri Aug 02, 2013 11:57 am

Re: call to event entity.PositionUpdated

Post by PSVWizard »

Hi Norbo,

Thanks again for your quick and very professional help. I fully agree to the points you are making. I'll implement some slight changes and I tend to agree that the performance impact might not be recognizable..

Thanks a lot for your great engine...

BR PSVWizard

PS: hopefully my PSVita title utilizing your engine will be out soon....
Post Reply