Starting with vehicles in 3.14

[JoshKlint]

I'm just trying to get some wheels to support the weight of a box. Can you see anything obviously wrong with the tireinfo settings here?

Untitled.jpg (47.45 KiB) Viewed 8225 times

[JoshKlint]

The chassis just falls to the ground and the tires stay stationary. I am getting feedback from the physics engine that says this is where the tires should be....

[JoshKlint]

Steering actually works fine. But my tires are hanging in the air, and the chassis seems to be unaffected by the vehicle.

[JoshKlint]

This is my creation code. It seems simple enough:

Code: Select all

   bool PhysicsVehicle::Finalize()
   {
      xMat4 localframe;
      xMat4 tiremat;
      delete newtonvehicle;
      tires.clear();

      float mass, ixx, iyy, izz;
      Assert(chassis->newtonbody);
      NewtonBodyGetMass(chassis->newtonbody, &mass, &ixx, &iyy, &izz);
      Assert(mass > 0.0f);
      
      newtonvehicle = new dMultiBodyVehicle(chassis->newtonbody, &localframe.i.x, Abs(chassis->world->gravity.y));
      newtonvehicle->SetUserData(this);

      for (int n = 0; n < tireinfo.size(); ++n)
      {
         Assert(tireinfo[n].m_mass > 0.0f);
         tiremat.t.x = tirepositions[n].x;
         tiremat.t.y = tirepositions[n].y;
         tiremat.t.z = tirepositions[n].z;
         tires.push_back(newtonvehicle->AddTire(&tiremat[0][0], tireinfo[n]));
      }

      dMultiBodyVehicleDifferential* differential = NULL;
      for (const auto& axle : axles)
      {
         differential = newtonvehicle->AddDifferential(1, 1, tires[axle.x], tires[axle.y]);
      }

      //dEngineInfo engineinfo = {};
      //engineinfo.m_topSpeedInMetersPerSeconds = 1000;
      //newtonvehicle->AddEngine(engineinfo, differential);

      newtonvehicle->Finalize();
      return true;
   }

[JoshKlint]

Oh, this is an old problem...

[Julio Jerez]

why don't you move to newton 4?
it is far easier than 3.14, has more features and it is the current active version

Dave just made this vehicle demo.
https://www.youtube.com/watch?v=QcmXDu4iIw4

he can give you some pointers. I myself will use his setting to place on the demo.

[JoshKlint]

I downloaded Newton 4, compiled it, and ran the demo sandbox and it just crashes on startup:

Code: Select all

#ifdef _DEBUG
void ndDemoEntityManager::OpenMessageCallback(GLenum source,
   GLenum type,
   GLuint id,
   GLenum severity,
   GLsizei length,
   const GLchar* message,
   const void* userParam)
{
   if (userParam)
   {
      switch(id)
      {
         case 131185:  // nvidia driver report will use VIDEO memory as the source for buffer object operations
            return;
      }
      ndTrace(("GL CALLBACK: %s source = 0x%x, type = 0x%x, id = %d, severity = 0x%x, message = %s, length = %d \n",
         (type == GL_DEBUG_TYPE_ERROR ? "** GL ERROR **" : ""), source, type, id, severity, message, length));
      ndAssert(0);
   }
}
#endif

[JoshKlint]

0x0000024a7b64ede0 "SHADER_ID_LINK error has been generated. GLSL link failed for program 22, \"\": The \x4 shader uses varying position, but previous shader does not write to it.\nOut of resource error.\n"

I think it is caused by this shader:
CreateShaderEffect("DirectionalDiffuse", "DirectionalDiffuseNoTexture");

[Julio Jerez]

the app chashes in 32 bit in debug mode,
I believe this is a bug in glatter that I have never been able to fix.
the Chash happen in different places, and I guess the only way for me
to get rid of is to find another open source GL function loader.
I am sure is something I am doing wrong, but I do not know what it is.

you can try release, or prelawsuit debug
you can build the 64 bit, that works in all config modes.

[JoshKlint]

Is there something else I need to install for the GPU solver to work? The stress test demos seem very slow and my GPU doesn't seem to be used.

[Julio Jerez]

The gpu solver use cuda.
But it is incomplete because it his an un resolvable block.
Cuda has a feature call dynamic parallim. That alow a kernel call some other kernel.
On panel this is really good, because make possible to use libraries.

The problem is that, they ke so that the hole app has to be a cuda project so that thei ke can link project,
I even try to see if it work on dlls, but was just a waster of month of frustration.

Newton is not a coda app, so I can not make a cuda solution.
I took it to the nvidia forum and never have an answer.

I even try to just doing launching single kernel, but realize is tge same bs, as it was on the beginning.
I know I am on the minority, lot of people love that kind of low level control, but not me.

If I eve resume the gpu code it will be what when it can be used from standard cpp.
Sycl seem a good solution, but intlell too make you make an intel app.

So the gpu seem bleak.
I can't believe that in more that 20 years of gpu, and all the self appointed experts on making standard
They so a way to write generic gpu cross platform gpu code.
You would expect that gpu programing would be part of the cpp standard by now.

[JoshKlint]

Okay, that's no problem. I'm sure the CPU solver is still much faster than Newton 3.

[JoshKlint]

I was also running in debug mode. The performance is really nice.

Have you done any tests of Newton 4 vs 3 performance? Can you quantify the performance improvement as a percentage?

[JoshKlint]

In DirectionalDiffuseNoTexture.ps change this at line 14:

Code: Select all

varying vec3 posit;

To this:

Code: Select all

varying vec3 posit;
vec3 position = posit;

And that will fix the shader linking error.

[Julio Jerez]

ah yes that shader was a 120 legacy, it is fixed now. thanks.
I have not put much emphasis of the render quality, just enough to render.

on the performance, all I can say is that I did all that I can to make 4.xx scale lineally with the hardware. That sound like some this easy but is quite hard.
there is this Amdahl's law
https://en.wikipedia.org/wiki/Amdahl%27s_law

that when writing parallel system, you would think you do not have to worry about.
you just paralyze the mush time consuming art that that will be it.
That is true as long as you have a very small cores count.
the moment the core count is increased, there the part that are not parallel become the bottleneck of the application.
and you would think that this does not apply to a parallel loop, but you would be very wrong

a parallel loop like

Code: Select all

atomin int i
for *i = 0; i < count; i.amoticAdd(1))
{
 // do some work in paraller
}

will suffer form that law and you get many cores, because you can see that as a multilane highway,
but with a tollbooth that only allow one vehicle at a time. and you se hwo that works.
Newton 3.14 and previews suffer significantly from that.
newton 4.0 does not,but was not easy.

In some cases you actually have to settle for a less optimal algorithm, but that can be parallelizable,
in order to get upscaling with multiple cores and that's what makes it really hard.
because in many case the paraller version may have so moch more cores that maye be a next lost.

fortunately, after lot of tweaking and reviewing, you find way to make the parallel version just as effecenets and even better.

the biggest example is that Newton 4 does no build island anymore.
The algorism for making island is elegant and fast, but cannot be parallelized, and easy atent to do so, result in slower performance.

but the problem with island is that, they are very uneven, so the rest of the code, does more work that is really should do.
on the ethe side not having island you have to update every thong every time.

but what if you can come up with and algorithm that, just consider a local island.

for example if a body become active, it does not have to active there entire island, it only has to active it neighbored. then when the neighbored become active, he active its neighbor and so on.

this algorithm takes more work, but is incremental and realizable. so now when a body goes to sleep, it just do so. them you realize that the extra cost you lose, you gain with interest because you no longer need to build island.

don that kind of rework, make almost the engine engine lock free, and atomic free. and for ethe firt time you can see that the ASVX2 is actually faster than the sse.

A friend recently test the engine with a 64 cores tread thread ripper, and the engine scale scale linearly to 64 threads. He did 29000 bodies all pile up at over 30 fps.
but at the level, you become limited by the poor graphics.

anyway, the answers is newton for is designment to be parallel, but I have not made any direct comparison, and the reason I do not do it because once, I made the decision, they is not turning back.
I thrust the newer method should be better than the older.