Page 1 of 1

Static ConvexHull

Posted: Sun Apr 14, 2013 9:37 am
by stino
I'm not entirely sure, but from what i find in browsing through bepu i come to the conclusion that InstancedMeshShape is the only way to create static geometry?

I've been trying to find how i can create a convexHull and position it in the world as a static collision shape like unreal engine does. But either i can't find a way how to transform the ConvexHullShape to the correct location, or the thing isn't static.

I'm not using XNA but i have a written similar content pipeline for slimdx.

I'm trying to create the collision shapes from a mesh and then save them to an asset file.
and for that purpose i have a generic class that wraps up a collidable with my asset saving/loading code.
But i've only figured out how to do this successfully for the InstancedMeshShape, as the InstancedMesh takes that shape + an AffineTransform.

but for the ConvexHullShape i can't seem to find what class i need to use for the shape + AffineTransform and have it immovable and not collide with other static geometry.

What am i looking over here?

Re: Static ConvexHull

Posted: Sun Apr 14, 2013 5:44 pm
by Norbo
but from what i find in browsing through bepu i come to the conclusion that InstancedMeshShape is the only way to create static geometry?
"Static" geometry in BEPUphysics tends to refer to objects which are incapable of motion. There are four such static types built in: StaticMesh, InstancedMesh, Terrain, and StaticGroup.

Then, on top of that, you can create entities without a mass parameter specified. These 'kinematic' entities do not collide with other static/kinematic objects by default and do not move in response to forces (they have effectively infinite mass). Kinematic entities can be used to place static geometry, though it's typically not the best choice for performance. Generally, entities are used when the object is capable of velocity-based movement. Moving elevators or fully dynamic objects are good usages for entities.

Should you find yourself wanting to place a bunch of static objects with entity shapes but not needing the capacity for movement, then the StaticGroup is what you want. Check out the StaticGroupDemo in the BEPUphysicsDemos for an example of its usage. You can bundle a bunch of entity shapes and static shapes together in one efficient group.
But i've only figured out how to do this successfully for the InstancedMeshShape, as the InstancedMesh takes that shape + an AffineTransform.

but for the ConvexHullShape i can't seem to find what class i need to use for the shape + AffineTransform and have it immovable and not collide with other static geometry.
Not all shapes and object types are able to support all types of transformations. ConvexHullShapes, for example, cannot be freely transformed with an AffineTransform. Many entity types can only take a RigidTransform directly because entities are only capable of rigid motion. The TransformableShape exists for this reason: for a little runtime computational cost, it can wrap any convex entity shape with a linear transform. You can then use the resulting TransformableShape in either an entity or a StaticGroup.

Re: Static ConvexHull

Posted: Mon Apr 15, 2013 8:32 am
by stino
So from what i understand, it would be more efficient (performance wise) to use the InstancedMesh for all static geometry instead of using a convex hull through a TransformableShape in a StaticGroup? Or is that computational overhead only when setting up the acceleration structures?

I've edited the StaticGroup Demo to use convex hulls instead of instanced meshes:

Code: Select all

            var points = new List<Vector3>(vertices);
            var output = new List<Vector3>();
            ConvexHullHelper.GetConvexHull(points, output);
            ConvexHullHelper.RemoveRedundantPoints(output);
            var convexShape = new ConvexHullShape(output);
and inside the loops:

Code: Select all

var transform = new AffineTransform(
                            new Vector3((float)random.NextDouble() * 6 + .5f, (float)random.NextDouble() * 6 + .5f, (float)random.NextDouble() * 6 + .5f),
                             Quaternion.RotationAxis(Vector3.Normalize(new Vector3((float)random.NextDouble(), (float)random.NextDouble(), (float)random.NextDouble())), (float)random.NextDouble() * 100),
                            new Vector3(i * xSpacing - xCount * xSpacing * .5f, j * ySpacing + 50, k * zSpacing - zCount * zSpacing * .5f));

                        var hullShape = new TransformableShape(convexShape, transform.LinearTransform);

                        var hull = new ConvexCollidable<TransformableShape>(hullShape);

                        hull.WorldTransform = new RigidTransform(transform.Translation);
                        

                        //var mesh = new InstancedMesh(meshShape, transform);
                        //Making the triangles one-sided makes collision detection a bit more robust, since the backsides of triangles won't try to collide with things
                        //and 'pull' them back into the mesh.
                        //mesh.Sidedness = TriangleSidedness.Counterclockwise;
                        //collidables.Add(mesh);
                        //game.ModelDrawer.Add(mesh);

                        collidables.Add(hull);
                        game.ModelDrawer.Add(hull); // yay, waiting time
and all of a sudden, halfway the simulation i get the exception "Inappropriate types used to initialize pair."

Re: Static ConvexHull

Posted: Mon Apr 15, 2013 6:34 pm
by Norbo
So from what i understand, it would be more efficient (performance wise) to use the InstancedMesh for all static geometry instead of using a convex hull through a TransformableShape in a StaticGroup? Or is that computational overhead only when setting up the acceleration structures?
A TransformableShape wrapping a ConvexHullShape incurs a little extra cost during every collision test. It's only a simple transform though; depending on the context, the TransformableShape's overhead might not be easily measurable. With or without a wrapping TransformableShape, a ConvexHullShape will likely be significantly cheaper than an InstancedMesh. Colliding with an InstanceMesh involves testing collision against every individual triangle overlapping the object's AABB. This could be dozens of triangles. While the triangle-convex test is quite speedy, it's hard to beat the single convex-convex test used by the convex hull option.

However, there are always exceptions. Measuring the actual performance for your particular use case is the most reliable way to know. In either case, an important optimization is to keep the physics representation relatively simple with as few triangles as necessary to approximate the graphical shape. This will help both approaches significantly.
and all of a sudden, halfway the simulation i get the exception "Inappropriate types used to initialize pair."
That's interesting; I am unable to replicate the failure on the current development version or the older slimdx fork. Were there any other relevant changes?

And, just in case: was there a CharacterController involved? I think there may exist a spectacularly rare bug where this exception can occur while the CharacterController is walking around across multiple support objects in a multithreaded context, but I've so far failed to isolate it. Finding a reproduction case for this bug would be extremely handy.

Re: Static ConvexHull

Posted: Tue Apr 16, 2013 10:12 am
by stino
There actually was a character involved, i was jumping down the stack of convex hulls and landed inside the layer with instanced meshes on a box that was standing on the mesh and then it gave the exception.

and so far I've only had it happen 2 times in the course of a day experimenting with the demo, so, rare indeed.

Re: Static ConvexHull

Posted: Tue Apr 16, 2013 9:02 pm
by Norbo
I'm currently attempting to track it down. Any additional information you can provide about the context of the crash might be helpful. Was it a CharacterController (the demo default), or a SphereCharacterController? Was this in the latest versions, or was it in v1.2.0 or one of the forks?

Re: Static ConvexHull

Posted: Wed Apr 17, 2013 12:35 am
by Norbo
A few more possibly-helpful questions, if you remember or encounter the issue again:
-What was the stack trace of the exception (did it come from a character controller query, or did it come from the NarrowPhase process)?
-What was the type of the pair handler that failed?
-What types were passed into the Initialize method where the exception was thrown?
-Was there a vehicle involved? Hitting 'v' would spawn the vehicle, and I have evidence to suggest that the vehicle is a 'person of interest' in the case, so to speak.

Re: Static ConvexHull

Posted: Wed Apr 17, 2013 2:18 am
by Norbo
I've just fixed a bug which at least shares the same symptoms. StaticGroup-Compound pairs had a broken initializer that would fail with the reported exception. In the StaticGroupDemo, this would show up when the vehicle came near the StaticGroup sometimes.

I'm not entirely convinced that this is the only issue in play, though. It is conceivable that I confused myself into thinking it was character related by coincidence (C and V are close to each other, after all!), but I wouldn't be surprised if another bug still haunts.

Re: Static ConvexHull

Posted: Sun Apr 21, 2013 3:38 pm
by stino
Oh, sorry, been a bit busy with another project, lost track of this thread.

The demo was fully at it's defaults, only the instanced meshes got replaced by the convex hull code a few posts above.

It was definatly not the vehicle as i was in character mode running/falling down around when it happend.

I'm currently on a workstation with only vs2012, (mans no XNA). If i get the exception in my SlimDX project, i'll try to dump a complete stacktrace and some involved objects in here. And when i'm back at the other workstation i can try the same for the demo.

I'll also try with the latest "codeplex source code " version to see if it's still there.

Re: Static ConvexHull

Posted: Tue Jul 02, 2013 3:11 pm
by stino
I haven't seen this reoccurring since, so I'd guess the fix fixed it! hurray!