Collision margin in bepu 0.15.0

[steko]

Hey Norbo,

what happened to the collision margin? In BEPU 0.14.0 I used (Radius + CollisionMargin) * 2 to calculate the spheres diameter for drawing, now the collision margin is equal to radius and all spheres are therefore rendered in double size.

I found this code in the SphereShape:

//This is a convenience method. People expect to see a 'radius' of some kind.
///<summary>
/// Gets or sets the radius of the sphere.
///</summary>
public float Radius { get { return collisionMargin; } set { CollisionMargin = value; } }

Do I have to remove the collision margin from my rendering code?

[Norbo]

Do I have to remove the collision margin from my rendering code?

That would be the recommended approach, yes. v0.15.0 moved towards making the collision margin 'invisible' from everyday use.

Just as spheres are a point with a large margin, Capsules are also just a segment with a large margin. Boxes now contain their margin within their defined extents (i.e. if you set a box's width to 1, the box's total width with margin is 1, not 1.08 like in v0.14.3).

[steko]

I updated our engine to BEPU 0.15.0. I had to change about 20 lines and now it's working!
I like the new API design from what i have seen so far.
In BEPU 0.14.x I had some strange experience with dynamic compound bodies. This seems to be fixed now, but It seems I have to recreate my compound body if i want do change its behavior from kinematic to dynamic because of DynamicCompoundEntry and CompoundShapeEntry. When I use the BecomeDynamic function of the CompoundBody Entity, the object will fall through the ground.

Is it be possible to get the current build and future builds always as strong named assemblies?

[Norbo]

When I use the BecomeDynamic function of the CompoundBody Entity, the object will fall through the ground.

The kinematic compound does not store enough information to transition to dynamic without some additional work to initialize it properly. This is known and 'intended,' but I would like to deal with it at some point. The compound construction process in general is messy.

Is it be possible to get the current build and future builds always as strong named assemblies?

The complete source code (solution file and all) can be downloaded from codeplex. You can sign the current version if you'd like. I'll probably include signing in future versions.

[Norbo]

The kinematic compound does not store enough information to transition to dynamic without some additional work to initialize it properly. This is known and 'intended,' but I would like to deal with it at some point. The compound construction process in general is messy.

In addition to being messy, there were some bugs in there too. The latest development version has been pushed to the codeplex fork to clean/fix it up (http://bepuphysics.codeplex.com/SourceC ... evelopment). This fork includes the deferred event dispatcher change referred to from the other thread as well.

[steko]

nice work!

just integrated the latest changeset and everything is working now as expected. had some fun playing around with complex dynamic compound bodies.