Height Field Collision Issue

[Esharc]

Good morning,

We use the height field collision primitive on what we call a quad terrain which is a NewtonCreateSceneCollision. The terrain has no "floor" collision primitive and it is the work of the height field primitive underneath the vehicle to do the collision detection. The only collision primitives added to the scene would be buildings, bridges, trees, etc.

The height field primitive moves with the vehicle as it moves along the terrain, updated it's position and height data read in from the terrain visual model. The problem that I have been experiencing is that the AI vehicles that we place in the world seem to get bumps, causing them to flip over. I have included a link to a video that I hope will demonstrate the issue that I am experiencing.

The AI vehicle is just a convex shape without any wheels to keep it as simple as possible so that little resources are used for them. Is it possible to move the height field around as we are doing, or is the intention with Newton 3.14 to keep the height field static and we should create the height field once to cover the whole terrain in the scene? Would that be worse for performance?

Link to the video:
https://youtu.be/AtrR2fbFSwQ

Thanking you in advance
Etienne

[Julio Jerez]

I did a lot of work in both those edge collision an also a far, far better vehicle model for 4.00

The code share the same root as 3.14 but it has lot of improvement that make it too hard to convert back to 3.14

Look at the video in you tube of the vehicles so that you can see the differences.

How hard would be for you to move to 4.00 rather than try to fix that bad edge bug in 3.14

It is not a trivial thing, to fix since it require lot of factors to consider.

[Esharc]

Hi Julio,

I am not sure what differences there are between the two version, but I will attempt the upgrade today and see what effort it will entail.

I will get back to you as soon as I can.

[Esharc]

Hi Julio,

The change from 3.14 to 4.0 is a big change. This is going to take me quite some time and effort to get it done.

I will continue with the update and get back to you if I have any issues or if there are features from 3.14 that we are using that is missing in 4.0

[Julio Jerez]

All funtionality of 3.14 is already in 4.00

There may be more custom joints in 3.14
But those where specific request, tha those user
Are not using anymore.

The migration should not be that hard, in fact 4.00 is fa simpler to used than all other versions.
It should be not more than a day or two.

[Esharc]

Hi Julio,

So what I am attempting now is to keep Newton 3.14 in our code whilst I upgrage to 4 so that we can switch easily between the 2 until I have all the functionality in and we can make the switch permanent.

But I have a issue where you are using the same files for some classes in 4.0 as in 3.14 so the wrong ones get included. Will it be possible for you to add namespaces to your classes so that this is not a problem as well as simplifying the additional includes to only include the sdk folder?

I could do this on my side, but then I would have to edit the includes for all the files each time I want to update Newton to the latest revision.

[Julio Jerez]

oh yes keep a 3.14 and 4.0 is a good idea for a project.
and yes some the files name are a problem if the have the same name..

for that when I start I copies all the files from the core of 3.14 and they are the core of 4.00
but now they have changed, but even if they did not it is still a problem, I realized that when I start writing the collision module, so I am using the nd Prefix for each class, but it never ocured to me to rename the file and classes in the dCore folder.

tonight I will rename them all to nd instead of d for example
dVector.h will become ndVector.h
that step one which is easy, and will let you compile and link all files.
them in secund pass I will rename the classes so that the si no confusion.

on the one header include, that is easy wit a c api, because in cpp is very hard wit the circular dependency of CPP plues for development find it better to have one header per cpp fiel as must as I can.

however there is a file ndNewton.h
that include all the files in the correct older. you onel nee to set the file path.

if you use CMake and you are linking the source in you project, the path will be set by cmake.
but if you use cMake to build the engine, if you run install, the visual studio will run a script that will copy the files to an installation folder. the install folder default name is win64sdk or win32sdk
but you can change to what ever you want.

I will copy all the binaries, the lib, dll, header and pdb files, so you will be able to step in debug into the source.

I hope this answer your questions.

BTW that video seem like a cool nice project you are putting together there. If you are using the vehicle model I can wait to see how it behave, the new vehicle model is much, much nicer.

but even if you do not use the vehicle model, There is a new concept in Newton 4.00 we call ndModel.

this scan be use to encapsulate collection of collision and bodies and joint that the application can apply operation on them taht make quite difficult using Joint Call back or collision before and after the physics update.

the Model have callback in between the collision and the solver phase where the application can do modification to the contacts and the joint base on any criterial is want.

I can change contact, and activate of deactive joints, and is can operate on all the part that make the models, and this is what make so powful.

[Julio Jerez]

ok now all file has the same nd prefix.
this make every file to have a unique name. so there should be not conflicts using 3.14 and 4.00 together.

at some point I will rename the classes. since this may have conflicts at least this should compile.

[Esharc]

Thank you Julio.

I will update the version that I have to the latest and continue.

Yes the project is cool, we make driving simulators for people around the world that include transportation trucks on the road, mining trucks and construction vehicles.

I have been monitoring your vehicle model for quite some time and have been thinking about how to use it in our system, but unfortunately the way that we have it setup, the vehicle model will not work. The ndModel that you speak of does sound interesting and I will take a closer look at it once I have 4.0 up and running.

[Julio Jerez]

Yes, understand.

One of the main focus of 4.00 is to provide that new ndModel, specifically for physics modeling.

This was hard in older version, and this is why thinkg like vehicle amd in general articulated bodies where complex.

Now with the ND Model it made a lot simpler.

One of the venefit right out of the bat is that from the application point of view, articulated object look like the same object. It also provide serialization this could be handy for debugging.

On the vehicle the new model, has some very big differences with previous version, one major one is tha it does not uses a pre solver pass, everything is set up for the general solver. So the interation with the rest of the world is seamless. It is also much more realistic, using realistic drive train with motor, differential. Gear box, clutch, and even torque converter. These are not just added for not reason, they are added as a nessesity of the simulation.
And lastly it use a pure brush tire model. This allow for emerging behavios like drift and sideways slide when breaking and accelerating.

You can give it a try, since it is a stoke model. You do not lose much, plus you can customize it with you domain knowledge that I am sure your team ha accumulated over time.

[Esharc]

Hi Julio,

I see that the impulse force and impulse torque members of the dynamic body cannot be set (unless I am missing it somewhere). Will you be able to add functions so that I can set them please or is there another way to set an impulse force and an impulse torque for a body?

[Julio Jerez]

done. thanks

[Esharc]

Hi Julio,

Thank you so far for the quick responses. I have been hard at work integrating the new version into our system.

I have had to change the name of the class dList to ndList to fix dual support issues with Newton 3.14 and 4. Will you be able to make that change on your side as well please.

Also we have a custom rope joint that uses the NewtonUserJointAddGeneralRow function from Newton 3.14, but I see that it is not in 4. Will you be able to add a AddGeneralRowJacobian function to the joints please.

[Julio Jerez]

I have had to change the name of the class dList to ndList to fix dual support issues with Newton 3.14 and 4. Will you be able to make that change on your side as well please.

yes I though this will be a problem, I renamed the files but not the classes.
I will try to do it little by little starting this weekend.

Also we have a custom rope joint that uses the NewtonUserJointAddGeneralRow function from Newton 3.14, but I see that it is not in 4. Will you be able to add a AddGeneralRowJacobian function to the joints please.

The good part of 4.00 is that making new joints is quite easy. far easier than it was in 3.14 and lower.
so if you have your joint it should be very simple to converted to 4.00.
if not, then is probably one of the custom joint and I sould be abble to add it.

[Esharc]

Hi Julio,

I am not sure if I am doing something wrong, but I cannot get the demo's to run in debug configuration. They run fine in release, but as soon as I try to run it in debug, it gets and access violation when calling glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), &vertices[0], GL_STATIC_DRAW) while creating the skyboxy.

I am running the demos in Visual Studio and created the project files using the default settings with CMake,