BEPUphysics

If I've got the facing direction and a point, how can I know if it's on the forward, backward and forward left, forward right, backward right, backward left ?

Let's say you have two vectors, F and D. F is the forward vector (which, if you extract it from an orientation matrix, should already be normalized; if it is from a non-normalized source, normalize it). D is the normalized direction from the source to the point (i.e. normalize(point - source)).

Here are some relevant angle-related tools:
1) angle between F and D = acos(dot(F, D))

Only includes the magnitude of the angle; the result would be the same if D points to the left as it would be if D points to the right.

2) unnormalized axis of rotation = cross(F, D)
angle = asin(length(cross(F, D)))

Once again, the angle alone does not include the 'sign' of the rotation. However, the direction of the cross product does include 'sign' information. For example, if F and D were both on the horizontal plane, the axis of rotation would either point straight up (signifying one sign), straight down (signifying the other sign), or it will be zero (F and D are parallel).

3) unnormalized axis of rotation = cross(F, D)
angle = acos(dot(F, D))

Mixes #1 and #2; sometimes more convenient depending on whether or not the cross product's length is used elsewhere.

4) Project both F and D onto the horizontal plane (set y component to zero). Use atan2 on the two dimensional components to get the angle of both vectors. Compare the result.

5) Assuming you extracted F from an orientation matrix, use the orientation matrix as a basis for measurement. Project D onto the basis. (This can be done by transforming D by the inverse of the orientation. Equivalently, transform D by the transpose of the orientation matrix or the conjugate of the orientation quaternion.) For example, the computation could look like this:

localD = Transform(D, transpose(orientationMatrix))
where 'localD' is D in the 'local space' of the object that has that orientation.

Now, use atan2 on the X and Z coordinates to compute the signed angle of 'localD'.

#5 is pretty easy to implement and is a little more natural than #4 because the steering takes place in the frame of reference of the vehicle, instead of in world space.

when the tank is returned from the target point, he goes forward when it should be a half turn, why ?

Can you make a example plz ?
With differents angle values, to go forward, forward left, left, ect...

When I have 20 tanks, the engine is making lots of lags... It's me ?

Can you make a example plz ?
With differents angle values, to go forward, forward left, left, ect...

The choice of what angle to consider forward/left/etc. and how to steer is up to you; the listed tools are just ways to compute some relevant angles. If you want to investigate a particular option more, try coding up a simple test case and trying different directions to see how it works.

I should also mention that there are ways to handle this problem without actually computing angles. Here's one approach which does part of what #5 did conceptually, except it leaves off the atan2:

From the orientation matrix, you have forward, back, right, and left directions. Simply taking the dot product of one of these directions with D will tell you if D faces in the same direction or in the opposite direction. So:
-If dot(F, D) > 0, then D points somewhere in the forward half.
-If dot(F, D) < 0, then D points somewhere in the back half.
-If dot(F, D) == 0, then D is perpendicular to F.
-If dot(Right, D) > 0, then D points somewhere in the right half.
-... and so on.

when the tank is returned from the target point, he goes forward when it should be a half turn, why ?

Unknown!

When I have 20 tanks, the engine is making lots of lags... It's me ?

Unknown!

I am unable to answer those questions given the lack of context. Further, even if I had the context, they may not turn out to be questions that are suitable for this forum. I cannot afford to spend lots of time answering general non-BEPUphysics-related questions.

Please spend more time:
-working out the details for yourself, and
-formulating focused questions
to ensure that:
-it makes sense to ask me, and
-I am able to answer

I am awfully sorry
I began by asking a question, but by asking another question, I thought you would have realized that I had found the answer. So my last question canceling all others.
So, just so you see the problem well, I decided to install a timer in milliseconds to know the time taken by the physics engine.
So if I put 20 tanks on my heightmap, the time taken by the physical BEPU is 16 to 18 ms.
My heightmap is great.
Would you some tips to reduce this time, because my game runs at 10fps with this two-time taken by the physical

I would recommend first determining if the performance you're getting is within the expected range. If it's abnormal, then the usual simplification tricks probably won't help at all.

However, I'm not sure if that is reasonable or not; if those numbers are on the Xbox360, the tank is quite complex, and the heightmap is very dense, it might be expected.

For reference, on my 3770K, dropping 8000 cubes on the terrain of the TerrainDemo only gets up to around 16 ms maximum once the boxes are piling up. While your tank is more complicated than a single cube, I doubt it costs more than about 10 cubes. By this logic, it would take around 800 tanks in the TerrainDemo to hit 16 ms on my processor. If you can find out how fast your processor is compared to the 3770K, you should get a rough idea of the expected performance.

If it turns out that the performance is reasonable, then you can use the usual approaches to optimization. The biggest boosts are usually obtained by simplifying the simulation: fewer, simpler objects.

Another option would be something like the BEPUphysicsDemos ConfigurationHelper. There's a variety of tuning settings that can reduce the quality of the simulation in favor of more performance. This is a brute force technique and will often fail to provide significant savings if there are other bottlenecks, like extremely complex geometry, but it can still help sometimes.

Okay, So in your terrainDemo I replaced this :
For this :
So I have 7500 cubes.
When all cubes go in the ground, the physic time is about 300ms.
I have a Intel Core I5

Is that 300ms a one-time momentary hitch? Depending on the environment, that might be reasonable if the JIT kicked in at the same time as thousands of collision pairs are being allocated.

If it's a consistent 300ms, then that is about 7-10 times slower than expected. In that particular simulation, on my computer, the first impact jumps briefly to around 50-55 ms due to the initialization cost (which could be avoided by warming the simulation up first), but when everything has fallen (but is still active) I'm seeing somewhere between 30 and 45 ms.

A few things to check:
1) Make sure that the solution is built in release mode, and make sure you are not running it in the debugger. (This is very important! These are huge slowdowns; they slow my simulation execution down to 80-85ms)
2) Make sure nothing else intensive is running. Heavy background tasks might interfere.
3) Check the windows performance tab to make sure all the cores are doing something during the simulation. Once the simulation is partially settled, you should see >80% usage overall with a fairly even distribution if the application has focus. One core will be doing slightly more than others due to rendering. (If you disable the graphics and interface by pressing Y and I, the usage should be closer to 98% overall as the multithreaded work has fewer bottlenecks.)
4) Make sure there's no RAM paging to disk going on or other really nasty environmental effects.

I'm doing it in debug mode.
So when I don't do it with the debug mode, the first impact is at 55ms, but after all impact I'm at 200-240ms

I'm doing it in debug mode.
So when I don't do it with the debug mode, the first impact is at 55ms, but after all impact I'm at 200-240ms

Are you sure the solution is building in release mode, and that you are not running with the debugger? Note that these are two separate things, and they are both important.

The slowest i5 I'm aware of in this situation would probably be a dual core Clarkdale from early 2010, which would be an i5 650. The gap between a 650 and a 3770 could conceivably be 4x on a heavily multithreaded workload like BEPUphysics. (I have a 3770K, not a 4770K like I originally said earlier. I've been reading too many Haswell-related articles )

So, if you've got a i5 650, that would go a long way in explaining the difference. On the other hand, if you've got a 2500 or something along those lines, the difference should not be anywhere near that large.

Here is the description of my processor :
Intel(R) Core(TM) i5 CPU M430 @2.27GHz 2.24GHz


EDIT :

I have another question.
If my heightmap is decompose in chunk so different model.
So chunks are litte than the big heightmap.
Calculs will be speedest or not ?

That's a dual core mobile chip from the early days of i5 branding; it's probably around 5-7 times slower than my processor for this kind of multithreaded job. That happens to fit fairly well with 30-45 ms versus 200-240 ms.

I would suppose that the M430 could handle around 400-500 cubes within 16 ms. Using the previous rough estimate of 10 cubes per tank, that suggests you should be able to run around 40-50 tanks in that time. Now that the gap is narrowed to a mere factor of two or so (though with a large amount of uncertainty introduced by the rough estimate), you can start looking for more 'regular' causes. For example:
1) Make sure multithreading is enabled in the tank simulation.
2) Watch out for external environmental issues like constant GC pressure slowing down everything. For example: you mentioned the physics took 16 ms, and that you had 10 fps. 10 fps corresponds to 100 ms per frame. The remaining non-physics 84 ms should probably be looked at first. If you're running with fixed time steps enabled, temporarily disabling them to get a clearer picture of update times might be a good idea.
3) Make sure that collision geometry is not more complex than it needs to be. Be especially careful of MobileMeshes; they are very expensive. Make sure the terrain is not too dense.
4) Make sure that the tank itself's construction is simple. If a tank has 50 wheels, that will take longer than if it had 10. If it's composed of 10 different connected entities, that's slower than if it was composed of 3.
5) Fiddle with the ConfigurationHelper-related tuning variables to see if you can get some speedups.

I have another question.
If my heightmap is decompose in chunk so different model.
So chunks are litte than the big heightmap.
Calculs will be speedest or not ?

If the heightmap is a Terrain collidable, splitting it should actually reduce performance very slightly. Terrains have constant time access to nearby triangles via simple array access. This is roughly the same no matter how massive the array is. Splitting the terrain would give the BroadPhase more work. It would not be significant, though; if chunking is convenient for other reasons, like streaming a large world, don't worry about it too much.