Hi, I'm Alex, my company sent an email some days ago for a commercial usage of the bepu engine.
As member of the dev team i have to ask some technical questions instead.
1) before bepu we used a custom octree class. I noticed the StaticTriangleGroup and i would like to make use of it instead.
our previous octree was defined into a custom MeshDescriptor to make it shared across all the instances of the same model.
It is the instancing of many StaticTriangleGroup efficient? there is some optimization under the hood so that geometry information isn't duplicated across all the instances?
I'm quite concearned because we are going to use a tileset framework so every tile should have his own StaticTriangleGroup to compute ground collision.
In addition since the creation of a StaticTriangleGroup require so many TriangleMeshVertex (that is a class instead of a struct). I'm quite
concearned about GarbageCollection issues and memory extension of a full scale application.
2) We are using Bepu 0.9, i didn't found in the object browser Controller classes as the CharacterController I read about in the forum.
Questions about StaticTriangleGroup and Controllers
Re: Questions about StaticTriangleGroup and Controllers
1) The current form of StaticTriangleGroups are designed to be used with a few, large meshes. Using a StaticTriangleGroup per tile would indeed duplicate data (the triangle hierarchies, specifically) and would also be less speedy. The TriangleMeshVertex instances could be re-used in multiple TriangleMeshes since the array of vertices is only read by the TriangleMesh and its hierarchy. For your purposes, making a custom solution might be the best route.
The base idea behind the StaticTriangleGroup could still be used. It collects entities, finds triangles that are near those entities, and adds them to the space. When the triangle is no longer needed, it is removed from the space. A pool of triangles is kept handy to avoid reallocations (accessed using the static ResourcePool.getStaticTriangle and ResourcePool.giveBack).
While you don't have to use the TriangleMesh structure to do this, it may make some things easier. There are still some improvements that can be made to the TriangleMesh that I may be able to get to for v0.10.0. The many instances of TriangleMeshVertex created don't trigger any garbage collections as they are kept around for the duration of the TriangleMesh's existence.
2) The character controllers are open source and contained within the downloadable demos project. You can also get a 'simple' version from this thread: http://www.bepu-games.com/forums/viewto ... 75&start=0. I also have a new, more robust character controller that is nearly complete. I will be posting it on the forums in the near future. Both of these character controllers will also be included in the next demos release.
The base idea behind the StaticTriangleGroup could still be used. It collects entities, finds triangles that are near those entities, and adds them to the space. When the triangle is no longer needed, it is removed from the space. A pool of triangles is kept handy to avoid reallocations (accessed using the static ResourcePool.getStaticTriangle and ResourcePool.giveBack).
While you don't have to use the TriangleMesh structure to do this, it may make some things easier. There are still some improvements that can be made to the TriangleMesh that I may be able to get to for v0.10.0. The many instances of TriangleMeshVertex created don't trigger any garbage collections as they are kept around for the duration of the TriangleMesh's existence.
2) The character controllers are open source and contained within the downloadable demos project. You can also get a 'simple' version from this thread: http://www.bepu-games.com/forums/viewto ... 75&start=0. I also have a new, more robust character controller that is nearly complete. I will be posting it on the forums in the near future. Both of these character controllers will also be included in the next demos release.
Re: Questions about StaticTriangleGroup and Controllers
thank you for the quick reply 
let's see what we can do.
let's see what we can do.