Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark Physics & Dark A.I. & Dark Dynamix / [Dark Physics] PHY UPDATE

Author
Message
Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 2nd Aug 2006 14:48
I wonder if someone could just elaborate on the point of this a little ...

Quote: "An alternative to the default phy update is supplied that allows you to run the simulation asyncronously. This is the recommended method for getting the best performance but to use it requires a different approach to calling the default phy update. This method allows a simulation mode parameter being passed into phy update. This parameter controls whether phy update is going to simulate or fetch data. The process to use this involves calling phy update and passing in 0 directly after phy start is called. In the main update call phy update 1 and then phy update 0 before sync. Finally at the end of the program call phy update 1. Using this method of updating can have a significant improvement on performance and it is demonstrated in the PhysX PPU demos ( note that the PhysX PPU is not a requirement to use this method of updating ). "


It appears that it is suggesting that instead of:
phy start
do
phy update
sync
loop

It is suggesting you use:
phy start
phy update 0
do
phy update 1
phy update 0
sync
loop

Is this correct, and how does this benefit performance?

Cheers.

Van B
Moderator
21
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 2nd Aug 2006 14:59 Edited at: 2nd Aug 2006 15:00
I think maybe it wont.

BUT!

If you only use PHY UPDATE 0 before a sync, you could double the speed of physics by simply...

PHY UPDATE 1
PHY UPDATE 1
PHY UPDATE 0

But I don't think that's how it would be used - it's more a concearn for slower systems, so maybe you might skip a screen sync when things get slow - you'd just call update 1 to update the physics internal data, then update 0 when you wanted to display it. Otherwise it would update it's internal data and the object positions etc each loop - I suppose it's a bit like putting a leash on the physics update and only letting it out to pee when it's convenient. I might be the best way to incorporate DP into timer based movement engines.

Aegrescit medendo
Mike Johnson
TGC Developer
21
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 2nd Aug 2006 15:14
The 2nd code listing shown by Fallout is the recommended method. It basically allows you to set the physics simulation running on a separate thread. This will help to increase performance gains when using the hardware and when dual core is also present.

Passing in a value of 0 to phy update will cause the simulation to start whereas passing in a value of 1 to phy update will update all objects in the scene using the physics data.

In the code listing you start the simulation processing outside of the main loop and then inside you get the data and then continue simulating. By breaking it up in this way it allows the simulation to be processing while other things are going on.

One thing to realise when using this approach - if you want to create any new rigid bodies or other physics objects or set properties etc then this has to take place inbetween the calls to phy update 1 and phy update 0 e.g.

Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 2nd Aug 2006 15:21
Ahhh, ok thanks for that. That makes some sense. So non-hardware or dual core systems might not see any benefit but won't see any real negative effects?

Also, in line with having to place properties, interactions and new rigid bodies inside the updates, can I assume this sort of structure would work?



Mike Johnson
TGC Developer
21
Years of Service
User Offline
Joined: 13th Sep 2002
Location: United Kingdom
Posted: 2nd Aug 2006 15:32
I'm running a single core cpu and don't see any improvement when using this update code on software scenes. When I enable the hardware compared to the alternative update code I do see a better improvement. It's worth doing. The only reason it isn't in most of the demos is as a way of keeping things as simple as possible.

That's how I would lay things out. Having the game code in between those calls is ideal. If you tried say setting a force on a rigid body outside of that block then at some stage you would get a runtime error and everything would close down.
Fallout
21
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 2nd Aug 2006 17:32
Ok thanks Mike. That clears it up nicely.

Login to post a reply

Server time is: 2024-03-19 06:31:43
Your offset time is: 2024-03-19 06:31:43