v0.15.0 Released!

Discuss topics related to BEPUphysics or physics engine development.
RyanGadz
Posts: 32
Joined: Thu Aug 12, 2010 8:34 pm
Contact:

Re: v0.15.0 Early Beta

Post by RyanGadz »

Danthekilla wrote:
RyanGadz wrote:
Norbo wrote: Being able to directly use a Vector3/int array for vertices rather than creating a duplicate also helps keep it down.
yay! thank you
I wonder if it would be possible to use a Vertice List/Array?

Code: Select all

                var verts = new StaticTriangleGroup.StaticTriangleGroupVertex[vertices.Length];
                for (int v = 0; v < vertices.Length; v++)
                    verts[v] = new StaticTriangleGroup.StaticTriangleGroupVertex(vertices[v]);
that is what im doing now
Danthekilla
Posts: 136
Joined: Sun Jan 17, 2010 11:35 am

Re: v0.15.0 Early Beta

Post by Danthekilla »

Norbo wrote:
I wonder if it would be possible to use a Vertice List/Array?
If you mean like a TriangleMesh that accepts VertexPositionNormalTextures or something similar, then no, not by default. But if you find it valuable, you won't have to wait on me to add it in once v0.15.0 is completed.
Well I was thinking it could reduce memory usage and cpu overhead in my game (which has about 100 vertice buffers with all our rendering data of the world in it, rather than models) as we can edit any of the world terrain on the fly during the game...

I could then just hand bepu a new list of vertices whenever a region changes.

But it may be pointless so yer. What do you think?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

But it may be pointless so yer. What do you think?
While it could reduce the memory usage a little, it's a little too specialized to include in the main release. But once v0.15.0 is completed, you'll have more control over how those systems work, so (with some effort) it will be possible to share the vertex data.
Danthekilla
Posts: 136
Joined: Sun Jan 17, 2010 11:35 am

Re: v0.15.0 Early Beta

Post by Danthekilla »

Cool because I have over 1000,000 vertices sitting in memory already for the game and it would just be good to not have to rebuild physics vertices and graphics verts too when a region changes...

Also are static tri meshes editable? (I know heightmaps are but we need tunnels and overhanging cliffs) or do I have to fully remove a static tri mesh and add the edited one whenever something changes?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

StaticMeshes are 'somewhat' editable. If the change doesn't affect the topology of the mesh (moving vertices around), then refitting the hierarchy is sufficient. If the topology changes (changing connectivity, adding triangles, removing triangles, etc) then the mesh has to be reconstructed. Reconstruction is memory and computation intensive for StaticMeshes. Neither refit nor reconstruction should require the addition or removal of the mesh from the space, but that has negligible effect on the the speed.

v0.16.0 is adding in the concept of the general dynamic hierarchy, which has the potential to do very fast, no-garbage adaptations to dynamically moving and changing meshes, just like the broadphase does now. The StaticMesh may move over to using that new hierarchy, or perhaps another type of static mesh will be added that uses it. There will at least be an entity mesh type that uses the dynamic hierarchy.
Danthekilla
Posts: 136
Joined: Sun Jan 17, 2010 11:35 am

Re: v0.15.0 Early Beta

Post by Danthekilla »

Also one other thing I was going to ask you is what kind of overheads are there in creating new static tri meshes?

What are the steps that bepu must undergo from me createing a static tri mesh to it being fullyintergrated into the broadphase and working?

Are there any things that can be changed or optimized in regards to createing and adding static tri meshes to the simulation as like I said I have a dynamic world that is broken up into many regions (over 1000) and want the nearest 20-40 in the physics (nearest 120 get rendered) so I need to remove and add new ones (pregenerated and sitting in memory) when the player moves around... But when any are edited I need to rebuild the changed static tri mesh then re-add it.

Any Ideas on how I should go about all this?

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

Re: v0.15.0 Early Beta

Post by Norbo »

What are the steps that bepu must undergo from me createing a static tri mesh to it being fullyintergrated into the broadphase and working?
It goes something like this:
1) Give vertices/indices to StaticMesh constructor.
2) Construct StaticMeshShape directly from inputed vertices/indices. This is the standard local-space Shape that all collision informations have. This step is just assigning some references, very simple and quick.
3) Construct the TriangleMesh data structure. This involves creating a new TriangleMeshBoundingBoxTree, which is by far the most expensive part of the process. The data is recursively split until it reaches the leaf nodes, generating garbage and performing large numbers of sorts.
4) Some miscellaneous other setup is performed. It's all nearly instant.
5) Adding the mesh to the space just involves inserting the collision entry into the broadphase dynamic hierarchy. As mentioned earlier, dynamic hierarchies are very quick. It's as expensive as inserting a simple box entity to the broadphase. The cost of adding/removing objects from the broadphase will probably be invisible compared to the reconstruction process.
when any are edited I need to rebuild the changed static tri mesh then re-add it.

Any Ideas on how I should go about all this?
Attempt to spread calculations over multiple frames as much as possible. Doing this with an individual StaticMesh wouldn't be trivial, but you can attempt to ensure that only one StaticMesh is being managed (edited, reconstructed) at a time to prevent frame hitches (which may end up being unavoidable).

A complete solution would come in the form of a custom usage of the dynamic hierarchies. The generalized dynamic hierarchy may be fast enough for changing meshes that you don't have to worry about doing anything tricky, but if it does need some extra help, it's not that difficult to spread the update process or even full reconstruction over multiple frames, preventing any single frame from jerking.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

Updated to Beta 21:
-Added ConvexCast (and an overload) and SphereCast to GJKToolbox.
-Cast methods in the GJKToolbox now prioritize accuracy slightly more over speed by default.
-Re-enabled box-box manifold improvement on PC/Xbox360.
-Changed Vertex properties on Triangle entity to return world space vertices; added LocalVertex properties.
-Temporarily added some tests into the Solver. It should have better behavior (in both single and multithreaded cases), but it has slightly worse performance and is spewing garbage all over the place. This will be addressed soon :)
-A kinematic ramming into something else should now properly wake that something else up.
-Fixed an issue with collision margins and contact generation.
preen
Posts: 16
Joined: Sun Feb 20, 2011 6:10 pm

Re: v0.15.0 Early Beta

Post by preen »

V15 greatly improves the stability and determinism of the vehicle. I don't know how but keep up the good work :)
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

Updated to Beta 22:
-Fixed up some structure relating to ShapeChanged events in Entity and CollisionInformation.
-Moved MaximumRadius property to CollisionInformation.
-Added MinimumRadius property to CollisionInformation and corresponding compute methods on shapes in preparation for CCD.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

Updated to Beta 23:
-Added CCD. Every Entity now has a PositionUpdateMode. They can be Discrete, Passive, or Continuous. Discrete objects ignore CCD and integrate their full motion each frame. Continuous objects will sweep using relative linear velocity to avoid missing collisions completely. Passive objects do not initiate sweeps, but will clamp their motion according to continuous pairs that they are involved in. The setting that entities are initialized with is MotionSettings.DefaultPositionUpdateMode, which is Discrete unless changed.
-Improved some shape minimum radius calculations.
-Fixed a bug introduced in the previous version that broke Terrains and fixed a related issue in InstancedMeshes.
-Fixed a bug in CompoundBody initialization. Again.
-Fixed a bug in the TriangleShape boundingbox calculation.
-Fixed a few simulation island bugs on entity removal from space.
-Adding or removing an object from the ActivityManager now activates it.
-EntityCollisionInformation WorldTransforms are now consistent with the post-update entity states.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

Updated to Beta 24:
-Fixed a bug in friction where old data was corrupting the first solving attempt on some new pairs.
-Fixed some tuning variables to match v0.14.3 (improving stability).
-Small box-box testing change reverted.
-Minor performance boost; also removed some solver diagnostic code.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

Updated to Beta 25:
-Added a new stabilization system that helps things settle down, leading to more robust looking behavior.
-CollisionInformationPairs now have a Contacts property instead of a GetContacts and ContactCount. The property returns an enumerable, indexable list of contacts and their associated normal/friction impulses and relative velocity.
-Accidentally deleted the original post in this thread.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

Updated to Beta 26:
-Fixed a bug with the solver that forced it to overwork, resulting in a substantial speedup.
-Condensed the abstractions associated with the Solver.
-Fixed a bug in nonconvex constraint manifold friction.
-RawLists are now properly enumerable.
-Fixed a bug in RawList's CopyTo implementation.
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: v0.15.0 Early Beta

Post by Norbo »

Updated to Beta 27:
-Improved both single threaded and multithreaded behavior. It should also be able to early-out faster, leading to an increase in performance. v0.15.0 now runs as fast (or faster) in single-threaded mode as v0.14.3 did in multi-threaded mode on some simulations :)
-Added OverlappedCollisionInformations to CollisionInformation and OverlappedEntities to EntityCollisionInformation. These are convenience enumerables to help scan the pairs list.

It's getting close!
Post Reply