API Help File Not Working?

[reeda1283]

Hey I was trying to get a better handle on how Shapes work in the engine, but for some reason the API chm file is not working for me. While the Content, Search and Index panel shows all of the various classes and the pages that contain their member lists, the actual Content (right pane) doesn't load. It says Navigation to Webpage canceled, presumably due to a bad link?

In any case, maybe I could just ask my question here. I am essentially trying to figure out the best way to assign proper collision shapes objects. I can of course programmatically tie box, ball, cone etc. shapes that approximate my in-game object, but this seems like it will get very cumbersome.

Let's say I have a house shape? Do I want to use code to setup a triangle shape and then a box shape for the base? Or do I want to be creating collision meshes in my 3d app and somehow parse them in my code and use them only for physics? Is there a way to pull a mesh or models vertices and create a collision shape from that (and if so, is BEPU capable of removing "detail" vertices from the mesh for the collision shape and just get the outermost boundaries)?

If there is a guide for how this (pretty common) workflow should look, I would be forever grateful.

[Norbo]

Hey I was trying to get a better handle on how Shapes work in the engine, but for some reason the API chm file is not working for me. While the Content, Search and Index panel shows all of the various classes and the pages that contain their member lists, the actual Content (right pane) doesn't load. It says Navigation to Webpage canceled, presumably due to a bad link?

Windows blocks .chm files by default. Right clicking the .chm, going to properties, and clicking unblock should make it work.

I am essentially trying to figure out the best way to assign proper collision shapes objects.

To get the basics, I would recommend checking out the BEPUphysicsDemos samples. In particular, the EntityConstructionDemo shows many different ways to construct a variety of entities.

Let's say I have a house shape

If the house is supposed to be static geometry, then you could just load the vertices and indices into a StaticMesh. That's the most common way to handle environment geometry. There are examples of this in the BEPUphysicsDemos (StaticMeshDemo.cs and others).

The vertex and index buffer extraction can be done in a variety of ways. The demos use a built-in helper method that operates on Models, but any method to get the vertices and indices will work.

If the object is supposed to be dynamic, technically you could still use a pure mesh in the form of a MobileMesh, though it's recommended that MobileMeshes are avoided in favor of simpler, faster approximations unless the mesh form is truly required.

Other options are to take the mesh data, or portions of the mesh data, and create convex hulls. Convex hulls only include the outermost vertices that belong to the convex surface. The performance of convex hulls depends on the number of vertices are in them, so in some cases, it might be a good idea to use a simplified model to generate them. If you create multiple convex hull shapes to represent a single mesh, bundling them into a compound body is a good idea.

The FancyShapesDemo and EntityConstructionDemo both show how to create convex hulls. The EntityConstructionDemo also shows compound convex objects. To get a feel for how it all works together, try grabbing some mesh vertex data and giving it to a convex hull.

So, in summary, here's the general hierarchy of creating collision shapes for mobile entities from most expensive/most closely matching to least expensive/most approximating:
-MobileMesh
-Compound of multiple ConvexHullShapes
-Compound of multiple primitive shapes like Sphere, Cylinder, Box, etc.
-Single ConvexHull
-Single primitive like Sphere, Cylinder, Box, etc.

The closer you can stay to the approximation end of things, the better your performance will be. Simpler objects also tend to behave better since they're easier to manage.

[reeda1283]

This is awesome info, thank you Norbo. I know you are probably trying to keep things manageable, but a quick guide with the exact info here would be very helpful in the Documentation section on CodePlex. The articles start off pretty digestible with the getting started section, but I think moves quickly into more advanced topics which aren't necessary for many types of projects.

Info on how to build shapes/entities for user imported objects would likely be a huge help for most beginners, and would be useful for most/all projects. In any case, thanks again for a great answer. I hope my (admittedly small) donation is of some help in allowing you to keep up the great work!

[Norbo]

I hope my (admittedly small) donation is of some help in allowing you to keep up the great work!

Thanks

[reeda1283]

Well I'm happy to say that I've gotten all this sorted out, and am looking forward to learning convex hulls in the coming days.

However, I did want to see if there was a faster way for me to "create" new entities. Profiling the my "GameObject" creation process tells me that creating a new entity for each object is taking 100x longer than any other part of initialization (per object).

I am already trying to remove as much overhead from the object creation process by using a referenced MobileMeshShape, but the below constructor still runs extremely slowly.

Entity physicsCollision = new Entity(baseObjects[baseID].collisionShape, mass);

I see this becoming a problem where I will have 15-20 enemies spawning at one, which will essentially lock up the game for 2 or so seconds. My shape is maybe too complex (2k verts), but it doesn't seem insanely high. Would love to know your thoughts, and if my workflow is as optimal as it could be.

[Norbo]

MobileMeshShapes and ConvexHullShapes have quite expensive volume/inertia tensor calculations proportional to the number of triangles in the object (on the surface of the object, in the case of convex hulls). It would save a lot of time if the physical properties were shared between entities that have the same shape. If mass, volume, and inertia tensor are given in the entity constructor, redundant calculations will be avoided and it will run extremely quickly.

Here's three ways to get the shape information:
1) Create one entity from the shape. Grab its Volume and LocalInertiaTensor to give to other entities which share the same shape. Note that if the other entities have a different mass, you'll need to scale the inertia tensor proportionally.

2) All entity shapes have a ComputeDistributionInformation method which outputs the computed center, volume, and volume distribution of the shape. The volume distribution is essentially the unscaled inertia tensor which describes how the mass is organized as far as angular motion is concerned. The mass, volume, and volume distribution scaled into an inertia tensor (usually using a multiplier of mass * InertiaHelper.InertiaTensorScale) are passed into the entity constructor.

3) Some shapes have to do quite a bit of shape information computation to construct. For example, the MobileMeshShape has a constructor which outputs the ShapeDistributionInformation directly. The ConvexHullShape can output the computed center position and also some surface triangle information which can be used to later accelerate distribution calculations.

That said, I think I should clarify some things about the performance of MobileMeshShapes. Using a MobileMeshShape that has 2,000+ vertices (implying around 700+ triangles) for dynamic shapes- especially multiple dynamic shapes- is very inefficient. While mobile meshes use a variety of acceleration strategies to keep things fast, they simply cannot compete with approximations. For the runtime price of a couple dozen 700-triangle meshes in collision, you could have hundreds or even thousands of individual primitives. Using one or a few convex hulls in a CompoundBody will be hugely faster, especially if the convex hulls are constructed from simplified low-poly meshes.

[reeda1283]

I do plan to move to convex hulls as for pretty much all meshes soon, as I think only my terrain will need vertex precision. Eventually I will probably have to move to models that include simplified collision meshes as well, but that is further out.

Performance is actually quite acceptable right now on a low end system, so certain optimizations I am saving for later, when I really need them

Oh, and I tried what you recommended. Initially I just tried using the shape/mass/inertiatensor constructor (mainly because I assumed a volume was the same as a shape) and saw no gain.

Then I used in all 4 paramaters like you said: Shape, Mass, InertiaTensor and Volume. I saw a 1400x speed gain (as in 140,000%) in creating objects. Soooo yea, I'll pretty much always do that when generating new entities

[reeda1283]

Last question and then you can close this thread. Is using a ConvexHullShape, casting it to a regular EntityShape and then making an Entity from that any less efficient than just using a straight up ConvexHull entity?

I ask because ConvexHull does not have a constructor that bypasses any of the heavy calculations (like the shape, mass, intertiatensor, volume Entity constructor). Essentially, when I tried to move to ConvexHulls, I saw all of my object load times slow down again

[Norbo]

The prefab entity types like ConvexHull, Box, Sphere, Cylinder, MobileMesh, and so on are just convenience wrappers to ease the creation of entities. There is no harm or slow down in creating an Entity object directly. Casting the object does not change anything about the object itself- just how it is referenced. Note that the ConvexHullShape already is an EntityShape, so no explicit casting is necessary.

[Norbo]

I should also mention that the only thing you lose when using the highest level Entity class is a narrow typed CollisionInformation property. For example, if you look at a ConvexHull object's CollisionInformation type, it shows ConvexCollidable<ConvexHullShape>. When looking at an Entity object, the CollisionInformation returns EntityCollidable. A ConvexCollidable<ConvexHullShape> is an EntityCollidable, but having the narrower type allows you to get convex hull-specific information. You can get this narrowness back by creating an Entity<ConvexCollidable<ConvexHullShape>> instead of an Entity.