Low FPS lead to wall slipping

Hi,

i have a problem using the update loop provided by jme3.

If the FPS get very low, the tpf parameter passed by the update()-methods is very high.
therefore moving objects with something like:
[java]
Vector3f moveOffset = curDirection.mult(tpf).mult(speed);
spatial.move(moveOffset);
[/java]

… results in teleporting my spatial from one point to another, allowing it to totally avoid collision control with a wall.

Is there a way to suppress this? Can i for instance define a maximum tpf-value for my App somewhere, which splits up the “one big update call” into “many small update calls”?

After starting the Application especially some of the first frames take very long to render:

  1. frame tpf: 0.1471746
  2. frame tpf: 1.6336108 << can cause slipping through walls without colliding
  3. frame tpf: 0.38494414
  4. frame tpf: 0.22636715
  5. frame tpf: 0.16856459

That happens because the app is initializing, and you have a black screen for a while before the game starts, while its stuck in the same frame (hence the high tpf).

http://hub.jmonkeyengine.org/forum/topic/unpausing-and-resetting-tpf/#post-226220

Sometimes a frame can take a long time to render for a variety of reasons. For example, when my card gets hot it sometimes takes 8 seconds or more to render a single frame.

…you will probably need to account for this sort of thing in your collision detection. Either do sweep tests or perform catch-up checks (ie: if time step is bigger than T then run a few smaller time steps to catch up). Alternately, you can keep your own time source and just make sure it never advances faster than a certain amount.

There are a few other ways to solve the issue but they depend on the physics implementation and how complicated you want to get.

Since i do the movement and the collision detection in different modules (i.e. Controls), it wouldn’t work to split up the update-call in the collision detection, since this would result in:

  1. move very far
  2. do many collision detections at the end of the movement.

the same problem could occur in many other modules.

So i need to split up the update mechanism one layer above my own Controls, so that the Application is not calling:

[java]
loop {
controler1.update(highTPF);
controler2.update(highTPF);
controler3.update(hghtTPF);

render()
}
[/java]

but instead is calling

[java]
loop {
controler1.update(lowTPF);
controler2.update(lowTPF);
controler3.update(lowTPF);

controler1.update(lowTPF);
controler2.update(lowTPF);
controler3.update(lowTPF);

render();
}
[/java]

Anything else seems inappropriate to me, from a software architectural point of view, since I don’t want my modules to know each other and I don’t want my game logic to be influenced by rendering problems.

Are there more Ideas?

@pspeed said: Either do sweep tests

Seems like a complicated solution for a very simple problem. Also it only solves the problem for collision, but potential other modules will still have to deal with high TPF (i.e. drowning or reloading may result in strange results). Anyway, are there any jme3 methods supporting me with sweep detection?

@pspeed said: or perform catch-up checks (ie: if time step is bigger than T then run a few smaller time steps to catch up).

This doesn’t work with different Controls which rely on each other (see my previous post).

As I understand it bullet runs its physics in its own thread with its own tick and then the scene graph is updated from that each displayed frame. That sounds like a similar concept but making better use of multiple cores.

Well, I’m not sure what your desire is, actually. How can JME make frames happen consistently? tpf will vary and somehow have to be dealt with.

You can also replace the time source and do whatever time generation you want… to include pretending every frame takes exactly the same amount of time no matter how fast or slow you are running.

Personally, I don’t use tpf for anything except visualization… since the tpf is only accurate for the visualization. All of my other systems use their own time source and run separate from the render loop.

…but there are as many ways to roll a game as there are games, I guess.

<cite>@pspeed said:</cite> Well, I'm not sure what your desire is, actually. How can JME make frames happen consistently?

It can’t. But i could call the update-methods of Controls and AppStates more consistently, like i tried to show in the pseudo code above.

So to explain my desire further, lets make a list of requirements i have to my gaming framework:

  • my game logic shall not depend on visualization issues, but run stable, even with laggy rendering.
  • my modules shall work independently, especially the movement and the collision module.
  • my modules may rely on the proper execution of the other ones. for example the collision module is always executed after the movement module to prevent some movements.
  • my game time shall not be slowed down (but the frame rate is allowed to), since this wouldn’t work in multiplayer on differently fast machines.
<cite>@pspeed said:</cite> Personally, I don't use tpf for anything except visualization... since the tpf is only accurate for the visualization. All of my other systems use their own time source and run separate from the render loop.

This sounds at least a little bit better than my current solution. Can you tell me how you do this? When I use the Control-class of jme3, I get my updates at a tpf-base.

Model-View-Controller

You Model your game world as an abstract state.

Your View is the 3d representation of that Model as displayed on the screen

You use Controls and AppStates as Controllers to update your view as required

For example its not “Model Monster1 in node X doing animation Y” it is “NPC Monster1, at position X moving towards Y with mission Z”. A control is then used to update the view each frame with the correct status of the monster. Moving it, changing the animation, whatever.

For things that change rarely you don’t even need a Control or AppState - just queue the change up from the model using app.enqueue()

For example spawning a new monster would happen in the model. The new monster would then be detected (several ways to do that, can use event callbacks, polling, etc) and a model for it generated and added to the scene graph, then a control attached to that to keep it synched up with the status of the model.

You can also look at Entity Systems. Quite a few discussions of them on these forums.

There are several advantages to this approach:

  1. The processes handling your physics/AI/whatever can occur separately from those in the render thread. (Just be aware of potential contention/synchronisation issues so you do need to think about how the 2 systems communicate). This means that multiple CPU cores can be used which on virtually all modern computers will increase performance.

  2. You separate the model from the view. This both gives much cleaner architecture and makes future changes easier. For example you could offer multiple views (tactical map vs first person for example) of the same data very easily just by attaching different visualisation to the same model.

  3. Generally cleaner architecture. Each class can just focus on doing one job and doing it well.

@Glut said: It can't. But i could call the update-methods of Controls and AppStates more consistently, like i tried to show in the pseudo code above.

The problem with that approach is that your updates could take a while and then the next frame is late and more of them have to run… and so on. JME would have trouble deciding which is important and which isn’t. The alternative would be for it to not count time that passes while calling your updates but then visuals will be jerky… kind of the whole point of tpf is to prevent jerky visuals, really.

It used to dynamically speed up time to catch up but then visuals looked kind of ridiculous. Animated water or grass blowing in the breeze would suddenly look like it was running in fast forward for a second or two. Very jarring visually.

@Glut said: So to explain my desire further, lets make a list of requirements i have to my gaming framework: - my game logic shall not depend on visualization issues, but run stable, even with laggy rendering. - my modules shall work independently, especially the movement and the collision module. - my modules may rely on the proper execution of the other ones. for example the collision module is always executed after the movement module to prevent some movements. - my game time shall not be slowed down (but the frame rate is allowed to), since this wouldn't work in multiplayer on differently fast machines.

I wouldn’t do any of those based on the tpf in controls. Especially not anything to do with multiplayer. In that case the server should absolutely be setting the pace of the game.

@Glut said: This sounds at least a little bit better than my current solution. Can you tell me how you do this? When I use the Control-class of jme3, I get my updates at a tpf-base.

As zarch describes, I only use controls for visual related animation (grass blowing or smoke rising or whatever) and synching with my game objects. But the game objects are updated separately. Mine are updated in a background thread but you can still do this without that… you just have to use catch-up updates like in your pseudo code.

Using spatials as game entities is useful for rapid prototyping and that’s why the tutorials do it a lot… but for a real game you hit a wall pretty quickly with that approach. I kind of wish we had more tutorials that showed the right way.

I start to see what you are trying to explain me. You are giving me general advice on software architectures and game development, while i seek jme3 specific answers.

I’m already familiar with subjects like software architectures, general game development, model-view-control, multithreading and stuff like the entity systems (didn’t know it under that name, but it seems like it’s nothing more than an implementation of the strategy pattern). What I’m not familiar with, is the jme3-framework. Also I did already read all the JME3 tutorials and a bunch of additional JME3 documentation, I haven’t figured out how to solve my problem in the context of JME3.

Your anwers are very well so far, so I’ll go through them step by step in different forum-posts:

<cite>@zarch said:</cite> Model-View-Controllern [...]

You use […] Controllers to update your view as required

[…]

then a control attached to that [scene graph] to keep it synched up with the status of the model.

As far as I understand Model View Control (MVC), the control manipulates the model depending on user inputs and the model informs the view about changes (or the view pulls it’s information from the model alternativly). I don’t see, why the control should manipulate the view or do synchronizing stuff between the view (i.e. scene graph) and the model.

<cite>@zarch said:</cite> You Model your game world as an abstract state.

Your View is the 3d representation of that Model as displayed on the screen

You use Controls and AppStates as Controllers to update your view as required

I don’t understand how that helps me with my described problem. My problem is, that the Management of controls (on a meta level) calls the update() methods of my controls only dpending on the Framerate, while I want my controllers to act indepentent from rendering. Are there any JME3 settings or something to manage HOW my Controlls and AppStates are called?

<cite>@pspeed said:</cite> I wouldn't do any of those based on the tpf in controls. _Especially_ not anything to do with multiplayer. In that case the server should absolutely be setting the pace of the game.

But how do I set the pace of the game? Is there any JME3 support for this, or do i have to implement a parallel framework to manage my model?

<cite>@pspeed said:</cite> only use controls for visual related animation [...] But the game objects are updated separately. Mine are updated in a background thread but you can still do this without that... you just have to use catch-up updates like in your pseudo code.

How to update seperatly? Are there JME3 methods, or do i have to implement this myself?
How do you update yours in a background thread? Are there JME3 methods, or did you implement this yourself?
Where to put my pseudo code catch-up updates? Is there a JME3 typical place for this, or do i have to implement my own glogbal update class, where i wan’t to register my components which i want to update, which is nearly the same as the TPF-based update methanism, but runs parallel to it.

In case i have to do it all by myself: Do you know any Update-Loop-Frameworks which handle that stuff for me and can be used in parallel with JME3?

Thanks for your anwsers so far. Your support is really welcome :slight_smile:

This general topic gets a lot more complicated. The simple answer:

[java]
public class MyAppState extends AbstractAppState {
private long lastTime;

public void update( float tpf ) {
    long time = System.nanoTime();
    if( lastTime == 0 ) {
            lastTime = time;
            return;
    }
    long delta = time - lastTime;
    lastTime = time;
    double seconds = delta / 1000000000.0;
    // Call your own update methods with these seconds... or split the frame up if delta is too large.
}

}
[/java]

…not necessarily worth having a whole framework just for that.

<cite>@pspeed said:</cite> [java] [...] // Call your own update methods with these seconds... or split the frame up if delta is too large. [...] [/java]

…not necessarily worth having a whole framework just for that.

And how to get the list of all my Control-Instances, to call my own update methods on them? Does JME3 provide a way to access my Controls, or do i have to implement a mechanism for registering controls myself?

To answer the generic question first by quoting http://en.wikipedia.org/wiki/Model–view–controller:

The Controller, in modern applications of 2000s, is a module, or an intermediary section of code, that mediates communication (between the Model and View) and unifies validation, using either direct calls or the Observer — to decouple the Model from the View in the active Model.[12]

It is also commonly used to describe the situation you are describing where updates to the model come through the controller but the bigger picture is that it is the interface between the model and the view and/or the interface between the model and any inputs to the model.

To be more specific about jME3.

Run your model however you like. You could have a separate thread, multiple separate threads, respond to network input/user intput, whatever. It really doesn’t matter as far as jME3 is concerned.

For example I believe bullet uses a single thread that bullet works in. Zay-ES uses at least one separate thread I believe, @pspeed is the expert on that though.

For changes that happen in the model you need to update the view.

There are 3 ways to do this:

For infrequent/specific changes - use app.enqueue() to push a task into the render thread to perform the update next frame.

For frequently changing specific objects (for example a moving NPC) use a control on that NPC. The job of the control is to keep it synched to the model state by using appropriate movements/animations/etc.

For changes not tied to specific objects in the scene graph use an AppState.

Again the job of the model is to keep track of the world.

The job of jME3 is to display the world.

The job of the AppState/Controller/enqueue actions is to co-ordinate between the two.

It’s down to your own personal taste/design/architecture/whatever which of these you use. I use a mixture of all 3 but you could equally use just one or two of these methods. Really it is a matter of deciding which works better for you for each case, and don’t be afraid to change your mind!

Why would you use a Control for your own logic update loop? Just make your own classes that get called by your own update loop. You can’t just hook the Controls into another thread and modify the scene objects with them. You will then have to devise some thread-safe way to get the data over to the visual scene, the controls have to be called from the render thread, thats their whole point. Also you can’t get a list of all objects you instantiated unless you maintain one, jME isn’t magic, this is a normal java library.

Here’s the way the structure would look:

Your Own Game Classes (the model) - this is where your game logic and entities are implemented. They are not Controls, they are not AppStates… they are JME-independent for the most part though using jme.math classes is quite common.

Your Visualization Classes - These are app states and controls responsible for syncing the visualization (view) with the game state (model). The controls may (probably do) have references to your game objects and then once a frame update themselves to match. User interaction is also probably handled at this layer in app states or controls… translating user interaction into game actions for the model.

Okay, the last posts made it much clearer to me. But now i need some help with the synchronization of multiple threads.

Lets assume i have a “game logic thread loop” which does the following

-> update object locations -> apply physics -> do X -> do Y -> update object locations -> apply physics -> …

And i have a render thread which does something like

-> pull current game logic state -> render current game logic state -> pull current game logic state -> render current game logic state -> …

Not all of the game logic states are valid rendering states. For example, if the render thread pulls it’s information between the “update object locations” and “apply physics”, it end up in rendering enemies inside walls.

Instead i need a mechanism, to only let the render thread access the valid game states. Can you give me some tips, on how to establish that? Maybe something like Double Buffering for Game States?

It seems like this topic about physics transforms into a topic about general game architectures :slight_smile: