Page 2 of 5

Re: v0.15.0 Early Beta

Posted: Thu Feb 17, 2011 9:18 am
by Norbo
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.

Re: v0.15.0 Early Beta

Posted: Fri Feb 18, 2011 9:17 am
by Norbo
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 :)

Re: v0.15.0 Early Beta

Posted: Sat Feb 19, 2011 9:31 am
by Norbo
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.

Re: v0.15.0 Early Beta

Posted: Sat Feb 19, 2011 10:04 am
by Danthekilla
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.

Re: v0.15.0 Early Beta

Posted: Sat Feb 19, 2011 7:37 pm
by Norbo
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.
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.
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.
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.

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.
does bepu use less memory in .15 (when not using instanced static trimesh's)
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.

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

Posted: Sat Feb 19, 2011 11:46 pm
by Norbo
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).

Re: v0.15.0 Early Beta

Posted: Sun Feb 20, 2011 12:25 am
by Danthekilla
Sounds great.

Hopefully the phone doesn't mind having static tri meshs thrown at it contantly then.

Re: v0.15.0 Early Beta

Posted: Sun Feb 20, 2011 10:20 pm
by Spankenstein
Found what is causing the bug in the latest BETA.

OK:

Code: Select all

            Box debugBox = new Box(new Vector3(-5, 5, 0), 0.2f, 0.2f, 0.2f, 1);
            space.Add(debugBox);
Error:

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]);
The event creator is managed by a different dispatcher; it cannot be added.
Could be my misuse of the new code structure though?

Re: v0.15.0 Early Beta

Posted: Sun Feb 20, 2011 11:00 pm
by Norbo
Could be my misuse of the new code structure though?
It's definitely a bug; I've located the cause, thanks for the reports. It'll be fixed for the next beta.

Re: v0.15.0 Early Beta

Posted: Mon Feb 21, 2011 9:25 am
by Norbo
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.

Re: v0.15.0 Early Beta

Posted: Tue Feb 22, 2011 8:56 am
by Norbo
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.

Re: v0.15.0 Early Beta

Posted: Wed Feb 23, 2011 8:39 am
by Norbo
Updated to Beta 20:
-The WP7 should now load properly.
-Fixed a bug in the box-box special case on WP7.

Re: v0.15.0 Early Beta

Posted: Thu Feb 24, 2011 6:42 pm
by RyanGadz
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

Re: v0.15.0 Early Beta

Posted: Fri Feb 25, 2011 3:14 am
by Danthekilla
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?

Re: v0.15.0 Early Beta

Posted: Fri Feb 25, 2011 3:49 am
by Norbo
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.