DebugManager affects Frame Rate?

I was just testing something, and when I disabled:



[java]bulletAppState.getPhysicsSpace().enableDebug(assetManager);[/java]



the FrameRate increased from 1500 to 2300.



Did something happen with my computer, or does it really effect the Frame Rate, and if yes, why?

If you’re collecting debug information, it likely affects performance (sometime quite alot).

I don’t know how the debugging of the bullet physics space works, but it’s very likely it has an impact.

As far as I know (I haven’t used bullet physics yet, just read some docs quickly), the debug mode draws the collision shapes visually, so that would increase load at least by some amount.

1 Like

I ask you: why would getting the info about the objects and then rendering blue meshes on top of them not affect framerate? Of course it does… :roll:

I figured that out, but I never expected the difference to be so big.

@memonick said:
I figured that out, but I never expected the difference to be so big.


That's what she said

And while 800fps sounds like alot, you were getting alot to begin with so really the percentage is what you should be looking at... if your fps was 100 to begin with, you may have seen it increase 50 or so

Yeah, going from 3000->1000 should not worry you much, much of that could even be rounding issues… From 60 to 30 is a much bigger performance hit and generally anything above 100fps is totally no problem, many games work with fixed 60fps.

1 Like

So you mean that it’s sort of ‘easier’ for the frame to decrease from 3000 than from 500? I never knew about that. Thanks a lot :slight_smile:

It’s quite simple really.



At 1000 frames per second each frame is rendering in one millisecond.



At 100 frames per second each frame is rendering in ten milliseconds.



So if you add something that takes one millisecond into your render loop then:

1000 fps goes to 500fps. 50% drop



100fps goes to 90fps. 10% drop



:slight_smile:

1 Like

Thanks. Great explanation!

Also… For some stuff it might be it delays a frame but doesn’t occupy the whole CPU/GPU’s processing power during this delay, allowing other things to be computed “within that time”, effectively not touching your headroom so much but only the fps.

Like for example when two Physics Bodies collide? (CharacterControl and RigidBody)

For example yeah.

I noticed that. When the player collides with a wall, the frame rate drops down to 800, and gradually increases back to 2000.