Simple Help! and Grats!

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
MDiaz
Posts: 2
Joined: Wed Jun 06, 2012 6:01 pm

Simple Help! and Grats!

Post by MDiaz »

Hi! Congratulation on this amaizing engine!

I got a question, i implemented the engine on my project and everything ok, it works... but i only know how to attach "primitive" objects (spheres, cubes) to my models... is there any way that the engine uses the model for the collision (i mean the vertices of the model) to make it more realistic than a box wrapping my model... i'been reading a lot in the forum and they talk about something called StaticMesh (sorry, im starting at this...but i know a lot of programming), i used and it accept it as an Entity... but i never give the position or the mass of it... im kinda lost...

Can anyone give me an advice on how to attach an Entity (for the Space) to my Model but with the shape of the model?

Thanks in advance!
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Simple Help! and Grats!

Post by Norbo »

A StaticMesh is not an Entity; it is a Collidable (which is a BroadPhaseEntry). In other words, it exists to generate collisions with entities, but it is incapable of motion. Space.Add accepts any object which implements ISpaceObject, not just Entity objects.

The MobileMesh, on the other hand, is an Entity and is capable of motion. However, it is almost always better to approximate the model with faster versions.

In a rough order from fastest/most approximate to slowest/closest representation:
-Simple primitives like BoxShape, SphereShape, etc.
-More complicated primitives like ConvexHullShape
-CompoundShape of BoxShape, SphereShape, etc.
-CompoundShape of ConvexHullShapes (you can, of course, use other simple primitives with it too if convenient)
-MobileMeshShape

Also note that would not be a good idea to try to modify a MobileMeshShape on the fly to match an animating character model. Instead, if you have an animated model, consider placing a set of simple primitives representing the segments of the body and controlling their motion. Check out the ragdoll demo to see how the shapes could look.

To learn the basics of the engine, I would recommend checking out the Getting Started documentation/demos. Also, check out the BEPUphysicsDemos project source contained in the main source download; there's a whole bunch of different simulations to fiddle with.
MDiaz
Posts: 2
Joined: Wed Jun 06, 2012 6:01 pm

Re: Simple Help! and Grats!

Post by MDiaz »

Thanks for the answer... i tryied with MobilMesh and it didnt fit to the mesh i use (i made a Triangle on 3dsmax -> export .fbx and load), i checked the BEPUExamples and the thing that i want to do is on the Example number 8... im going to check that!

Thanks!
User avatar
Piranha
Posts: 8
Joined: Fri Jun 01, 2012 12:20 am

Re: Simple Help! and Grats!

Post by Piranha »

Norbo wrote: In a rough order from fastest/most approximate to slowest/closest representation:
-Simple primitives like BoxShape, SphereShape, etc.
-More complicated primitives like ConvexHullShape
-CompoundShape of BoxShape, SphereShape, etc.
-CompoundShape of ConvexHullShapes (you can, of course, use other simple primitives with it too if convenient)
-MobileMeshShape
Thanks for that too! I noticed a few days ago that the generation of a MobileMesh took over 2 seconds(!) with just 32 vertices. Using a StaticMesh it took just 8ms (which is still quite slow on just 32 vertices).

Is the StaticMesh the fastest non-dynamic concarve collideable in BEPU ? Because im looking for something for this shape.
Image

In fact of that you can walk on the planet, I need the static mesh for "triangle perfect" collision. Is the StaticMesh the type you would recommend too? Or is there something that is faster? I can't use your Terrain type, because it don't seem to handle curvature :(
(The reason why im not happy with this 8ms is that I need 4 of them when creating a deeper chunk, what results in 32ms just for object creation)


Sorry MDiaz for abusing your thread, but your question fits good on my problem.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: Simple Help! and Grats!

Post by Norbo »

The speeds I was referring to were runtime speeds for collision tests, not so much construction times. StaticMeshes are faster than MobileMeshes in terms of collision tests, though.

As for construction speed, 2 seconds is orders of magnitude longer than the mobile mesh should take. On my desktop, constructing a 176 triangle mobile mesh (the tube model) takes around 0.6 milliseconds. That's over three thousand times faster than 2 seconds, and for a larger model too. Some shenanigans are likely afoot; not even a phone is that much slower than a single core of this desktop.

Constructing a StaticMesh from the same 176 triangle mesh takes about 0.1 milliseconds. If your goal is maximum construction speed, then among the arbitrary concave meshes, the StaticMesh is the best bet. (If you could use heightmaps, then Terrain would win at 0.6 milliseconds for 64,082 triangles and 5 milliseconds for 522,242 triangles.)
Post Reply