v0.15.0 Released!
Re: v0.15.0 Early Beta
Updated to beta 15:
-Added Compound-Compound, Compound-StaticMesh, Compound-Terrain, and Compound-InstancedMesh collision cases.
-Fixed some bugs in CompoundBody construction.
-Added some empty constraint constructors (more to come).
-Improved deactivation candidacy computation.
-Added Compound-Compound, Compound-StaticMesh, Compound-Terrain, and Compound-InstancedMesh collision cases.
-Fixed some bugs in CompoundBody construction.
-Added some empty constraint constructors (more to come).
-Improved deactivation candidacy computation.
Re: v0.15.0 Early Beta
Updated to Beta 16:
-Added parameterless constructors for all constraint types.
-Fixed SingleEntityLinearMotor warmstarting.
-Fixed a problem where old corrective velocities were sometimes sticking around in single entity motors when changing configurations.
-Changing the involved entities of a solver updateable will now properly wake up all involved entities (before and after the change).
-Giving a SingleEntity motor a null entity will no longer cause it to immediately explode.
-Successfully tested ForceFields! Finally one area that just worked![Smile :)](./images/smilies/icon_smile.gif)
-Added parameterless constructors for all constraint types.
-Fixed SingleEntityLinearMotor warmstarting.
-Fixed a problem where old corrective velocities were sometimes sticking around in single entity motors when changing configurations.
-Changing the involved entities of a solver updateable will now properly wake up all involved entities (before and after the change).
-Giving a SingleEntity motor a null entity will no longer cause it to immediately explode.
-Successfully tested ForceFields! Finally one area that just worked
![Smile :)](./images/smilies/icon_smile.gif)
Re: v0.15.0 Early Beta
Updated to Beta 17:
-DetectorVolumes should work properly.
-Entity.Tag is an object once again, instead of a string.
-Fixed a bug with changing solver updateable entities after construction.
-Compound body hierarchy is correctly initialized with nonzero bounding boxes now.
-Blended material properties are now computed at the initialization of a pair instead of each frame.
-Changing entity materials now updates pair material properties.
-DetectorVolumes should work properly.
-Entity.Tag is an object once again, instead of a string.
-Fixed a bug with changing solver updateable entities after construction.
-Compound body hierarchy is correctly initialized with nonzero bounding boxes now.
-Blended material properties are now computed at the initialization of a pair instead of each frame.
-Changing entity materials now updates pair material properties.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: v0.15.0 Early Beta
Hey norbo just a quick question.
I think I remember you saying that you were not sure if compound bodys would support compound bodys in them in the .15 branch of bepu...
I was just wondering if this was still the case or if this may get implimented.
Also one other question, I am prototypeing a game made entierly out of generated vertices and not models, but the vertices can change frame to frame and I was wondering what kind of performance issues I may run into with this in bepu .15 I would be removeing and adding upto a max of 2 static tri meshes each frame with around 500-2500 vertices each.
But I was hopeing to also get this running on the phone... which is obviosly very cpu and memory limited which brings me to my 3rd little question, does bepu use less memory in .15 (when not using instanced static trimesh's) as we are running very close to the 90mb memory limit on 2 of our phone games and were just wondering if any memory reductions (however small) would happen for the .15 release (expesially on phone and 360)
Anyway sorry for putting all this in your beta thread feel free to move it or delete it if you wish.
Thanks heaps.
I think I remember you saying that you were not sure if compound bodys would support compound bodys in them in the .15 branch of bepu...
I was just wondering if this was still the case or if this may get implimented.
Also one other question, I am prototypeing a game made entierly out of generated vertices and not models, but the vertices can change frame to frame and I was wondering what kind of performance issues I may run into with this in bepu .15 I would be removeing and adding upto a max of 2 static tri meshes each frame with around 500-2500 vertices each.
But I was hopeing to also get this running on the phone... which is obviosly very cpu and memory limited which brings me to my 3rd little question, does bepu use less memory in .15 (when not using instanced static trimesh's) as we are running very close to the 90mb memory limit on 2 of our phone games and were just wondering if any memory reductions (however small) would happen for the .15 release (expesially on phone and 360)
Anyway sorry for putting all this in your beta thread feel free to move it or delete it if you wish.
Thanks heaps.
Re: v0.15.0 Early Beta
It should be implemented now. I haven't done thorough testing on nested compound shapes yet, but there's no intentional reason why it wouldn't work. They are a little different than v0.14.3's nested compounds though, since the hierarchy is not composed of Entities, but rather CollisionShapes.I think I remember you saying that you were not sure if compound bodys would support compound bodys in them in the .15 branch of bepu...
I was just wondering if this was still the case or if this may get implimented.
Reconstructing a hierarchy every frame isn't going to be particularly fast or friendly to the GC at the moment. It might work with only one or two 500-2500 vertex meshes, but it's hard to say for sure on the phone.the vertices can change frame to frame and I was wondering what kind of performance issues I may run into with this in bepu .15 I would be removeing and adding upto a max of 2 static tri meshes each frame with around 500-2500 vertices each.
That job is better suited to a dynamic hierarchy, somewhat like the current broadphase. The construction times for dynamic hierarchies is very fast, and with some trivial pooling, does not produce garbage like static hierarchies. It may, however, take up marginally more memory and create a 'messier' heap organization. But for that scenario, the dynamic approach would definitely be better overall. A generic reusable dynamic hierarchy is planned for after v0.15.0.
Yes, depending on what is being used. I haven't done any precise measurements on the core systems alone, but when dealing with meshes (static, non instanced), the required memory should have dropped a bit. Before, static mesh vertices were created containing some per-vertex physical data which is no longer there. Being able to directly use a Vector3/int array for vertices rather than creating a duplicate also helps keep it down.does bepu use less memory in .15 (when not using instanced static trimesh's)
In many cases, mesh data can eat up as much/more memory as the core systems, so reducing it should have a noticeable impact.
Other areas have been changed to be more memory friendly, but most of the changes were made with performance in mind, so I'm not sure how much of an effect it will have on total usage.
Re: v0.15.0 Early Beta
One thing I did forget to mention about memory is that you can share collision shapes. For most objects, this is a very tiny savings. If there's a lot of ConvexHulls, CompoundBodies, or similarly complex shapes though, there could be some benefit to both memory and startup time (since you can re-use inertia tensor calculations).
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: v0.15.0 Early Beta
Sounds great.
Hopefully the phone doesn't mind having static tri meshs thrown at it contantly then.
Hopefully the phone doesn't mind having static tri meshs thrown at it contantly then.
-
- Posts: 249
- Joined: Wed Nov 17, 2010 1:49 pm
Re: v0.15.0 Early Beta
Found what is causing the bug in the latest BETA.
OK:
Error:
OK:
Code: Select all
Box debugBox = new Box(new Vector3(-5, 5, 0), 0.2f, 0.2f, 0.2f, 1);
space.Add(debugBox);
Code: Select all
debugBoxes[0] = new Box(new Vector3(-5, 5, 0), 0.2f, 0.2f, 0.2f, 1);
debugBoxes[0].CollisionInformation.Events.InitialCollisionDetected += Events_InitialCollisionDetected;
space.Add(debugBoxes[0]);
Could be my misuse of the new code structure though?The event creator is managed by a different dispatcher; it cannot be added.
Re: v0.15.0 Early Beta
It's definitely a bug; I've located the cause, thanks for the reports. It'll be fixed for the next beta.Could be my misuse of the new code structure though?
Re: v0.15.0 Early Beta
Updated to beta 18:
-Vehicle should now work.
-Fixed a bug in InstanceMesh and Terrain raycasting normal.
-StaticMesh now uses an AffineTransform.
-Collision events should work now in general.
-Fixed a bug with adding Simulation Island Members to the space that are connected to something, but all those somethings lack simulation islands.
-StaticMesh, Terrain, InstancedMesh MaterialChanged events added.
-Fixed a bug with pairwise material handling.
-Vehicle should now work.
-Fixed a bug in InstanceMesh and Terrain raycasting normal.
-StaticMesh now uses an AffineTransform.
-Collision events should work now in general.
-Fixed a bug with adding Simulation Island Members to the space that are connected to something, but all those somethings lack simulation islands.
-StaticMesh, Terrain, InstancedMesh MaterialChanged events added.
-Fixed a bug with pairwise material handling.
Re: v0.15.0 Early Beta
Updated to Beta 19:
-Added Xbox360 and WP7 .dlls to the zip. Brief tests on the Xbox360 showed good overall stability, with a few odd bugs still hanging around. WP7 .dll has not yet been tested.
-Completed the MorphableEntity implementation. Their CollisionInformation can be changed after construction.
-Re-implemented FluidVolume.
-Fixed a bug with removing entities from the space/broadphase.
-Fixed a bug with vehicles and simulation islands.
-Added Xbox360 and WP7 .dlls to the zip. Brief tests on the Xbox360 showed good overall stability, with a few odd bugs still hanging around. WP7 .dll has not yet been tested.
-Completed the MorphableEntity implementation. Their CollisionInformation can be changed after construction.
-Re-implemented FluidVolume.
-Fixed a bug with removing entities from the space/broadphase.
-Fixed a bug with vehicles and simulation islands.
Re: v0.15.0 Early Beta
Updated to Beta 20:
-The WP7 should now load properly.
-Fixed a bug in the box-box special case on WP7.
-The WP7 should now load properly.
-Fixed a bug in the box-box special case on WP7.
Re: v0.15.0 Early Beta
yay! thank youNorbo wrote: Being able to directly use a Vector3/int array for vertices rather than creating a duplicate also helps keep it down.
-
- Posts: 136
- Joined: Sun Jan 17, 2010 11:35 am
Re: v0.15.0 Early Beta
I wonder if it would be possible to use a Vertice List/Array?RyanGadz wrote:yay! thank youNorbo wrote: Being able to directly use a Vector3/int array for vertices rather than creating a duplicate also helps keep it down.
Re: v0.15.0 Early Beta
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.I wonder if it would be possible to use a Vertice List/Array?