@GlyphTheWolf Good point, thank you for remind me this. I don't know why I keep over optimize and new optimization idea keep pop in my head now and then. And this time I unable to realize it myself :(

Yes, that is also something I used to do many times in my projects.

Sometimes I stuck because I was trying to make optimal solution for some problem, but couldn't figure out how it should be done or it was a lot more complicated and I wasn't able to finish my project even I knew easier and working solution, but I wasn't keen to use it.

That's why now I think in case of optimization unless there are real performance issues any working solution may be considered valid, at least at the very beginning of the project.

Generally the rule of thumb is to not optimize early.

a year later

Hi,
First of all, I am completely new to Godot, but I have the same consideration right now. I once read a benchmark for Unity that showed that 2D physics are about 4 times faster than 3D. In my opinion this is not just an optimization but a very crucial design decision that should be made early on. Changing the physics engine in the optimization phase would require a major rework. I think that it is unfortunate that graphics and physics are so tightly coupled in Godot as there is no real reason to do so in my opinion.
I would be very happy to have some more elaborate opinions on that topic.

Generally, from an engine design point of view, physics and rendering are unrelated and only have contact with each other in so far as the renderer must receive data from the physics part to know where to render what.

I do not know how they are related in Godot and to what extent they are tightly coupled, i would assume (and someone please correct me if that's wrong) that physics and rendering run in different threads and synchronize somehow, simply because the renderer can (and does) run with different frame rates than the physics ticks, the former being variable, the latter fixed to avoid numerical instability.

For your game made with an engine, you simply have to rely on the engine doing it in a reasonable way, or you'd have to brew your own physics and integrate it as an extension into your game. If you need to solve differential equations you'll certainly have to go that way, if I just check for collisions I'd want to rely on the engine's capabilities and only start to question when things aren't looking "right", in which case I'd per default search the error on my side before digging deeper.

I can't really imagine how to reasonably do 3d in 2d. Well, maybe calculating orbits in the simple 2-body problem are ellipses on planes, so that would work. But passing the data in for rendering needs 3d things again. Anything else where life's ups and down play a role you need the third dimension. Don't worry so much about performance prematurely, only when it starts to show that your scene won't render fast enough, then you'd have to think about solutions.

    Well the game is either 2D or 3D. Not in the graphics necessarily, cause you can mix 2D and 3D layers freely in Godot. But in the gameplay. The choice of tools should be based on the game. For example, there are fighting games that are in 3D, but restricted to a 2D plane (Street Figher 4, etc.). But it would still be a 3D game, since there are 3D elements, for example particle effects that move along the Z axis, characters can side step or parry, etc. I'm not even sure how you would make a 3D game in 2D, and, even if possible, how that would increase performance. If anything, it would require software hacks and just decrease performance substantially. And, in any case, GPUs have no concept of 2D or 3D. They are rasterization hardware, that can just perform math and transforms, and they do the same work whether the game is 2D or 3D. The one case I could see it making sense is in the physics engine, but I think with clever tweaking you can get better performance.

    For 2D vs 3D physics, performance isn't always as clear cut as 2D is faster. It depends on the tech being used.
    In my 2D engine, I usually use Box2D (as MANY games have done). But I did some testing and found PhysX doing 3D physics with axis locks and 3D primitives instead of 2D is far faster at the same scene than Box2D.
    I still prefer Box2D for simple coding, but I'd use PhysX if I needed a lot of objects.
    PhysX is also 4 times faster at 3D ray casting than Box2D is at 2D raycasting.

    Here's a graph I made. I dropped 5000 circles (Box2D) or spheres (PhysX) into the scene.
    Orange is Box 2D, blue is PhysX. The y axis is time in seconds a physics update takes.

    Obviously Godot is a different situation. In 3.x, Godot uses a custom physics engine for 2D and the popular open source Bullet for 3D. I don't know how well those two compare to each other. In Godot 4, a custom physics engine is replacing Bullet as the default for 3D.

    • Zui replied to this.

      You can use Godot Physics for 3D as well, even in Godot 3.x. I find Bullet is more full featured, but they have pros and cons. It depends on the game.

      15 days later

      Kojack
      That's really interesting! So I guess it needs specific testing to see what difference it really makes in practice.
      However, I still fail to see the point why physics and graphics should be tied together. I think it's not hard to imagine a game (like Ori or Trine) where all the physical relevant calculations can be done in one plane but the graphics are done in 3D.

        2 months later
        a year later

        This is the exact topic that brought me to the forum!
        I'm beginning to prototype a top-down space shooter type of game, but i need all elements to move on a flat 2D plane, however i need 3D elements as my story will require the camera to tilt to create some perspective .