New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Weird physics behaviour for certain vehicles with OpenGL renderer (DirectX for Ogre 2.0) #28

Closed
Hiradur opened this Issue Jan 15, 2015 · 19 comments

Comments

Projects
None yet
4 participants
@Hiradur
Contributor

Hiradur commented Jan 15, 2015

The easiest way to test this is to use OpenGL, load simple2 terrain and spawn a Gavril MV4 and activate it.
Sometimes it breaks immediately, sometimes it requires some driving around, sometimes resetting it triggers it, sometimes time alone will trigger it. The higher the FPS the bigger the impact (I think).

@Hiradur Hiradur self-assigned this Jan 15, 2015

@Hiradur Hiradur added this to the RoR 0.4.5 (Nextstable) milestone Jan 15, 2015

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur Feb 1, 2015

Contributor

Two things I noticed so far:
CMakeLists.txt in source/main mentions that Angelscript may mess with the physics engine if it's not compiled with CLEAR_FPU_STACK defined. I rebuilt AS with CLEAR_FPU_STACK but this didn't solve it. Could be interesting for other things though.

If 'K' is pressed to show the skeleton of the vehicle it breaks apart immediately. So this may be related to the rendering of beams. So far it felt like the search for a needle in a haystack.

Contributor

Hiradur commented Feb 1, 2015

Two things I noticed so far:
CMakeLists.txt in source/main mentions that Angelscript may mess with the physics engine if it's not compiled with CLEAR_FPU_STACK defined. I rebuilt AS with CLEAR_FPU_STACK but this didn't solve it. Could be interesting for other things though.

If 'K' is pressed to show the skeleton of the vehicle it breaks apart immediately. So this may be related to the rendering of beams. So far it felt like the search for a needle in a haystack.

@Aperion

This comment has been minimized.

Show comment
Hide comment
@Aperion

Aperion Feb 2, 2015

Member

Any chance this is due to the variable physics time step based on the frame
rate?
On Feb 1, 2015 7:54 AM, "Hiradur" notifications@github.com wrote:

Two things I noticed so far:
CMakeLists.txt in source/main mentions that Angelscript may mess with the
physics engine if it's not compiled with CLEAR_FPU_STACK defined. I rebuilt
AS with CLEAR_FPU_STACK but this didn't solve it. Could be interesting for
other things though.

If 'K' is pressed to show the skeleton of the vehicle it breaks apart
immediately. So this may be related to the rendering of beams. So far it
felt like the search for a needle in a haystack.


Reply to this email directly or view it on GitHub
#28 (comment)
.

Member

Aperion commented Feb 2, 2015

Any chance this is due to the variable physics time step based on the frame
rate?
On Feb 1, 2015 7:54 AM, "Hiradur" notifications@github.com wrote:

Two things I noticed so far:
CMakeLists.txt in source/main mentions that Angelscript may mess with the
physics engine if it's not compiled with CLEAR_FPU_STACK defined. I rebuilt
AS with CLEAR_FPU_STACK but this didn't solve it. Could be interesting for
other things though.

If 'K' is pressed to show the skeleton of the vehicle it breaks apart
immediately. So this may be related to the rendering of beams. So far it
felt like the search for a needle in a haystack.


Reply to this email directly or view it on GitHub
#28 (comment)
.

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur Feb 3, 2015

Contributor

Could be. So far I thought that the frame rate is too high to have an impact. It's worth a look though. Maybe it's not the frame rate but the frame time jidder. Got to look into how this actually works.

Contributor

Hiradur commented Feb 3, 2015

Could be. So far I thought that the frame rate is too high to have an impact. It's worth a look though. Maybe it's not the frame rate but the frame time jidder. Got to look into how this actually works.

@Max98

This comment has been minimized.

Show comment
Hide comment
@Max98

Max98 Feb 4, 2015

Contributor

Talking about frame rate and and physics time step, I tried last time doing some kind of slowmotion feature like BeamNG, and the first thing i noticed is when you slow down the simulation, beams get weaker and weaker until it all explodes for no reason.

Here's the code if you want to test. https://github.com/Max98/ror_nextstable_gui/tree/SimTimeManager
You have to enable Async physics to get this working.

Contributor

Max98 commented Feb 4, 2015

Talking about frame rate and and physics time step, I tried last time doing some kind of slowmotion feature like BeamNG, and the first thing i noticed is when you slow down the simulation, beams get weaker and weaker until it all explodes for no reason.

Here's the code if you want to test. https://github.com/Max98/ror_nextstable_gui/tree/SimTimeManager
You have to enable Async physics to get this working.

@Aperion

This comment has been minimized.

Show comment
Hide comment
@Aperion

Aperion Feb 5, 2015

Member

@Max98 Most of the RoR slowmotion videos came from using the replay feature, I think Kitteh(or what ever his name is now, I swear he changes his name more than my wife changes shoes.) was one of the first to do it.

Member

Aperion commented Feb 5, 2015

@Max98 Most of the RoR slowmotion videos came from using the replay feature, I think Kitteh(or what ever his name is now, I swear he changes his name more than my wife changes shoes.) was one of the first to do it.

@Max98

This comment has been minimized.

Show comment
Hide comment
@Max98

Max98 Feb 5, 2015

Contributor

@Aperion I remember seeing one of the users use Cheatengine to slow down the simulation actually. The replay feature doesn't have the possibility to slowdown simulation if i'm not mistaken.

Contributor

Max98 commented Feb 5, 2015

@Aperion I remember seeing one of the users use Cheatengine to slow down the simulation actually. The replay feature doesn't have the possibility to slowdown simulation if i'm not mistaken.

@Aperion

This comment has been minimized.

Show comment
Hide comment
@Aperion

Aperion Feb 5, 2015

Member

@Max98 IIRC it does or can but I haven't used it in a long time. All it does is store node positions in some container with a time stamp, then on replay the nodes are set top the stored positions.

Member

Aperion commented Feb 5, 2015

@Max98 IIRC it does or can but I haven't used it in a long time. All it does is store node positions in some container with a time stamp, then on replay the nodes are set top the stored positions.

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur Feb 9, 2015

Contributor

Today I found out that if the frame rate is below 20 FPS (forced by activating debug information for beams) then vehicles behave normally. So it may very well be related to the physics time step since its locked to 100 steps at <=20 FPS.

Contributor

Hiradur commented Feb 9, 2015

Today I found out that if the frame rate is below 20 FPS (forced by activating debug information for beams) then vehicles behave normally. So it may very well be related to the physics time step since its locked to 100 steps at <=20 FPS.

@Max98

This comment has been minimized.

Show comment
Hide comment
@Max98

Max98 Feb 9, 2015

Contributor

Nice discovery there, but why it doesn't do the same for DirectX then?

Contributor

Max98 commented Feb 9, 2015

Nice discovery there, but why it doesn't do the same for DirectX then?

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur Feb 10, 2015

Contributor

The answer to this question may be a part of the solution.

Contributor

Hiradur commented Feb 10, 2015

The answer to this question may be a part of the solution.

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur May 10, 2015

Contributor

So I already spent many hours debugging this but got nowhere and ran out of ideas. Help would be appreciated.

This is what I know so far:
- 0.38 does not have this issue
EDIT: This is wrong. I tested most releases since 0.36 and the issue is always present though it's less obvious in older versions.
-> 0.4 brought multi-threading and new terrain format, maybe the issue lies there

  • If FPS are below 20 FPS vehicles seem to behave normally
    -> may have to do something with the timestep but timestep detection seems to work correctly with OpenGL

Vehicles related to this issue:
MV4: http://www.rigsofrods.com/threads/84411-Gavril-MV4 (also most of the other cars by gabester)
Audi 80: http://www.rigsofrods.com/threads/87177-Audi-80-B2-CC-%28Download-link-on-page-17-post-327%29?p=1095982&viewfull=1#post1095982
BMW E39: http://www.rigsofrods.com/threads/114599-Update-Page-14-BMW-E39-%285-series-1995-2003%29

Contributor

Hiradur commented May 10, 2015

So I already spent many hours debugging this but got nowhere and ran out of ideas. Help would be appreciated.

This is what I know so far:
- 0.38 does not have this issue
EDIT: This is wrong. I tested most releases since 0.36 and the issue is always present though it's less obvious in older versions.
-> 0.4 brought multi-threading and new terrain format, maybe the issue lies there

  • If FPS are below 20 FPS vehicles seem to behave normally
    -> may have to do something with the timestep but timestep detection seems to work correctly with OpenGL

Vehicles related to this issue:
MV4: http://www.rigsofrods.com/threads/84411-Gavril-MV4 (also most of the other cars by gabester)
Audi 80: http://www.rigsofrods.com/threads/87177-Audi-80-B2-CC-%28Download-link-on-page-17-post-327%29?p=1095982&viewfull=1#post1095982
BMW E39: http://www.rigsofrods.com/threads/114599-Update-Page-14-BMW-E39-%285-series-1995-2003%29

@Max98

This comment has been minimized.

Show comment
Hide comment
@Max98

Max98 May 10, 2015

Contributor

Last time I wanted to make a slowmotion system, and when I made it to slowdown the physics step, all vehicles began to act weird and explode. (This is one Windows w/ DirectX) So my theory is simply that the physics engine is in a pretty bad state and needs a total re-factoring.

Contributor

Max98 commented May 10, 2015

Last time I wanted to make a slowmotion system, and when I made it to slowdown the physics step, all vehicles began to act weird and explode. (This is one Windows w/ DirectX) So my theory is simply that the physics engine is in a pretty bad state and needs a total re-factoring.

@Max98

This comment has been minimized.

Show comment
Hide comment
@Max98

Max98 May 10, 2015

Contributor

I have an other theory also. I think that few simulated values are depending on "delta time" while others don't. Which can cause these types of glitches and bugs.

Contributor

Max98 commented May 10, 2015

I have an other theory also. I think that few simulated values are depending on "delta time" while others don't. Which can cause these types of glitches and bugs.

@Max98

This comment has been minimized.

Show comment
Hide comment
@Max98

Max98 Jun 17, 2015

Contributor

This problem now happens for both OpenGL and DirectX using Ogre 2.0

Contributor

Max98 commented Jun 17, 2015

This problem now happens for both OpenGL and DirectX using Ogre 2.0

@Max98 Max98 changed the title from Weird physics behaviour for certain vehicles with OpenGL renderer to Weird physics behaviour for certain vehicles with OpenGL renderer (DirectX for Ogre 2.0) Jun 17, 2015

@Max98 Max98 added the Ogre-2.0 label Jun 17, 2015

@Max98 Max98 modified the milestones: Post-Nextstable, RoR 0.4.5 (Nextstable) Aug 12, 2015

@Hiradur Hiradur removed this from the Post-Nextstable milestone Oct 24, 2015

@Hiradur Hiradur removed their assignment Nov 10, 2015

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr Nov 11, 2015

Member

2 cents:

At the moment, timing in RoR simulation works like this:
_1. Main thread invokes OGRE to render a frame.
_2. Ogre invokes FrameListener::frameStarted(deltatime). Deltatime is seconds since last frame, and there is a smoothing mechanism in place: http://www.ogre3d.org/forums/viewtopic.php?f=1&t=28584. I think in RoR it stays at default, whatever that is.
_3. Physics are simulated (threaded or not - same code) by slicing the deltatime into chunks of almost-constant size cca 500 microseconds (plus minus couple microseconds):

number of phys steps:

https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/physics/Beam.cpp#L1521

actual deltatime per step:

https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/physics/Beam.cpp#L1589

_4. Repeat.

This design is not optimal and the code is a huge mess. However, it's not hopeless - the basic requirement of physics (constant time step) is satisfied pretty well. In fact, it works a lot better that I long feared.

Member

only-a-ptr commented Nov 11, 2015

2 cents:

At the moment, timing in RoR simulation works like this:
_1. Main thread invokes OGRE to render a frame.
_2. Ogre invokes FrameListener::frameStarted(deltatime). Deltatime is seconds since last frame, and there is a smoothing mechanism in place: http://www.ogre3d.org/forums/viewtopic.php?f=1&t=28584. I think in RoR it stays at default, whatever that is.
_3. Physics are simulated (threaded or not - same code) by slicing the deltatime into chunks of almost-constant size cca 500 microseconds (plus minus couple microseconds):

number of phys steps:

https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/physics/Beam.cpp#L1521

actual deltatime per step:

https://github.com/RigsOfRods/rigs-of-rods/blob/master/source/main/physics/Beam.cpp#L1589

_4. Repeat.

This design is not optimal and the code is a huge mess. However, it's not hopeless - the basic requirement of physics (constant time step) is satisfied pretty well. In fact, it works a lot better that I long feared.

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur Nov 11, 2015

Contributor

What if the Direct3D 9 renderer in OGRE has a bug which has been fixed in Ogre 2.0? So that OpenGL actually is correct and RoR has been fine-tuned for a faulty D3D9 renderer?
I consider this to be unlikely though since older releases of RoR using older versions of Ogre also show this behaviour so it would have to be a long standing bug.

What's the situation like with D3D9 and Ogre 1.9 on Windows?

With OpenGL on Linux I made RoR output dt after every frame and it was always correct (16.6ms for constant 60FPS), perhaps it's different with D3D9.

Contributor

Hiradur commented Nov 11, 2015

What if the Direct3D 9 renderer in OGRE has a bug which has been fixed in Ogre 2.0? So that OpenGL actually is correct and RoR has been fine-tuned for a faulty D3D9 renderer?
I consider this to be unlikely though since older releases of RoR using older versions of Ogre also show this behaviour so it would have to be a long standing bug.

What's the situation like with D3D9 and Ogre 1.9 on Windows?

With OpenGL on Linux I made RoR output dt after every frame and it was always correct (16.6ms for constant 60FPS), perhaps it's different with D3D9.

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr Nov 11, 2015

Member

@Hiradur Please investigate:

AFAIK Directx9 internally synchronizes it's operations, while OGL does not. RoR does some gfx right from the physics code, and unless OGRE explicitly synces those operations, then it's up to the underlying graphics API.

Further, RoR is heavy on draw calls (i.e. batches) and those are known to be more expensive under OGL 2x than DX9. This would cause different framerates and as a result, different physics behavior because under current RoR architecture, different FPS will yield slightly different results.

EDIT: I'm willing to test for you, just specify the scenario.

Member

only-a-ptr commented Nov 11, 2015

@Hiradur Please investigate:

AFAIK Directx9 internally synchronizes it's operations, while OGL does not. RoR does some gfx right from the physics code, and unless OGRE explicitly synces those operations, then it's up to the underlying graphics API.

Further, RoR is heavy on draw calls (i.e. batches) and those are known to be more expensive under OGL 2x than DX9. This would cause different framerates and as a result, different physics behavior because under current RoR architecture, different FPS will yield slightly different results.

EDIT: I'm willing to test for you, just specify the scenario.

@Hiradur

This comment has been minimized.

Show comment
Hide comment
@Hiradur

Hiradur Nov 11, 2015

Contributor

@only-a-ptr

I'm willing to test for you, just specify the scenario.

The easiest way to test this is to use OpenGL, load simple2 terrain and spawn a Gavril MV4 and activate it.
Sometimes it breaks immediately, sometimes it requires some driving around, sometimes resetting it triggers it, sometimes time alone will trigger it. The higher the FPS the bigger the impact (I think).

Does threading ON/OFF has any effect on this?

Threading does not have an effect on this.

What OGRE_THREADING_LEVEL is your OGRE 2.0 built with?

I can't find any information on that macro, are you sure it exists?
Anyway, I never set it so it should be the default value.

Contributor

Hiradur commented Nov 11, 2015

@only-a-ptr

I'm willing to test for you, just specify the scenario.

The easiest way to test this is to use OpenGL, load simple2 terrain and spawn a Gavril MV4 and activate it.
Sometimes it breaks immediately, sometimes it requires some driving around, sometimes resetting it triggers it, sometimes time alone will trigger it. The higher the FPS the bigger the impact (I think).

Does threading ON/OFF has any effect on this?

Threading does not have an effect on this.

What OGRE_THREADING_LEVEL is your OGRE 2.0 built with?

I can't find any information on that macro, are you sure it exists?
Anyway, I never set it so it should be the default value.

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr Nov 13, 2015

Member

@Hiradur Sorry my bad, the macro is OGRE_THREAD_SUPPORT

Thanks for the testing instructions, I'll look into it.

Member

only-a-ptr commented Nov 13, 2015

@Hiradur Sorry my bad, the macro is OGRE_THREAD_SUPPORT

Thanks for the testing instructions, I'll look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment