Porting from 3.xx to 4.00 - need help

[misho]

Hi!

I was wondering if there is some kind of a guide to migrating from Newton 3.xx to Newton 4.00? I looked at the Wiki but not a whole lot has changed in a while. I finally have some spare cycles to start implementing my SpaceFlight module (referenced in this post) to 4.00 to add some new exciting functionality.

Can someone here (Julio?) help me and give me guidance as to what needs to be changed as I go down my list of LNK2001 errors? My code is based on the 3.14 DemoSandbox structure (Entity, SceneManager, etc.)

[Julio Jerez]

The major difference is that 4.00 is now full cpp.

Also object are not own by the world by design.
Now object are shared pointers, not the last reference is the one destroying the object.

For reasonable trained cpp programmers 4.xx should be easier than 3.xx

There are also a set of streamaly simply unit tests that you can check to get start.

[misho]

Thanks Julio!

Ok, first easiest thing I am doing is converting to new types. So far:

dVector to ndVector, dVector.DotProduct3() to ndVector.DotProduct()
dList to ndList
dFloat to ndFloat32
dListNode to ndNode
dMatrix to ndMatrix, dMatrix.SanityCheck() is gone?
dQuaternion to ndQuaternion
NewtonWorld to ndWorld

Looks correct?

[Julio Jerez]

Yes that looks correct.
I suggest you go with the mind set that is a different library.

Is true the 3.00 and 4.00 are very similar, but there is a big difference between write an interface in c and cpp

Pretty soon you will find that the divergence is enough that there will be thing in 4 that do not exist in 3.
It is not a simple search and replace.

You can keep your old version and just add a new layer using 4.

[misho]

Thanks Julio! Yes, I am tackling easy stuff first so that at least it doesn't show as "red" an all of my files, and is out of the way. Of course, architecture stuff will be a bit more involved.

Architecturally, my spaceflight module is very simple - there are no complicated hierarchies, assemblies or other things that Newton is capable of. It is basically a collection of Newton bodies, linked by simple "hard" joints, and in some cases, hinges, ball and joint, motorized, and a few other ones. The structure is similar to DemoSandBox 3.14, where I have a "TBEntity":

Code: Select all

class TBEntity : public dHierarchy<TBEntity>, virtual public dClassInfo

which contains NewtonBody object (I think this slightly differs from DemoSandBox, where it is the other way round, NewtonBody contained DemoEntity through userdata member), and a LOT of other members needed to represent a part of a spacecraft (properties like propulsion, aerodynamics, etc.). I use these properties to calculate forces on the body and apply them - that is pretty much it.

These "TBEntity" objects are then organized in the TBEntityManager container:

Code: Select all

class TBEntityManager : public ndList <TBEntity*>

which contains ndWorld* m_world; member, and where I also have member functions for operations on the TBEntities list, like adding, deleting, swapping order, etc, plus, a lot of Newton option switches (like Solver Passes, Solver Substeps, etc.). This is also basically closely modelled after the way things were organized in DemoSandBox 3.14.

I know the structure has changed from 3.14 to 4.00, and I will go through the demo projects to see how they are organized, but I am hoping that my setup is fairly straightforward and I won't have to drastically restructure everything.

Any pointers or advice based on what I described above would be very welcome!

[Julio Jerez]

when you go over the demos, check out the new class called the ndModel.

it is a container where you can group bodies, jointer, collisions, joints, plus your one stuff.
these containers offer few methods, from the engine pipeline, that you can use to control your model.
you get update before, collision after Collison and before physic, and after physics.

you can make your rockets and space craft using these ndModels, and the app see then as a single entity, rather that a collection of individual joints and bodies.
ndModel is new to newton 4,

I am making a library of complex models, name ndModel that will have some examples, at the moment there only one is the ragdoll and vehicle.

[misho]

Aha! Interesting! I have something similar, class called "Assembly". Basically, a container for one or more bodies, so let's say a spacecraft would be an "Assembly" of 2 rigidly attached bodies (Crew capsule and a propulsion module) and a space station would be another "Assembly" of a number of rigidly attached bodies. I'll definitely check it out.

[Julio Jerez]

Ah yes, the is alone the line of the kind of grouping most apps would do at a higher level.
What the ndModel class offers is the hook points in the pipeline update.

In previous newton that could only be before and after updates. At these stages the contact are either not available or already used.
Now with the ndModel the app can apply the controls when all contacts are available.

So you can group make your model have a ndModel. And do the update where is appropriate.

[misho]

Yeah, I would LOVE to "dump" my "Assemblies" and move them to ndModel.

I am not sure if this has been mentioned or debated before (please forgive me if it was) but the more I think about this, the more I am leaning towards taking the complete DemoSandBox project "as-is", and creating a layer that basically adds functionalities that suit my needs. I think we talked about this before - the one thing that made it hard in 3.14 was how the DemoSandBox was intricately created and interwoven with the graphics engine (which it obviously needs, since it is a DEMO application).

But I was wondering if any effort has been made (or, is the effort worth it) to separate the two, and create DemoSandBox architecture that will create the physics world with all the interfaces to define and add/remove bodies in all of their variations, properties, linkages, etc., and all this WITHOUT the graphics layer, which would be a separate module. This basic module would then just "do its thing" and run the physics world without any graphics. The user would then hook in the graphics layer of their choice, in my case, Flight Simulator, and in Newton's case, glfw.

That is basically what I had to do with my project - remove a LOT of graphics layer stuff that was embedded throughout the DemoSandBox - all the mesh building stuff, graphics render calls, etc. All I needed was Newton world defined and running, and reading the Newton Body position/attitude and applying it to Flight Simulator visual objects. I think that kind of a high-level architecture would make Newton a lot more palatable to many developers, as the Newton learning curve is quite steep (as mentioned in one of the forum posts)

[Julio Jerez]

But I was wondering if any effort has been made (or, is the effort worth it) to separate the two, and create DemoSandBox architecture that will create the physics world with all the interfaces to define and add/remove bodies in all of their variations, properties, linkages, etc., and all this WITHOUT the graphics layer, which would be a separate module. This basic module would then just "do its thing" and run the physics world without any graphics. The user would then hook in the graphics layer of their choice, in my case, Flight Simulator, and in Newton's case, glfw.

You are not the first to point that out.
The answer is yes, that is the ndModel library.

I extract a significant part of the sandbox demos, and move to that lib..
There it use ndMesh instead of demo entity and ndDemoMesh.
But exclude the graphics and physics from both.

I am converting all the demos from the sandbox to have a core support in ndModel.
The the graphics is a thing layer than just do the translation and graphic part.

The ndModel will also have file save/load for stuff like debug, and asset sharing.

But this is a tedious and labor intensive process.

My guess is that when you get enough conversion, you can start using ndModel to make your models, and I can give you some pointers.

[misho]

Hi Julio,

Thanks, yes, I am slowly getting familiarized with the new structure and I quite like it! Much more C++ indeed. I think I will be able to directly link to DemoSandBox source for all the Entity manager processing, without creating my own custom version. I was just testing some stuff and I was glad to see that not setting mesh on the body:

Code: Select all

// entity->SetMesh(geometry);

works just fine. I think 3.xx would not allow that and I had to remove all kinds of mesh members.

Other question I have is, I tried looking through demos, and I can't locate any samples that illustrate joining of 2 bodies using a "hard" joint. Are there any examples, or if not, could you add it to the BasicJoints demo?

[Julio Jerez]

Hi Julio,
Other question I have is, I tried looking through demos, and I can't locate any samples that illustrate joining of 2 bodies using a "hard" joint. Are there any examples, or if not, could you add it to the BasicJoints demo?

newton 4, is not just translations to cpp, there are some initial conditions changes.

-stuff like Body having a linear and angular drag by default, now drag is zero.
-gyro integration was optional by flag, now only by setting an spherical inertia.
-solvers are better, therefore all joints are set to use direct solvers by default, the app can set to be soft but calling virtual void SetSolverModel(ndJointBilateralSolverModel model);
after creation.
so all joints are strong by default.
-there are few other things that I do not remember now.

you can check the demos:
../newton-4.00\tests\bilateralJoints_test.cpp
..\newton-4.00\applications\ndSandbox\demos\ndBasicJoints.cpp

[misho]

Ok - the joint I was looking for is

Code: Select all

ndJointFix6dof

.

So, in ndBasicRigidBody.cpp, I added another box on top of the main body, and connected the two with ndJointFix6dof, as such:

Code: Select all

        origin.m_posit.m_y += 8.f;
        auto pMainBody2 = AddBox(scene, origin, 1500000.0, 4.0, 8.0, 8.0);
        ndJointFix6dof* const joint = new ndJointFix6dof(pMainBody, pMainBody2, pMainBody->GetMatrix().m_posit, pMainBody2->GetMatrix().m_posit );
        ndSharedPtr<ndJointBilateralConstraint> jointPtr(joint);
        ndWorld* myworld = scene->GetWorld();
        myworld->AddJoint(jointPtr);

And I got what I wanted - two boxes rigidly connected to each other. One thing I don't understand is, if I position pMainBody2 a bit higher, using, let's say, origin.m_posit.m_y += 20.f;, so, a bit further above the pMainBody, it always places the pMainBody2 right on top of the pMainBody. I would expect it to be suspended above the pMainBody, rigidly connected.

[Julio Jerez]

ah that's one of the cool features of some joints.
ndJointFix6dof ha tow constructors.

Code: Select all

ndJointFix6dof(const ndMatrix& frameInGlobalSpace, ndBodyKinematic* const body0, ndBodyKinematic* const body1);


frameInGlobalSpace is common to the two bodies, so the initial error is zero.

in some cases, you have two objects that aren't position exactly as you want, but you know want point on each body you want to be common. that where the secund constructors is useful.

Code: Select all

ndJointFix6dof(ndBodyKinematic* const body0, ndBodyKinematic* const body1, const ndMatrix& globalMatrixBody0, const ndMatrix& globalMatrixBody1 );

here
globalMatrixBody0 is a pint fix on body0.
globalMatrixBody1 is a pint fix on body1.

them the solver uses the penalty part to drive the error between the two, to zero over time.
this is good for correction small errors when initializing a scene.

edit:
also make sure you pass the proper parameters initialization.
in your test case, you came across to one of the short coming of c++.
this is in C++ is possible to make object type by up and down casting, and some time that can cause.
unintended consequences that are hard to debug.
this is one for the reason I do not like to add too many constructors to classes,
but that rule is hard to enforce.

you are creation the the joint like this:

Code: Select all

ndJointFix6dof* const joint = new ndJointFix6dof(pMainBody, pMainBody2, pMainBody->GetMatrix().m_posit, pMainBody2->GetMatrix().m_posit


the reason that works is because there is a constructor of a matrix that build a matrix using grand smith normalization. which should nt exist.

by you probably want to make

Code: Select all

ndMatrix matrix0 (pMainBody->GetMatrix())
ndMatrix matrix1 pMainBody2->GetMatrix())
matrix0.m_post.m_y += 1 (some value
matrix1.m_post.m_y -= 1 (some value

ndJointFix6dof* const joint = new ndJointFix6dof(pMainBody, pMainBody2, matrix0, matrix1)

sometime later I will convert that GrandSmith into a function since that has happen few times.

[misho]

Oh that is perfect to have that option! My rockets were always showing a bit of a gap at the joints between parts, and I was always sure that the geometry and position was correct! This may fix this problem!

Ok, so isn't the frameInGlobalSpace just an identity matrix?

I adjusted my code to this:

Code: Select all

        origin.m_posit.m_y += 20.f;
        auto pMainBody2 = AddBox(scene, origin, 1500000.0, 4.0, 8.0, 8.0);
        ndJointFix6dof* const joint = new ndJointFix6dof(ndGetIdentityMatrix(), pMainBody, pMainBody2);

But the 2nd box still gets attached to the first without the gap...