BEPUphysics

I want that my turret follow the camera.
So I saw the sample of pathfollowing, but the fact is that the angular speed is to hight. After I the class ConstantAngularSpeedCurve to control the angular speed, but when I use it, the program crash, why ?

For the start I use that :
And after in the update methode I use that :
But with only QuaternionSlerpCurve this code works.
Thanks

After I the class ConstantAngularSpeedCurve to control the angular speed, but when I use it, the program crash, why ?

There appears to be a bug in the SpeedControlledCurve's evaluator. It should be fixed in the latest commit. Thanks for the report!

I want that my turret follow the camera.

Paths are not a great fit for this. They're designed for long sequences of control points.

In addition, trying to control the orientation of the turret directly will interfere with the constraint system and collisions. Changing the orientation directly is effectively teleportation; it's not a normal dynamic behavior. Even if a SingleEntityAngularMotor/EntityRotator was used instead, it will still interfere with the constraints because the force would have no physical link to the tank itself.

Instead, I would recommend just using the the motors in the constraints directly. Each RevoluteJoint has a RevoluteMotor. You can compute the desired velocity from the camera input, or put the motor into servo mode and specify the goal angle. Either of these methods will ensure proper physical interactions.

You may find that using the velocity motor approach is easier than using a servomechanism. This is because the goal angle of a servo is relative to some measurement basis; unless the initial constraint construction guessed correctly, you'll have to tell it which direction is 0 degrees and which direction is 90 degrees. A basic example of servo-mode motors can be found in the RobotArmDemo.

Ok but there are a few bug

I have to replace my code with that :
EDIT :

I download the lastest version and I have lags, it's normal ???

One-point paths aren't a fully supported concept for speed controlled curves (because controlling the speed on such a curve would have no effect), but I went ahead and added a protection against throwing an exception unintuitively.

You don't need to create that curve at initialization by the looks of it, though, since the path gets recreated every frame anyway. Still, I would recommend using the motors instead.

I download the lastest version and I have lags, it's normal ???

If it seems slower, make sure you're compiling in release mode without the CHECKMATH symbol. If CHECKMATH is defined (which it is by default under the debug configuration), lots and lots of debug checks are inserted all over the engine.

How I know if it's disable ? Where it is ?

It is a compilation symbol; you can check it in the build properties on the project (double click Properties in the BEPUphysics project, go to Build tab, check "Conditional compilation symbols:" field for CHECKMATH). If you're compiling the downloaded BEPUphysics solution, then the Debug configuration will have CHECKMATH defined, and the Release configuration will not. Release should be used for performance reasons unless you're actively trying to debug something in BEPUphysics.

I remove it, but nothing change, I have lags.

If anything, the latest version should be faster, so added lag is not expected.

What kind of 'lag' is it? Jerky motion? Extremely slow physics update speed? A video may help me determine the cause, particularly if it's recorded in the BEPUphysicsDemos.

I do not know why, but the lag does not appear at same time. This means that when I run the program, there may be lags of different types:
- The lag fades after a while I infer that there must be a load for the physical but there is no lag every time
- When my tank fired a missile, it does sometimes but rarely

Sorry, I can't reproduce any slowdown which matches the description, and I can't isolate the source based on the information provided.

If you're seeing this lag outside of the BEPUphysicsDemos, it would be a good idea to insert timestamp checks in various places to collect some shallow profiling results. For example, in the BEPUphysicsDemos, the physics time is measured by checking a timestamp before and after the physics, and the frames per second is measured separately. This would allow you to see the time physics is taking in isolation in comparison to total frame time.

If the physics time is unusually large and dominates total frame time, then physics can be investigated more thoroughly. This doesn't necessarily imply the physics are directly at fault (since the slowdown may be external, e.g. GC pressure), but it is at least a starting point. If, on the other hand, the entire frame seems to be slowing down proportionally, or if physics aren't a significant chunk of frame time because frame time spikes without a physics time spike, then the problem is more solidly isolated outside of physics.

You could also make use of a proper profiler (ANTS, DotTrace, SlimTune, EQATEC, etc.) to narrow down the cause further. You may find that something like the CLR profiler would help in tracking down GC-related performance issues.

When lags appear the physic time grow to 24ms. And I have modify a bepuphysic Demo

Sorry, I do not have enough information to help further. If you'd like, I could take a look at the demo setup you created in BEPUphysicsDemos.

Okay,
So I have lags at certain moment.
I upload my DemoBepuPhysics project in my dropbox public file.
So you just have to replace the Demo project.
https://dl.dropboxusercontent.com/u/131 ... sDemos.rar

The demo to test is the WallDemo ( number 2 )
I have charge different model with staticMesh and a long wall.
Lags appear when I moove quickly the camera with the mouse.
To test this demo you have to activate the Tank because the lags appear with it.
For that, it's the same that the car, you have to press V.

Thanks.

It runs fine for me; there are no noticeable spikes or performance problems. The worst physics frame time I noticed was 4.5 ms while I was firing constantly and driving through the wall, though it typically stayed below 3.5 ms even during that. If I let the wall go inactive and didn't shoot things, physics time never went above 1 ms. I did not observe any lag while moving the mouse quickly while using the tank.

Some of the gap between what you see and what I see may be caused by processor differences. I have an i7 3770K; if your processor is ~5 times slower, seeing 24 ms briefly might be reasonable during periods of extreme simulation activity.

If you're seeing momentary jerks and halts, I would guess it's related to GC issues or perhaps graphics reconstruction:
1) Right now, projectiles, debris, and other objects are created on the fly rather than being reused. This will eventually result in a garbage collection which, depending on your hardware and environment, may be visible.
2) Potentially more pressingly, it's adding and removing objects from the ModelDrawer frequently while firing. The ModelDrawer is not at all designed for performance, especially with regards to adds and removes (after all, it's just a debug visualizer). Big batches of vertices will be created and thrown away frequently. Creating batches takes a lot of raw computing power, and throwing away old batches causes a lot of garbage.

Hum, when I see lags, I look to the physic time, and you are write it's under 10ms, so it's the graphics, and it's not bepuphysics engine.
I'm going to include bepuphysics engine in my project.
My project uses a standard architecture. My project runs on XNA.
That is to say that I cut my game subproject:
- One for the processor happy to load my private assets.
- One for my engine that inherits XNA, it uses a system standars scenes with graphs and physical players.
- One for my game (gameplay) using my engine.
What do you Recommend to me to integrate bepuphysics?