Has anyone ever done physics culling in the same manner as geometry culling? It doesn't have to be too precise, but I would like to keep from calculating collisions far off screen and using up the CPU. I guess this could apply to everything - sound, ai, etc. So my question is how do you only update the part of your game that is in the general area of the camera? [Edited by - Bixilo on May 7, 2008 3:46:31 PM]

The problem with this is what happens when an object is off screen? You can cull for sounds and etc, but objects should still be moving/colliding/etc even when you don't actually see them. This was solved in many older games by ignoring things offscreen (they literally were removed once offscreen), but that hasn't been the case since SNES! :D Keep in mind that if you throw a grenade then turn around, that grenade will still bounce then explode, even though you're not facing it.

resting objects in a game don't collide and it's generally accepted that a majority of objects will come to rest in a physic system. Those are marked as inactive and stuff. This is actually a basic thing in physics engines so it solves many problems you might be thinking where there's 10,000 physics entities on the map. Basically only those that are active are updated. Like a pile of stacked boxes aren't updated until something happens to them so they are pretty much like static geometry that are easy to cull away.

Broad phase collision detection takes up a majority of the culling. A moving physics object can only effect objects around it. If you really want you could just pause objects that are past a certain distance from the player, however it might not be necessary depending on if you expect only a few physics objects to be active at a time. Think of a game like half life. How many physics entities in that game were active at a time. It was generally very low around 25 or smaller.

Make sure you are familiar with things like octrees. I assume you are since you talked about graphical culling.

Thanks for your replies, due to them I decided to not worry about physics. About 75 objects on the screen cause a drop in framerate - I suppose that's more than enough. Now I have a quadtree structure (it's a 2d game) that has the added attribute of all the smallest cells being linked together like a 2d linked list. The linking allows objects to add/remove/move their bounding boxes to different locations when needed. The quadtree aspect allows picking and determination of which cells are visible quickly. And, of course, the whole thing is used for broad phase collision detection.

I don't to be a bad news bear, but 75 objects is not a lot. You should be able to easily have 75 _active_ scene objects. That means you should safely be able to have hundreds of inactive scene objects.

Try stripping everything not physics related from your setup. Isolate your physics engine when testing it.

I'm not sure if this will work or if you're already using it, but could you break your world/room/space into chunks? So let's say you have a room, and it's broken into three rectangular sections. One on the left, one middle, one right. If you have a movable object on the left, it doesn't need to be calculated with the stuff on the right hand side. So the physics calculations only apply to a node-section and adjacent nodes, but that's it (excluding large objects).

Would that be feasible?

I have profiled the application and physics is definitely what lags it - 70% of the time spend in the physics call. I do split up the map into sections like that, unfortunately the library I use (Phys2D) isn't quite compatible with such a setup. The library does precise physics, but I looked at the code and it appears very inefficient. If it gets too laggy I'll probably have to code my own, unless someone can suggest another 2d physics engine in java.