There are the pre built collision shapes like spheres. And there is “custom” and that’s anything you give a mesh to and then the mesh will determine collisions as you would expect.
So. Yes, you can just whip up a new collision body, and switch them out or remove them, etc…
Both prebuilt and custom collision shapes are mostly disconnected from the visible geometry, except for the special case where you create the collision body from the visible mesh. But that’s basically the initialization step and what you do afterwards will work the same. So, splitting a main object into two parts and then deleting the old collision shape and creating new ones from the split parts should work as one would expect.
The custom collision shapes work exactly like regular geometry. So if you can update regular geometry, you can do it with collision shapes too. I haven’t looked into it. But if you have something that already does it for graphics, the process should work exactly the same for the custom collision mesh.
The collision system merely loops over the geometry you give it and finds collisions as defined.
The only difference is that you set a collision mask defining how it should collide and to add the shape to the list of things that is being looped over.
I was thinking of some destructible thing where you have a “break” moment where you calculate new parts and it’s just one step, but changing it over time should be possible too.
The thing is, I’m not sure that that’s true: I’m not sure that there isn’t some collision-specific processing of the geometry being done.
In fact, this suspicion of mine is bolstered by the manual:
In the section “Collision System Misuse”, the manual warns against colliding against visible geometry, because:
Even collision geometry constructed from CollisionPolygon objects is significantly more efficient than colliding against the renderable geometry!
And further that:
Various exporters are able to automatically generate optimized collision geometry during the export process.
Which suggests that there is some collision-specific optimisation potentially in effect…
That’s part of my concern: I don’t want something that’s going to prove to be a performance issue. (And don’t want to spend the time implementing such a system only to find that it is such a performance issue. ^^; )
I think CollisionPolygon means quad. If you use mesh, then this is also a CollisionPolygon, but a trangulated one. To use the quad effectively, it must be coplanar. With Quads, collision calculations are performed twice as fast as triangles.
That was an interesting experiment, indeed! (A quick-and-hacky one, mind, and I would like to swear to its validity, but still.)
You are in fact correct!
Based on a simple expedient of traversing a simple ray-cast many times over per frame, the left-hand shape produced a frame-interval of about 100ms, while the right-hand one produced a frame-interval of about 180ms!
If you want to try the experiment for yourself, here’s the code that I used:
from panda3d.core import loadPrcFile, loadPrcFileData
loadPrcFileData("", "show-frame-rate-meter #t")
loadPrcFileData("", "frame-rate-meter-milliseconds #t")
from direct.showbase.ShowBase import ShowBase
from panda3d.core import CollisionTraverser, CollisionHandlerQueue, CollisionRay, CollisionNode
from panda3d import __version__ as pandaVersion
model = loader.loadModel("CollisionSpherePolygon.bam")
#model = loader.loadModel("CollisionSphereTriangle.bam")
ray = CollisionRay(0, 0, 0, 0, 1, 0)
node = CollisionNode("mew")
np = render.attachNewNode(node)
self.queue = CollisionHandlerQueue()
self.traverser = CollisionTraverser()
self.firstTime = True
def update(self, task):
for i in range(1000):
if i == 0 and self.firstTime:
self.firstTime = False
print ("Entries found:", self.queue.getNumEntries())
app = Game()
To perform the test, comment-and-uncomment the relevant calls to “loadModel” (if required), then run the program and press “1” and observe the frame-timer at the top-right.
There are also additional considerations, rdb said that internally the engine wants “buckets” for things that can collide. If the buckets don’t collide, neither will the objects inside them.
That reduces the effort of calculation from
E.g. from 16**2=256
And the efficiency goes up the better you can “bucket” your objects. Rdb said he put in some option for the collision system to try and “bucket smartly” automatically, but you have to turn that on explicitly.
In Blender I made a simple sphere, and exported it twice: once as visible geometry, and once as collision geometry. I then modified the experiment that I posted above to make use of those two models, and repeated my timing-test.
When using visible geometry, the frame-interval is much higher than when using collision geometry.
(And taking a quick look at the egg-file for the visible-geometry sphere, it does look as though it is still composed primarily of quads; it doesn’t seem to have been triangulated, at least before it enters the engine.)
Oh yes, I’m well aware of that! My concern is less related to how I arrange my scene than to how to handle a single given object of unusual requirements…
I’m not saying otherwise–I’m saying exactly what you are.
My point is against the claim just above my post that the reason that the manual warns against colliding with visible geometry is simply a matter of higher polygon counts being expected in such.
But if that were the case, then I would expect to see similar performance from collision and visible geometry, as long as they have the same polygon count (and there aren’t complicating factors, like triangulation). Which doesn’t seem to be the case.
Specifically, here are the claims that I’m addressing: