Bullet Physics

[BielBdeLuna]

do you guys see plausible to include it in the code?

[DanielGibson]

What's wrong with Doom3 physics?

[BielBdeLuna]

this: https://www.youtube.com/watch?v=Cmz7Q3zzp9A

[DanielGibson]

and you expect other physics engines to perform much better for that scenario?

[BielBdeLuna]

yes if they use more modern resources and not only the CPU.

try to do this in Doom3 https://www.youtube.com/watch?v=INmMohKp7KY and you'll see if it can do it at all.

[DanielGibson]

And according to motorseps comment, bullet isn't even faster:

I just tested 18 ragdolls using BGE with Bullet - 6fps on my PC. And that's with plain scene, no shadows, static camera, etc. Basically not even realistic game test case, just one of those static test scenes. It seems that physics just very stressful on CPU regardless of the physics engine, and Doom 3 / BFG still ahead of Bullet (at least Bullet in Blender Game Engine). There is a map in Doom 3 with falling boxes. In BFG has has no slowdown whatsoever. Ragdolls on top of ragdolls is slow. (see https://www.youtube.com/watch?v=Cmz7Q3zzp9A&lc=00qz_1vRWkXwO8sFPIDGa3m3t0m9HNew9KSrRBhTpIc)

[DanielGibson]

well, maybe indeed try that with doom3. If it's not ragdolls but just solid objects that are thrown around, it'll be faster than the ragdolls test. Not sure how much faster and up to what amount of objects, so it should indeed just be tried out, if you're interested in this topic.

[BielBdeLuna]

Motorsep has been proven wrong other times though. but the case he raises here is true. I bet the improvement on the amount of FPS doesn't have to do to any improvements to the phsycs but the fact that the renderer was multi-threaded. therefore the CPU was more free to attend to the physics calculus, and also maybe on improvement on the maths in the CPU.

Also with Bullet or even ODE, we might gain support for clothes and cords, springs and other physics gadgets we otherwise would need to code ourselves.

Bullet seems to have a much more lively community, albeit Erwin Coumans left for the robot division of Google. bullet source is here:

https://github.com/bulletphysics/bullet3

[DanielGibson]

Oh, I'd never overestimate Motorseps competence, don't worry ;-) In this case at least he actually tried out bullet physics, so that's the best data I have on that topic.

I think physics code in bfg is also multi threaded, that explains a linear (with number of CPU cores) speedup. Which is pretty cool.

Looks like bullet3 isn't nearly done.

If anyone writes a clean integration of bullet into OTE that works at least as good as the existing code for the common (currently supported) usecases, we'd probably merge it. (Chances are higher if it's optional and physics engines can be switched at compile-time.)

I don't think I'll try to do that myself.

[BielBdeLuna]

:)

I didn't know the physics was multi-threaded, I knew the blending task was passed to the GPU, and that the some matrix calculus was optimized via SIMD optimizations.

where is it stated that the Physics was multi-threaded, in the code maybe?

[BielBdeLuna]

here is the documentation I have on idTechX:

http://www.fabiensanglard.net/doom3_documentation/index.php http://www.fabiensanglard.net/doom3_bfg/index.php

and the idTech 4 is also great:

http://www.fabiensanglard.net/doom3/index.php

[ghost]

Motorsep's post is old, so it could be that Bullet was slower in an old version of Blenders game engine in 2013. The Blender devs have improved a lot on the game engine in the 2.7 series.

I created a small fps game in Blender 2.73 a while back which had convex hulls on all models. The gun fires bullets which has around 60 vertexes, setting the firing to a machine gun that streams about 1000+ p/s bullets gave a stable 60fps. Each bullet had dynamic physics, so it would ricochet off the levels geometry.

I'll revisit that file again and add ragdolls and see how it performs under a stress test. I'll try recreate the game with the SDL2, OpenGL, Bullet 2.83 project I'm working on to learn. I'll share the results when I get to that stage. With D3BFG I get massive lag hits if I spawn 6+ imps into a scene, even a harder hit when I kill one and the ragdoll kicks in.

[ghost]

@BielBdeLuna I think Carmack spoke about multi-threading code for BFG at a Quakecon event.

[BielBdeLuna]

ok

[motorsep]

@Yetta1 Try disabling shadows with your imp tests and see if that helps performance.

As you can see here, BFG doesn't lag much with that many Imps: https://www.youtube.com/watch?v=qPRs-OQi1_g&feature=youtu.be&t=2m5s

AI and rendering frontend suffer, but even with that the game doesn't lag much.

Non-shooting monsters don't even stress performance that much: https://youtu.be/X1oM1m8ZO44?t=21s

[BielBdeLuna]

@motorsep in the case of the imps, if you disable their light do they lag as much? I mean it's the multiple lights that lag the game or the creation of the entities of the projectiles?

[motorsep]

@BielBdeLuna I am saying is that it doesn't lag for me. That's what I am showing on the videos.

Original Doom 3 lagged for me with 4 zsecs attacking me. And I mean, it lagged. But not Doom 3 BFG.

Although I am incompetent in the whole subject, so what do I know ....

[BielBdeLuna]

so Doom3 the entities themselves also contributed to the lag, not only the added lights, so they also changed something with way of handling the entities.

Yes, the other day I tried to spawn several instances of the allied soldiers and I was surprised when there where so much of them they started to pile up one over the others even in two rows, and it was true, it was the physics that made it slow, killing all of them with the BFG gun made the engine drop frames but before and after it went really smooth, I bet there where 20-30 if not 50 dudes and they where the allies (from the allies mod) which have the most complex scripting for an NPC I've seen. I wonder if we used massive threading in the scripting if it would affect negatively to the code or not. like having a thread for sight, another for hearing, another for the movement, another for turning, another for strategy etc...

[ghost]

@motorsep I watched your videos a few days ago. It could be the shadows, however I get the same kind of lag on Rage when enemies explode, similar to how the imps do, it's a lot worse on Rage as they added a lot more gibbage to the animation. Then again my hardware is quite low end for todays standards.

However I have been playing Dota 2 reborn lately and tried out the hero tester mode which allows to spawn enemies, I stress tested it and spawn over a hundred Axe heroes while playing as techies, I blew them all up with bombs with almost no lag. Not sure how Valve got it to run so many instances so smoothly. It could be that they have added SDL2 in the engine, not sure what other changes they've made in Source 2. Quite impressive if it handles so well on a 2006 Celeron CPU and low end Geforce 630 GT with 4GB DDR2.

[motorsep]

Well, you can't be seriously expecting multithreading benefit on single core CPU from 2006 :) In your case Doom 3 BFG plays just like old Doom 3.

[ghost]

@motorsep It's a dual core 64-bit cpu.

[motorsep]

@Yetta1 I didn't think Celeron from 2006 would be a dual core CPU o.O

[ghost]

@motorsep It was among the first, came out around the same time as the socket 775 Core 2 Quads. It performs quite well for what it is, manage to run many new games with medium to high settings with an average 25-40fps, but I guess my saving grace is the low-latency memory I got since my mobo can only take 4gb ram.

I'm waiting for AMD's hybrid systems to mature a bit, before I upgrade. Some nice things ahead with HSA it seems, it just needs more people to develop for it. Wouldn't mind to find a second hand core 2 quad though, quite rare in my country or people sell them for $400.

[motorsep]

@Yetta1 If you are going AMD, you can pretty much forget about BFG engine, because BFG and AMD don't get along at all.

[ghost]

@motorsep I play rbdoom3bfg and vanilla doom3bfg on my AMD dual core ql-64 laptop with HD 3200 gpu and 2gb ddr2 with an average of 25-35fps. The gpu uses 256mb from the ram.

[Anthony-Gaudino]

I think that using Bullet Physics is a good idea.

Do you want to completely replace the current physics or make both ID Physics and Bullet Physics available, like what is being done with CEGUI and Flash interfaces?