sharing shapes and setlocalscaling

[Carl]

hello, (and greetings)

I am hoping for some assistance in understanding the best practice of utilizing setlocalscaling and sharing shape objects.

I have many different sized shapes and want to minimized the actual shape object count by sharing the
shape objects.

When do we use setlocalscaling?
would we create shapes with a constuctor scale of btvector3(1,1,1) and then use a setlocalscaling?
or do we somehow use a setlocalscaling on-the-fly?

Ideally I want to have many differently scaled shapes but with very few actual shape objects actually created.
Is this possible or should I only share the shapes when they are exactly the same scale?, if so, what is
setlocalscaling for?

Thanks for any insights into this
Carl

[Flix]

setLocalScaling() changes the local scaling of a given btCollisionShape instance. What I mean is that if you assign the same collision shape to 100 rigid bodies and then you call setLocalScaling() on the shape, the call will affect all the 100 rigid bodies.

To reuse the same collision shape with a different (uniform) scaling you can use btUniformScalingShape (works only for convex shapes), or you can use the btBvhScaledTriangleMeshShape (or something like that: I don't remember the exact name now) to share the same (bvh) static triangle mesh shape and apply to it a (free) scaling factor.

Please read this post http://bulletphysics.org/Bullet/phpBB3/ ... al+scaling to know more about setLocalScaling().

Hope this helps.

[Carl]

hello, thanks-alot for the response!

ok, I get it, however...
The confusing part for me is the fact that shapes take a scale in their constructors *and* the scale
of the shape is influenced by the (set)localscaling.
Therefore a btboxshape created with a constructor scale of btvector(2,2,2) and has a setlocalscale of
btvector(2,4,6) will end up with a 'real' scale of (4,8,12)
This makes coordination between a renderer and the physics world a bit more tricky than if I just created
the btboxshape with a constructor value of btvector(1,1,1) and just use the (set)localscaling for the
entire scale of the shape, then I would have a one-to-one correspondance with my renderer's object scale vector and the physics worlds (setlocal)scale of the shape.

I would say that it would be simpler to just have unit scales of shapes on construction and use setlocalscaling only to scale your shapes.

Unless I am missing something that benifits from this dual sourced shape scaling system?
does anyone know what I am not seeing here?

Thanks,
Carl

[Erwin Coumans]

You are right, using unit-scale shapes would have simplified things indeed, especially for basic convex shapes such as boxes and spheres. For convex hulls or concave triangle meshes though, using a local scaling is more convenient. For Bullet 2.x we added the local scaling feature afterwards as a uniform method for all shapes. We could have removed the sizes of primitive shapes, but didn't want to break the API.

btCollisionShape::setLocalScaling was only added to make it easier to (re)scale existing collision shapes, it doesn't help sharing shapes.
The main collision shapes that take more memory can be shared among different rigid bodies using a special shape: a single btConvexHullShape can be shared among multiple rigid bodies using btUniformScalingShapes with different scaling for each, and similarly a btBvhTriangleMeshShape can be shared using btScaledBvhTriangleMeshShape. See also http://bulletphysics.org/Bullet/phpBB3/ ... f=9&t=5852
Thanks,
Erwin

[Carl]

Thanks for the clarification Erwin.

I now am using pure unit shapes and only use setlocalscaling to change their sizes.

To support cone shapes I had to apply the change
http://code.google.com/p/bullet/issues/detail?id=448
( Thanks! promyclon )

I (went to lengths too) share the shapes between objects, even though they have small memory footprints
and this does therefore not save much memory, or effect performance?

I am planning to do the same for btConvexHullShape's using a btUniformScalingShape.

Unfortunately its only for uniform scaling.
If it was a btVector3 scaling like setlocalscaling, it would be much more flexible to support a complete shared shape system.

I wonder if this ( uniform scaling only ) restriction is necessary? or if I could write a
btNonUniformScalingShape taking a btVector3 ?

Thanks for any insights!
Carl

[Bock]

Also note typically using setLocalScaling() grows the margin which is effectively affecting the physics.

with shape_dimension = 1.0f, margin = 0.04f (default)
calling setLocalScaling(10.0f)
leaves you with shape_dimension = (1.0f+0.04f)*10.0f-0.04f = 10.36f
which I thought was a bit odd.

So beware of that, mind your local scaling factor and margin.

[Erwin Coumans]

Also note typically using setLocalScaling() grows the margin which is effectively affecting the physics.

It depends on the collision shape, so if you see this effect it is important to report the actual collision shape type (btBoxShape? btConvexHullShape? etc)