BGE physics objects cost performance order?

Also I think it’s important to use collision group / mask to determine wich objects are likely to collision and others who don’t, so we can avoid unnecesary CPU usage with objets that wont be colliding during the game excecution.

:grinning:

1 Like

yeah upbge even can seprate physics meshes layers in ray and mouse over sensors, and even in raycast api.

another trick is we have bvhtree now, so we can roll our own physics using raycasts

also we have bvhtree from triangle mesh, so we can see where meshes overlap or the closest point on a mesh etc.

1 Like

I,m finiahing level 3 openworld going to spawn enemies now…

I using just one lamp moving around level and all game where player stay using a barrel firing too where player stay… for reduce stress on bge!

yes for object with many faces that is perfect except terrain ground where player and enemies walk…

Even for terrain it can be useful to have a duplicate “physics mesh” that you run a decimate modifier on (often terrain is pretty much flat where the player is, and the decimate modifier can reduce the polycount dramatically).

Another trick is to split up the terrain’s physics mesh into “chunks”. That’s what I did in [BGMC 28] To The Surface where I had terrain with 25,000 faces after the decimation (there’s something to be said for auto-generating extremely detailed collision shapes…).
With the terrain as a single object, every single other object in the scene had to run a collision test against all 60,000 vertices, so even a handful of dynamic objects caused performance drop on my laptop. Dividing the 25,000 faces into 16 chunks of ~1600 faces each meant that the objects had to do a bounding box check (cheap to run) against all 16, and then only had to check 1600 faces. (in absolute worst case, you may be within the bounds of four terrain chunks, in which case you have 6400 faces - still better than 3x performance gain).

Making sure you aren’t overly stressing one part of a physics engine is a pretty good technique. Unfortunately, BGE/bullet doesn’t have any good profiling tools, so you have to know a bit about how physics engines work and do it via trial and error. It’s similar to the renderer in some ways: a single million polygon object will run slowly, as will a million single polygon objects. You find the best balance somewhere in between.

As far as I’m aware, you can’t.

In the past I’ve gotten around that by having a camera that can see the entire scene and cover it with a completely opaque title/loading screen. I have it sit there for a second or two.

I use the same obejcts over and over that are modular except for terrain tiles,
each terrain tile is a unique mesh but they are reused to skin empty locations over and over.

no stutter even when generating the world and building pathfinding for the first time.

can you duplicate whole sections of buildings you made then move the whole section of the building you made out of many parts?

about near logick bricks if i change to distance property object by script will better for not expansive processor?

What about sensor physics type? I don’t even see a physics shape being drawn when it has no collision/near sensors within it’s current logic state. I reckon it’d do fine as a toggleable hitbox.

Even with sensors it has wacky physics, sensors need to be used only when you know how they work. They should always have box collision(depending on shape) else it will fail a lot. Sensors will detect collision when colliding with something, but if something collides with the sensor then it does not work 5/10 times.

Also sensors aren’t so heavy if used properly. Like everything else don’t abuse them. i would put the sensor on spot 3.5, it can be lighter then dynamic but in most cases it won’t be, and rigid should be heavier due to the additional rotation calculations.

Sphere? hmm do you have that right? box vs sphere face count, more faces the heavier to calculate physics right?

i would say: box, cylinder, capsule, sphere, triangle, convex. (at least it’s the right order to use them as in physics bounds)

I have no real exp. with this or tested anything of this, but this is how i see it.

depending on the situation, SCRIPT will be better then NEAR sensor, why? A near sensor checks every single object every tic around him that are within the range. with a script you can simply check a single object, instead of lets say 50 objects that are near. But if you have 50 objects near, and you need to update all 50 then a near brick would be lighter.

It’s not making a high vert sphere and checking collisions like that. It’s a lot easier to work things out when your collision is a perfect sphere.

For example, if something collides, it’ll be exactly the radius distance away from the center when it does it. Therefore, you can work out how close something is to colliding with you with a simple formula.

1 Like