BGE: Recording of simulations should use fixed timesteps
AbandonedPublic

Authored by Sybren A. Stüvel (sybren) on Sep 7 2015, 5:47 PM.

Details

Summary

Recording of animations should use fixed timesteps. Since the inception of this patch, things have become clearer, so the original description is no longer entirely valid.

This patch rolls back the changes from 62b254e42af10a38d1dd760b4b26177f23f6baca, as the original code (using fixed timesteps when recording animation) is actually correct.

The issues described in T30484 and T29449 no longer seem to apply to a current version of Blender, even after rolling back 62b254e42af10a38d1dd760b4b26177f23f6baca (UPDATE: yes, they do, the issue is still there)

Diff Detail

Repository
rB Blender
This revision is now accepted and ready to land.Sep 10 2015, 8:11 PM

More testing shows that the original issue of ridiculously fast frame rates is still there.

This configuration will result in a very fast frame rate:

  • game_settings.use_frame_rate = False
  • game_settings.vsync = False

Setting game_settings.use_frame_rate = False causes KX_KetsjiEngine::m_bFixedTime = true, which also happens in this patch when we're recording animations.

What I find strange, is that "use a fixed timestep" (FT) is eventually understood by the BGE as "as fast as possible" (AFAP). In FT simulations, this generally doesn't happen; instead, a suitable timestep is chosen (say 1/60 sec) and used for every step, regardless of the actual duration of the logic tick & render time (rendering is limited to 1/timestep frames per second). In contrast, in the current state of the BGE, the FT behaviour is enabled by rejecting the use of a specific frame rate (use_frame_rate = False). Personally, I really don't understand this design choice. After all, if you don't "use a frame rate", how do you control the timestep size? From the code it looks like the BGE would use render.fps, but a quick test shows that this is not the case. I suspect it uses a fixed 1/60 sec timestep instead.

In my opinion, FT and AFAP should be separate options. Let's look at a concrete example: some simulation that runs in the BGE but is recorded in order to nicely render in Blender. When playing back the recording in Blender, it'll happen at a fixed rate, so it should be recorded at that rate as well. This argues for the "recording enables FT" that is re-introduced in this patch. However, this has nothing to do with the AFAP behaviour. Someone may want to visually inspect a simulation while it is being recorded, and then 1000+ FPS is rather useless. On the other hand, maybe an inspection of the results after the simulation has run is good enough, and then the AFAP approach makes sense -- you won't have to wait as long for the simulation to finish.

As you can see, these are two separate choices, which are now crammed into a single boolean. A possible solution would introduce yet another choice (a separate AFAP checkbox) and possibly a choice for the FT timestep size. However, IMO there are already too many confusing FPS settings (game_settings.frequency, render.fps and game_settings.fps), and I'm Very Reluctant to add even more.

Furthermore, there are multiple variables in KX_KetsjiEngine that store something that could be interpreted as "the current time", but aren't. These should be better documented as to their intended use, as things are now rather unclear (for example see D728). This makes it even harder to address the above issues.

I invite everybody with an interest in the BGE to join a discussion here, on how to address this issue and fix this properly.

Sybren A. Stüvel (sybren) updated the summary for this revision. (Show Details)Sep 28 2015, 1:01 PM

Disclaimer: I have never played with recording simulation feature.

In this case you are proposing that the simulation in the BGE should run to fixed/capped (1/60 sec) timestep. This way you could inspect the results before you go to blender.
But, if you have a very very complicated simulation, maybe it is possible that run it AFAP be a good option. The approach could be:

  • Do a tests using fixed timestep.
  • Run/Record simulation using AFAP approach
  • Rerun in blender at fixed timestep.

Maybe, we can give to user the option to choose between both approachs

EDIT: I have read again your text and you are taking into account my thoughts. Sorry for the noise

This configuration will result in a very fast frame rate:

  • game_settings.use_frame_rate = False
  • game_settings.vsync = False

    Setting game_settings.use_frame_rate = False causes KX_KetsjiEngine::m_bFixedTime = true, which also happens in this patch when we're recording animations.

    What I find strange, is that "use a fixed timestep" (FT) is eventually understood by the BGE as "as fast as possible" (AFAP). In FT simulations, this generally doesn't happen; instead, a suitable timestep is chosen (say 1/60 sec) and used for every step, regardless of the actual duration of the logic tick & render time (rendering is limited to 1/timestep frames per second). In contrast, in the current state of the BGE, the FT behaviour is enabled by rejecting the use of a specific frame rate (use_frame_rate = False). Personally, I really don't understand this design choice. After all, if you don't "use a frame rate", how do you control the timestep size? From the code it looks like the BGE would use render.fps, but a quick test shows that this is not the case. I suspect it uses a fixed 1/60 sec timestep instead.

From my understanding (and test), it is based on scene.game_settings.fps, not render.fps.
Concerning the design choice, I can't answer :) We use it, trying to handle madness (but also all cool stuff) of BGE.
AFAP is currently related to FT due to "KX_KetsjiEngine.cpp:[567-570]". In non-FT mode, we rely on system clock (i.e. simulated clock == system clock), and so the BGE will "sleep"
if we compute "too fast" for the requirement. in FT-mode, there is no requirement related to system-clock, we just compute as fast as possible, computing each time one timestep.

In my opinion, FT and AFAP should be separate options. Let's look at a concrete example: some simulation that runs in the BGE but is recorded in order to nicely render in Blender. When playing back the recording in Blender, it'll happen at a fixed rate, so it should be recorded at that rate as well. This argues for the "recording enables FT" that is re-introduced in this patch. However, this has nothing to do with the AFAP behaviour. Someone may want to visually inspect a simulation while it is being recorded, and then 1000+ FPS is rather useless. On the other hand, maybe an inspection of the results after the simulation has run is good enough, and then the AFAP approach makes sense -- you won't have to wait as long for the simulation to finish.

I tend to agree that the two options are orthogonal and need to be configured separately.

As you can see, these are two separate choices, which are now crammed into a single boolean. A possible solution would introduce yet another choice (a separate AFAP checkbox) and possibly a choice for the FT timestep size. However, IMO there are already too many confusing FPS settings (game_settings.frequency, render.fps and game_settings.fps), and I'm Very Reluctant to add even more.

Furthermore, there are multiple variables in KX_KetsjiEngine that store something that could be interpreted as "the current time", but aren't. These should be better documented as to their intended use, as things are now rather unclear (for example see D728). This makes it even harder to address the above issues.

I invite everybody with an interest in the BGE to join a discussion here, on how to address this issue and fix this properly.

In this case you are proposing that the simulation in the BGE should run to fixed/capped (1/60 sec) timestep.

It should at least be able to.

But, if you have a very very complicated simulation, maybe it is possible that run it AFAP be a good option. The approach could be:

  • Do a tests using fixed timestep.
  • Run/Record simulation using AFAP approach
  • Rerun in blender at fixed timestep.

    Maybe, we can give to user the option to choose between both approachs

I think giving the user the option is a good idea. In your proposal, it's impossible to record the result of any interactive simulation/game, because it'll run way too fast.

From my understanding (and test), it is based on scene.game_settings.fps, not render.fps.

Well, there you go, apparently the UI is not clear on this matter. IMO stuff like this should be blatantly obvious in the UI.

I tend to agree that the two options are orthogonal and need to be configured separately.

Great.

So to summarize, we agree on the following:

  • AFAP and FT are orthogonal, and the user should be able to choose which one is used.
  • Enabling animation recording should enable FT but leave AFAP as a choice for the user.
  • The UI should be clear on which frame rate is used where and in what situation.

Currently I'm thinking about adding a "Time" panel to the Blender UI that consolidates all time-related properties. This can show the link between animation recording and FT, and more clearly explain the relation between the different options. It would also serve as a logical place to add the time scaling options of D728.

And as another discussion point: does it make sense to allow AFAP without FT?

Sybren A. Stüvel (sybren) updated the summary for this revision. (Show Details)Sep 30 2015, 2:50 PM

In this case you are proposing that the simulation in the BGE should run to fixed/capped (1/60 sec) timestep.

It should at least be able to.

But, if you have a very very complicated simulation, maybe it is possible that run it AFAP be a good option. The approach could be:

  • Do a tests using fixed timestep.
  • Run/Record simulation using AFAP approach
  • Rerun in blender at fixed timestep.

    Maybe, we can give to user the option to choose between both approachs

I think giving the user the option is a good idea. In your proposal, it's impossible to record the result of any interactive simulation/game, because it'll run way too fast.

From my understanding (and test), it is based on scene.game_settings.fps, not render.fps.

Well, there you go, apparently the UI is not clear on this matter. IMO stuff like this should be blatantly obvious in the UI.

I tend to agree that the two options are orthogonal and need to be configured separately.

Great.

So to summarize, we agree on the following:

  • AFAP and FT are orthogonal, and the user should be able to choose which one is used.
  • Enabling animation recording should enable FT but leave AFAP as a choice for the user.
  • The UI should be clear on which frame rate is used where and in what situation.

    Currently I'm thinking about adding a "Time" panel to the Blender UI that consolidates all time-related properties. This can show the link between animation recording and FT, and more clearly explain the relation between the different options. It would also serve as a logical place to add the time scaling options of D728.

I think it would be very nice.

And as another discussion point: does it make sense to allow AFAP without FT?

AFAP without FT means basically keep stuff in real-time, but do as many step as possible, so it can lead to a really precise simulation in real-time. Still, the result will depends of the hardware and other stuff working around, so not completely determinism (contrary to FT mode). So it may have some use, but probably a really niche one. Through, I'm using blender / bge mainly for simulation purpose, so I may miss some valid usage in different situations.

Thanks for your feedback, I think I should be able to write a nice patch that implements our proposal.

Just to keep things linked: T34510 is related to this too.

This has become obsolete with the changes in the UPBGE branch. Closing