collision scales (and CollisionBox)

Scaling is not recommended to not make a solid end up inside another one the next frame, right? But what about scaling upon creation of the collision node? Wouldn’t it be okay to scale a sphere along Z to make it like a capsule and use it for characters, instead of using multiple spheres on top of each other?

Also, is Box implementation complete? I’ve seen it in the API doc, but not in the manual page: … ion_Solids
It would be nice to know what they can collide with in the list in the bottom of the page.

Also, any plans to make tube a from object? I’ve seen it used in some Bullet demos, sounds like a perfect shape for characters.

And whats the difference between CollisionFloor and using CollisionPolygon for the floor? I’ve only seen people use the last one.

Scaling is sort of supported. Non-uniform scaling is not supported. You can’t turn a sphere into a capsule through scaling.

The CollisionBox is spottily implemented. It was done by a student project over a summer, and no one has revisited it. Some issues remain.

I’d be happy to accept your patches to make a CollisionTube function as a from object. :wink:

A CollisionFloorMesh is a simpler (and slightly faster) way to represent a mesh of connected polygons that make a contiguous floor. If you have only a single CollisionPolygon, that’s probably better. But if you have a mesh of polygons in a rectangular shape, consider the CollisionFloorMesh.


My python skills would be pretty useless here.

I don’t understand this.

If you’re using a mesh that resembles a plane, make it a CollisionFloorMesh.

So CollisionFloorMesh is like CollisionPlane which is not infinite?

No, a CollisionFloorMesh is more like a collection of CollisionPolygons. If you don’t understand it, don’t worry about it–just use CollisionPolygon.


Well I understand that you mean CollisionFloorMesh is like a collection of collisionPolygons which is faster probably because you don’t have to check for collision on all of the vertices like when using a single CollisionPolygon. But I still want to know whats the difference of just using multiple CollisionPolygons in a CollisionNode. It seems to do the exact same thing to me.

The result is indeed exactly the same. It’s only a question of computation effort. The CollisionFloorMesh can take a few shortcuts, knowing that all of the polygons in its mesh are edge-connected and nonoverlapping.

But these shortcuts are small, so there’s not a real big performance difference either way. That’s why I say don’t worry about it if you’re not sure about it.