ConstantAngularSpeedCurve ?

[kavatortank]

Okay, so I have to manager with friction coef.

Now, I have a problem with the rotations of my turret.
Here is a picture wich represent my tank, and the turret on the tank. In red, this is the center of rotation wanted.
http://imageshack.us/photo/my-images/5/rotation1.png/

But when I rotate the turret, the center of rotation is not the center wanted.

http://imageshack.us/photo/my-images/209/rotation2.png/

So, how I can change it ?

[kavatortank]

This is fixek, but I have an other problem.
I use a ConstantAngularSpeedCurve for the rotation of my turret.
But after a time, the constant speed is higher than the start, why ?

[Norbo]

Without more information, I could only speculate that there's a configuration problem, or perhaps the sample count for the speed controlling curve needs to be increased.

However, using the connecting constraint's RevoluteMotor is probably going to work better with less effort. You can create a constant speed motor by setting the BaseCorrectiveVelocity to something above zero and setting stiffness to zero.

[kavatortank]

I have a EntityRotator applied to my turret, and I use this entityRotator ConstantAngularSpeedCurve to regulate the speed of rotation.
Initially, during the first rotation about 2PI, speed is the one I gave parameter ConstantAngularSpeedCurve, but after a while, the speed accelerates abnormally, there is more control of speed

[Norbo]

With regard to the curve, my previous guesses still hold. However, using an EntityRotator to control a turret which is physically connected to the body of the tank is a bad idea. That connection will fight the rotation of the tank body and introduce stress, potentially leading to strange behavior if the goal location cannot be met.

Using a proper two-entity revolute motor will avoid this problem. Assuming you're already using a RevoluteJoint, you can use its motor to do it.

[kavatortank]

Okay, that works great thanks.
But I want to limit the angle for the rotation.
So I use the revoluteJoint Limit with Minimum et Maximum angle, but how I can modify the position of the limit ?

[kavatortank]

Okay, I limit my target angle without limit angle.
I have problems.
1) When the tank go forward, the wheel rotate great, but when a collision appear the wheel don't rotate, so the graphics wheel don't to. How I can solve it ?
2) When the tank go forward an obstacle, the turret go inside the obstacle, I think is that the mass of the tank is too important but can I solve it too ?
3) The radius of wheels is too low, so the collision doesn't take all my graphic model and if I take a raidus more important, the tank doesn't rotate great, so how I can solve it ?

Thanks men.

[Norbo]

Okay, I limit my target angle without limit angle.

Limiting the target is indeed probably the better option compared to using a limit to constrain the motor, but I'll go ahead and explain the usage of the limit for completeness. The two most directly useful properties are the RevoluteLimit.MinimumAngle and RevoluteLimit.MaximumAngle. These properties are relative to some angle which is defined as 0 (which I'll get to in a moment), but an important thing to note is that the minimum and maximum angles can encompass any part of the rotation. Even if you don't configure the 0 angle, you could set the angles to compensate.

For example, setting limits like this:

Code: Select all

            axisJoint.Limit.MinimumAngle = MathHelper.PiOver4;
            axisJoint.Limit.MaximumAngle = MathHelper.PiOver2;

limits the rotation to an angular area of pi / 2 - pi / 4.

On the other hand, reversing the endpoints:

Code: Select all

            axisJoint.Limit.MinimumAngle = MathHelper.PiOver2;
            axisJoint.Limit.MaximumAngle = MathHelper.PiOver4;

limits the rotation to an angular area of 2pi - pi / 4. It starts at pi / 2 and wraps all the way around back to pi / 4.

To adjust the zero angle direction, set the limit's Basis accordingly. The 'basis' is the constraint's frame of reference. It's attached to the first entity of the connection, so as entity A moves around, the basis will follow it. As described in its intellisense comment, the primary axis of the basis is the rotation axis. The secondary axis- which must be perpendicular to the rotation axis- is the direction of zero angle. The combination of the rotation axis and zero angle axis is used to compute the 'winding' of the angle consistently; that is, which rotation is a 'positive' angle and which rotation is a 'negative' angle.

For example, if (0,1,0) was the rotation axis and you wanted (1,0,0) to be the zero angle direction (both in world space), you could set it like so:

Code: Select all

            axisJoint.Limit.Basis.SetWorldAxes(Vector3.Up, Vector3.Right);

1) When the tank go forward, the wheel rotate great, but when a collision appear the wheel don't rotate, so the graphics wheel don't to. How I can solve it ?

The wheels do not actually exist, so they aren't ever really rotating. The apparent rotation of wheels is a convenience computation performed based on the relative velocity between the ground and the cast impact and the radius of the wheel.

Since the effect is purely graphical, you can choose whatever method you want to make the wheels spin. For example, you could arbitrarily make the wheel graphics rotate at a fixed rate whenever the tank is told to move.

2) When the tank go forward an obstacle, the turret go inside the obstacle, I think is that the mass of the tank is too important but can I solve it too ?

This is related to the mass ratio issue. When the turret hits the obstacle, the heavy tank body depends upon the lighter turret. If the turret's connection has been made extremely rigid, the collision constraint might be the weakest, resulting in penetration. You can force collisions to be infinitely rigid by setting the CollisionResponseSettings.Softness to 0. Setting softness to zero may not end up producing a pleasing result. Depending on the severity of the mass ratio isssues, something could end up freaking out a little bit.

Note that, when using nonzero softness, the softness scales with the effective mass of the collision. So, increasing the mass of the turret will make the impact more rigid without touching the CollisionResponseSettings.Softness field.

3) The radius of wheels is too low, so the collision doesn't take all my graphic model and if I take a raidus more important, the tank doesn't rotate great, so how I can solve it ?

When using CylinderCastWheelShapes, increasing wheel radius will effectively increase the height of the vehicle. This may be responsible for the change in behavior. Shrinking the suspension length appropriately may fix this issue, though a shorter suspension will also subtly change behavior.

[kavatortank]

Okay for one and two, but how can I simulate box for each wheel ( to represent better collision ) ?

[Norbo]

You could make your own wheel shape based on the CylinderCastWheelShape (just use a BoxShape instead of a CylinderShape). The difference probably won't be all that significant, though.

[kavatortank]

I read your post road map and I see it.

Future Wishlist:
-Fracture simulation. The existing (currently private) fracture simulation is promising, so after some clean up, it may become public.

When it become public ?

[Norbo]

That is still unknown; that item has been on the wish list for a while now. It's currently beaten in priority by v1.3.0's completion, some non-BEPUphysics work, and v1.4.0's optimization. At this point, I wouldn't expect fracture to show up before v1.5.0- whenever that is.

[kavatortank]

and there is no way to get this version as a test ?

[Norbo]

Correct; it is really not ready for external use. It's useful as a proof of concept, but adapting it to more general uses would take about as much work as building it from scratch. Releasing it now as a sort of preview would end up creating a lot of work for me.

[kavatortank]

Excuse me but I'm just curious to see it