Refactoring joints

[JoeJ]

Single threaded: 5.2 ms
Four threads: 5.4 ms (guess no improvement because single island?)
i7 930

Although the tracks don't get to rest and keep jittering, the demo shows big improvement. Tracks more robust now.

If one picks up the vehicle with the mouse, is there some external force applied to make it move?
Otherwise i'd worry about where all this energy comes from (both linear and angular).

instead the link are constrained to the path with just one link.
I never though thsi would work, but so fat seem stable enough.

I've had similar experiences. You can do a lot more with joints if they act directly on COM.
* Used single row distance joints from feet to every other body in the ragdoll before new stiff joints came up. (Added a bit of micro jitter, but ok)
* The one legged hopper uses only one joint and two bodies. So the joint is both angular and linear motor.
Nothing of this works with an offset to the COM.

[Julio Jerez]

In a my computer home and the one at work which is an I7 4820k I get fro 3.1 to 3.5 ms

but there is good knew on that front, I took a vs profiler capture and you cna see that at teh high level the dynamcis dominate everything by a factor of almost 20.

Code: Select all

Function Name   Total CPU (%)   Self CPU (%)   Total CPU (ms)   Self CPU (ms)   Module
 - dgWorld::RunStep   13.37%   0.00%   2130   0   demosSandBox.exe
   - dgWorld::StepDynamics   13.32%   0.00%   2122   0
     + dgWorldDynamicUpdate::UpdateDynamics   11.98%   0.00%   1908   0
     + dgBroadPhase::UpdateContacts   1.28%   0.00%   204   0


the is I expand the solver we can see that the contact solver dominate almos everything by a factort of almost 10

Code: Select all

Function Name   Total CPU (%)   Self CPU (%)   Total CPU (ms)   Self CPU (ms)   Module
   dgWorldDynamicUpdate::CalculateJointForce   6.74%   6.74%   1073   1073   
 + dgSkeletonContainer::InitMassMatrix   2.59%   0.01%   412   2
 + dgSkeletonContainer::CalculateJointForce   0.82%   0.46%   131   73
   dgBilateralConstraint::JointAccelerations   0.21%   0.21%   34   34

but guess what CalculateJointForce is the function that we can parallelize even on single island.
I have the paraller solve commented out because it has some problems, but for 3.15 there will be another mass matrix factorization that will allows to solve single island in parallel.
the down size if the is reduce the converge rate because the resulting mass matrix is one the yield the same rate for both Gauss Sidel and Jacobi iteration.

but if this works, the there will be no need to make island, or we can make an option, so we do no nee to worry too much about that for now.


The jitter is a concern, but I have an idea what it is, teh new joint nwo issue the stiffness for each row, an dteh defaul is 1.0, before some joint did and soem did not, I will complere to the version befre dec 31 and see if it does the same thing.


last there is no way to drive now, because I need to re write the servo joint which are all commented out. I will do that tonight.
Are you talking about the vehicle getting a kick when you let go of the mouse pick, I did see that is some case, but I do not know why is happened.
I will make a replay to see if I can reproduce it.

But all in all this much better than the previous demo. The tracks are part of the vehicle, so the get the same solve pass and they remain attached to the vehicle without assistance.

you can rather the whole thing and get the tracks off but if, I claim that the mouse apply a lot more force that what you would need to break a real vehicle.
Remember mouse forces are unbounded, they can not be the Lemon test for robustness and stability.

[JoeJ]

Are you talking about the vehicle getting a kick when you let go of the mouse pick,

No, i mean what happens if you drag the vehicle up to air and keep holding it. But thinking of it, it's surely error feedback because the camera is fixed to the vehicle, so the picking as well and this constantly adds force
But it might be worth to test this with default camera to see what happens with so many joints.

[Julio Jerez]

oh yes, there may be some camera feedback there.
I will go on, if there is a bug the, I am sure it will show up in some other setting.

I made a change which goes along the line of reducing the number of call to the contact solver to solver joint, but this is at the Spence of calling more joint solver.
It does no make much difference, so I di no committed, but this is past of the parallelization, I was just curios.

In any case this baby is not an easy thing to do I am surprised it even work without doing anything special. The old demo has lot of tweaks that I removed for this one.
when it is all running I will compare it to the old demo and to see where the tweak apply

[Julio Jerez]

Ok now now teh tank can drive forward and backward and I also tightened the threads. not steering yet.
It jitters more and I think is going to be a good challenge to figure out how to eliminate that jitter.
But we leave that for later.

I also commited part of the optimization I mentioned before, but without the contact joint is parallel, and is marginally faster.
is hard to say because me system is faster that your and optimization gain become very small.

but to see the real effect I run in debug mode.
in debug mode with the optimization and with the W key down on so that all joint execute the max number of iteration I get 70 ms.
without the optimizations same condition, I get 90 ms.

you can try this by commnetion out the #if 0 in file:
..\sdk\dgPhysics\dgWorldDynamicsSimpleSolver.cpp line 1200

if you sync yp cna try in debug, but you sopuld see some aprecialble diffrence in relase as well.
I do see some but I my values in MS are in the margine of error in release mode.

anyway I will leave the optimization more enable until I get sign that it nee to be a run time option instead of a compile time option.

one thsi that we can do now is apply stronger torque so that is more powerful
and set bigger top speed so that and runs faster but I will leave that for the tuning phase.
now to the servo joints.

[Julio Jerez]

ok now I added another optimization which is added the compound collision filter.

this allow for rejection shape parte before the contact are calculated, before It has to let the compound aabb pass the overlap test and the in the onContact delete all the unwanted contacts.

now the overlap test let teh compoudn pass, and teh teh compound shec for each shape/shape pait of it need to calcylate contact ort not.
In fact system this is no a big deal, but in slower system is does make a diffrences.

ok now on to the steering, functionality

edit:
I also added a island of terrain objects. The tank drives over them without any problems, however this doe no come for free, is a wood slab get into the track and the tire, there are huge forces that try to keep the thre4ad in place. and the vehicle pops.

That the price of a stronger solver, it will no deal will with too unreality situations.
Remember in real like huge pieces of wood do not get needed into the tracks of a bulldozer of a tank, but even if they did, the track most likely crush the wood, this will be more like a piece of steel getting into the tracks in which case then the tracks would brake.

what I am going to do is debug opinion that the wood do not collide with the Treads, of with the tires
whis even look better the the crushing thing can be avodied.

[JoeJ]

Tried again, but no noticabale performance difference. Hard to tell as timings fluctuate +- 0.5 ms.

[Julio Jerez]

Yes that's what I said before, in there is some gain but not enough to see in release mode.
I see about 10 % in debug and almost nothing in release, but the profiler say is better.

This is not important now, I just remember that that was something I had pending.
Once this is all done, all the will Ron in multiple thread even in single islands.

[Julio Jerez]

I now made a demo of the differential gear joint that I was in the vehicles for controlling turning.
when you sync see if you can understand it.

[Julio Jerez]

Ok I am now using that joint in teh vehicle, the problem was that I was using the worn axis, before the pin of the joint was the front vector of teh matrix because the traction tire was a hinge but now is the sliding contact so the rotation is around the secund axis. This was making the tank sway in weird ways.

now teh last thing is to the the engine also a joint instead of applying a direct torque to the carcass.the sterring is already controll by a motor.

in the end the entire vehicle souel be a self conteaied object with no mistrios force of torque come for teh thin air, other that the gravity, Everything should be modeled with a joint.

[Julio Jerez]

I could not do much last weekend, had to work.
But I get to redo the slider and the hinge servo joints and I added the boom crane to the vehicle.

The one thing I noticed is how remarkable stable it is. So much that you wich it was not so much, it goes to sleep in one frame, so the script has to take control of sleeping.
When I add the thread it does not go to sleep, but that is in fact a good thing. I compared to the 3.13 demo and I saw that the reason 3.13 goes to sleep was that the joints stiffness are more relaxed.
Now they are all at much higher tolerance, so it is the end user responsibility to set them to some lower value.
When the last part is completed, I will probably add an option to set the stiffness to some smaller value so that the whole system find a minimal faster.

I also did two things.
1 committed without the thread for debugging,
2 separated it into two demos, the track and the forklift.

The reason is that the track is too complex and adding two demos in one file does not help the user.
Therefore the forklift is a simple slow moving vehicle that shows how useful the servo joint are, and how stable the system is, and the track demo is just a show off demo.

I now has to redo the next two servo joints: the two axis servo and the wheel joint. And with that we are finish with the standard joints.

[Julio Jerez]

Hey Joe I renamed this topic because is was not about what It was intended.

I now completed all the servos joints, and I committed the tracked vehicle without the thread for a while.
I's like you to sync when you have time and see what performance you get.
I get 0.6 ms at home and 0.7 ms at work.

The reason I want to know is because this is about the as complex as a vehicle can get.
Like I said the tread stuff is for showing off, and I will add that later, by this can serve as a metric for how much it will cost to simulate a complex vehicles.

[JoeJ]

I get between 1.3 and 1.5 ms (debug 10-12 ms)

[Julio Jerez]

Ha ok, thanks.

It is high, and it does not seem as if there is much more we can do about with a single core.
the only consolation is multicores.


from shi point on, I am not going to worry more about single thread performce, we knwo that the only way that can be acchived is by degrading the quality of the solution.
I will focus instead on making multicores more efficient.

I do not think there is a single mothern PC or game console that has at least two full cores or that can run many threads.

anyway I will complete the forklift which is more representative of what a vehicle can be.
I mean 4 wheels plus some joints to control the moving part and the engine. The track vehicle has 43 joints not counting the threads, with the threads is 139, so that's a big difference.

I now start the inverse dynamics joints, and I am following your advice to make the a dCustom joint

[JoeJ]

I often read racing games use very short timesteps, about 300Hz. So the performance looks pretty good to me.