Newton 4.00

[zak]

My game is on 3.14 (visual studio 2015). Now I would like to evaluate 4.00.
I have two questions:
1) Does 4.00 already have all the features of 3.14 or is there still something missing?
2) With 3.14 I had to indicate only an additional inclusion directory, while with 4.00 it seems to me that I have to add several additional directories
Newton-4.00 \ sdk \ dNewton;
Newton-4.00 \ sdk \ dNewton \ dModels;
Newton-4.00 \ sdk \ dNewton \ dJoints;
Newton-4.00 \ sdk \ dCore;
Newton-4.00 \ sdk \ dCollision;
Is it right?
If so it is somewhat inconvenient or is it possible to enter just one additional directory which also includes subdirectories with something like
Newton-4.00 \ sdk \ * ?

[Julio Jerez]

the easier way to use the engine is to run teh cmake wit teh default setting,
you cam make single dll or sing static library.

teh afte that you can run install and thsi will create a folder: ../newton-4.00\win64sdk

wit three sun directories: bin, include, lib

the in your project you just at the path like
..\newton-4.00\win64sdk\include

and for linking
..\newton-4.00\win64sdk\lib

the in you source code you just add

// SDK includes
#include <ndNewton.h>

and that should be all you need.


for teh secudn question, no not all teh feature has been implemented, yet. This time I am going for teh feature that were really used. they is ton of stuff in newton 3.xx that when largely ignored, fore whatever reason. so this time I am going for the thing that is actually use by people.
stuff like: rigid bodies, players, triggers, particles, vehicles.
after we get that them we think of the more specialized features.

[Enclave]

I try to switch in my project from 3.14 to 4.0 and it is not very easy, as it turned out. Many of the functions that were used have different names, others are simply absent.
I need: create a world, create a player, create dynamic objects. In version 3 there was a lot of c-api interface, here it is almost absent.

For example, I used such functions.
NewtonCreateTreeCollision
NewtonTreeCollisionAddFace

There are also many other things.
It is not clear how it all works now.

[Dave Gravel]

Here for the TreeCollision I use something like this.

Code: Select all

  int idccount = 0;
  dVector faces[3];
  dPolygonSoupBuilder meshBuilder;
  meshBuilder.Begin();
  for (int i = 0; i < aMeshCount; i++) {
    for (int u = 0; u < (aAssimpMeshes[i].aIndiceCount / 3); u++) {
      //
      faces[0] = dVector(aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 0]].posit.x,
      aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 0]].posit.y,
      aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 0]].posit.z, 1.0f);
      //
      faces[1] = dVector(aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 1]].posit.x,
      aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 1]].posit.y,
      aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 1]].posit.z, 1.0f);
     //
     faces[2] = dVector(aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 2]].posit.x,
     aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 2]].posit.y,
     aAssimpMeshes[i].aMVtx[aAssimpMeshes[i].aMIndices[u * 3 + 2]].posit.z, 1.0f);

     meshBuilder.AddFace(&faces[0].m_x, sizeof(dVector), 3, idccount);

     idccount++;
    }
  }
//
meshBuilder.End(false);


In the sdk you can find a exemple in file ndMakeStaticMap.cpp
At line 88
ndBodyKinematic* BuildStaticMesh(ndDemoEntityManager* const scene, const char* const meshName, bool optimized)

[Julio Jerez]

Many of the functions that were used have different names, others are simply absent.
I need: create a world, create a player, create dynamic objects. In version 3 there was a lot of c-api interface, here it is almost absent.

yes that is correct, 4.0 has a c++ interface.
3.xx was a mix of c and c++ and that made complicated to used.
in the pass c interface made sense because engines only deal with collision and bodies and few joints, but as engine get more complex the c interface made much difficult to implement objected oriented functionality using a procedural language like C. the result was a mix that got more and more difficult to use.

It may seem difficult at first, but is is not is just different.
take for example the player capsule demo in 4.0 file:
../newton-4.00\applications\ndSandbox\demos\ndPlayerCapsule.cpp

it is just a few dozen lines of code and that include the background.
and is much better that 3.14 just take a look,
if you are fluent with C++ is should be easy to follow.

[zak]

Ok, I started my journey in Newton 4.
I have a first question. Why, when I create a DynamicBody, if I don't call ndBodyDynamic.SetCollisionShape() then ndBodyNotify.OnApllyExternalForces () and ndBodyNotify.OnTrasform() are not called?

[Julio Jerez]

because a bodies with null shape does not get update.
the body still has null shape. but that shape is just for having all algorithms running without having to check if the shape is null not.

[zak]

What is the equivalent of 3.14 SceneCollision in Newton 4?
I think it could be a kinematic body but how to assign more than one shape to it?

[Julio Jerez]

I have not added the compound collision yet.
I can't do it this weekend, but since you are the secund person asking for it I will added this next week.

[zak]

I have not added the compound collision yet.
I can't do it this weekend, but since you are the secund person asking for it I will added this next week

perfect

In Newton 3.14 i can call NewtonMaterialGetContactPositionAndNormal() to obtain the normal of the contact point. In the function i have to indicate the body, so i obtain a normal referred to body0 or a different normal referred to body1. In Newton 4 i can obtain the normal in ndContactPoint.m_normal, but there are no normal0 and normal1, but a single m_normal vector. How should it be intended? Is it always the normal referred to body0? And in this case, to obtain the normal referred to body1, do I have to negate m_normal?

[Julio Jerez]

Yes, that is exactly what 3.14 does.

[zak]

Yes, that is exactly what 3.14 does.

Ok, thank you.

In Newton 3.14 i can call NewtonMaterialSetDefaultCollidable(world, id0, id1,state) to disable collisions between two specific materials, leaving collisions with other materials on. In Newton 4 i think this can be achieved by setting off the ndContactOptions :: mCollisionEnable flag in ndMaterial. I did this but the engine seems to ignore the flag.

[Julio Jerez]

ah yes, that one of teh major difference between 3.xx and 4.00
in 3.xx the material id was part of the rigid body, but as time passes that's become difficult to handle for bodies with more than one material, ex terrains, compound collision, or even for app that do specil contact handling.

for 4.xx wit moved teh controll to teh application, now the collsion shapes has ther material id,
and teh app register an callback with the world

for example

inline void ndWorld::SetContactNotify(ndContactNotify* const notify)
the app can subclass for top deal with the collision as if desire to do.

you cna fond an example of a contact call back in file

../newton-4.00\applications\ndSandbox\ndContactCallback.h and ndContactCallback.cpp

and a typical example will be in demo
../newton-4.00\applications\ndSandbox\demos\ndBasicFrictionRamp.cpp

this way we not longer have a one fix all mode of handling contact material.

[zak]

Ok, i have implemented my own code in ndContactNotify::OnAaabbOverlap() (ah, too many "a" in the function name). When for my app logic a collision does not have to happen it returns false.

this way we not longer have a one fix all mode of handling contact material

Yes, but i think if the engine implements ndContactOptions :: mCollisionEnable doesn't break this logic. Application code in ndContactNotify::GetMaterial() decides if collision is not active, if so deactivates mCollisionEnable in ndMaterial or a material previously recorded with the flag disabled is simply returned.

[Julio Jerez]

ndContactNotify::OnAaabbOverlap yes fixed,

with the exception of the collsion disable flat of a shape.
there are not options that can be set on initialization anymore. at least this is the idea.
the may change with gpu opencl if we implement gpu contact joint calculation,
but I am still far from that and is we have to do it it will be and option.