Vehicles in 3.0?

[Julio Jerez]

Ok now to make eassy to integrate with a game engines I added the BasicCar demo using only Newton elements.

The demo can be set a to all wheel drive, rear wheel drive, and front wheel drive.
Is really fun (to me) to make it rear wheel drive and do drifting and power slides when turning.

I will add some code to a just the interaction with lightweight dynamic object n the scene, it do no react very nice but that easy to solve.
after I will add the Flight model.

does any one has a Airplane model that can donate? a WWII p51, P32 of maybe a Messerschmitt

[Julio Jerez]

Ok guys now I added that third type of Vehicle.

Tracked Vehicle. I made a M1A1 tank, this is a challenging in one because It is heavy, and mia1 tank are the equivalent of supercars in the Tank word.
I thing that for a first pass this fell pretty good.

Now I will add the Assort joint, these are joint that allow to add moving part to vehicle,
stuff like opening doors, hanging decorations, moving weapon, and stuff like that.
these will be feature that will have enable disable capabilities.

I will that for adding the Torrent and the Cannon to the military vehicles.


Note: the tank thread do no roll with the tire, this will be a graphics feature that I will add as an option. most people use scrolling UVs for that, but I will investigate the use of a spline path, and if is come out well I may added as a Vehicle functionality.

[Julio Jerez]

I am looking a this video for tip on how to animate the tank track

[manny]

Awesome, great that your focus is back on vehicles. IMHO that is one of the most important aspects of a physics library.

Ok now to make eassy to integrate with a game engines I added the BasicCar demo using only Newton elements.

I think it would be better if we seperate it from dCustomJoints.
I said this before, it might be hard to understand but our engine is huge and we're on multiple platforms: from android to xbox one. Our buildscripts are complex, and we have to minimize the amount of libraries we include in our engine. That is why we only use the newton physics project and nothing else. That is also the reason we have rolled our own vehicle code (which does not depend on dCustomJoints).
I vouched for this before, but the base physics engine should be a single library that includes all most used joints. Anything special should reside in a seperate lib.

planes and tanks, that sounds awesome. I hope we will use that in some future project. Don't forget about 2 wheeled vehicles (bicycles and motorcycles) and hover cars. All that stuff can actually be simulated with a ray cast vehicle

[Julio Jerez]

Ok course two wheel vehicles is a most.

The dJointLibrary can be linked statically, and it is actually very small.
I do not understand why you have a resistance to it. I like to have things compartmentalized.

[JoeJ]

and we have to minimize the amount of libraries we include in our engine

You could build a single newton lib that includes only the joints you really need. That means more work to keep up to date when Julio adds or removes files, but that does not happen so often. I do it a similar way because i add all newton source to my project.

[manny]

I do not understand why you have a resistance to it. I like to have things compartmentalized.

Yes, from a library builders perspective that is great. But if you have to include such a clustered library in a custom build processes and you have to maintain all those makefiles across multiple platforms it is incredibly tedious. It also means you have to recompile even more dependencies. There is a trend on the internet amongst coders and that is to develop single file librarys. They're insanely popular for exactly that reason I've stated. Ease of integration and no dependencies.
Compiling on console platforms is incredibly slow, and that makes it even worse, when you have to recompile a library where you're only using a single method. Hard to justify that wasted time. Yup, 10+ minutes of build time.

IMHO, this would be less of a problem if there would be dynamic link libraries available on ALL platforms and precompiled binaries. However some platforms only allow for static linked libs, so this does not work. And if it works, who will maintain the libs with the proper compilation flags for your project? And if there are no precompiled libs available then recompiling all that is tedious again, because you compile certain consoles on Win8.1, other consoles on Win7, ios/osx on a mac etc.

You could build a single newton lib that includes only the joints you really need. That means more work to keep up to date when Julio adds or removes files, but that does not happen so often. I do it a similar way because i add all newton source to my project.

Sure, but that means to maintain an own fork of a project, that's even worse than maintaining dependency builds. Things like that are not feasible when you have to ship games and you are a small studio.

When architecting our engine we made sure to avoid huge external dependencies, we've learned from previous mistakes with many dependencies and custom forks that become hard to maintain. I speak from my personal experience that it's best to avoid huge libs like gtk, libglib, wxWidgets, libJPG etc. when you want to create a system that builds accross multiple platforms out of the box. You'll have to care about your own code enough so it's best to not maintain third party code.

Julio, maybe the solution is to include a special makefile/project that we maintain for all major platforms that builds newton dynamics as a single library. But the project already includes so many project files (all those vs project files...), might not be wise to add even more project files.

ugh, TL;DR; it's time consuming to integrate and maintain a library in a 3d engine build process, so every library that is integrated has to be reviewed if that commitment now and in the future is really worth it.

[Julio Jerez]

it may be time consuming to add to a project, but that some it is done once.

The reason you are given for not separating related files in libraries are, to me the same reason for separating related file into separate libraries.

libraries are no compile each time to build a project, only when a dependency library header is modified.
the djoint, dcontainer and dmath are very small set of libraries that allows me to work in insulation

when I touch anything on those libraries, the core libraries are no touched, which is what a compartmentalized design ought to be.
plus those libraries I use on other projects with out the baggage of a physics engine.

[manny]

what you say is right, if you're using the MSVC project files with everything setup nicely. But if you have to setup the whole project from scratch and develop a ton of makefiles for a platform like android that is something you don't want and then you'd have to maintain it yourself.
I am arguing here from the perspective of a person who has to maintain an engine that builds across lots of platforms with different compilers and architectures. Some of those have no IDE and use a custom buildsystem like android or HTML5.

But there is sourcecode access, and the project can be forked, and everybody is capable of just doing what joe said and simply build a lib that fits the size

[Julio Jerez]

But there is sourcecode access, and the project can be forked, and everybody is capable of just doing what joe said and simply build a lib that fits the size

I think you are making too much out of that, as you say the project is 100% open source.
even I put the project together different with different platform.

In Window I have the Newton core as tree different libraries: core, physics and Newton
but in Linux and OSX I simply take of the CPP files and put then together in one library.
I only separate then by directory.

the same can be done with the other libraries, they all can be added as jut one big single library by adding the source files to just one project.

[pHySiQuE]

Basically, the Newton C API was simple and easy to use. The commands were documented and clear. This is why I originally used Newton, and then I found out how accurate and stable it was, which is why I stayed with.

The vehicle joint involves four or five different C++ classes. I briefly tried to compile it, but couldn't figure out which .cpp files to include, and didn't go beyond that. Then you look at your demo example, and it involves 800 lines of code, more classes to manage those classes, and it's just a giant mess of loading code, rendering code, custom classes, with some physics setup code buried in there somewhere. This is why people do not like the C++ joint library. The actual information we want is buried in a lot of extra stuff we don't want.

It's like when my biochemistry professor would say "read about this idea in this chapter", and you would have to sift through 60 pages of dense text to try to figure out what he actually wanted you to know, when 95% of the information wouldn't be on the test.

As a result, I just haven't bothered to get vehicles working yet, whereas with the old C API I would have had it running in ten minutes.

I don't know if you necessarily need to change anything, but it's just a big hindrance to usage. I'll probably get to it some time next month if I have time, instead of having it done already.

[Julio Jerez]

you have not look at it because the vehicle controller only need one class
CustomVehicleControllerManager

you sub classes and to overload the callbacks. this si why I made the BasicCar demo so that people have a simpler time going over it

ad for the include, this is quite a simple problem, what I do is that in my app I made a base include file to include header file of dependent libraries.

for example the
stdafx.h file for the demos include these files form the joint library

Code: Select all

#include <CustomHinge.h>
#include <CustomHingeActuator.h>
#include <CustomBallAndSocket.h>
#include <CustomSliderActuator.h>
#include <CustomUniversalActuator.h>

#include <CustomInputManager.h>
#include <CustomTriggerManager.h>
#include <CustomControllerManager.h>
#include <CustomKinematicController.h>
#include <CustomPlayerControllerManager.h>
#include <CustomPlayerControllerManager.h>
#include <CustomVehicleControllerManager.h>
#include <CustomArcticulatedTransformManager.h>


this is great because them you can place that file s you precompile header and you compilation time is about 10 time faster. this apply to Xcode and Visual studio. I have no seeing doing any better in Linux.
I do no really know what to do, people keep finding the engine too difficult to use, and I can tell you compere to other engine Newton in by far much easier to use.

[manny]

I think you are making too much out of that, as you say the project is 100% open source.
even I put the project together different with different platform.

Yup, don't worry -- that's what I am already doing, but my point is - if everybody is doing that why not make it a stock-option

Basically, the Newton C API was simple and easy to use. The commands were documented and clear. This is why I originally used Newton, and then I found out how accurate and stable it was, which is why I stayed with.

<snip>

As a result, I just haven't bothered to get vehicles working yet, whereas with the old C API I would have had it running in ten minutes.

I don't know if you necessarily need to change anything, but it's just a big hindrance to usage. I'll probably get to it some time next month if I have time, instead of having it done already.

That is a strong point here: So we can support them via the C API. Which we also use for our engine (well besides for the custom vehicle joints)

The Newton C API is really awesome.

EDIT: well, we could also add a C-API to the dCustomJoints project

[pHySiQuE]

I spent about an hour on this, and got this far:

Code: Select all

   //Create vehicle
   NewtonWorld* newtonworld = ((NewtonDynamicsSimulation*)world->simulation)->newtonworld;
   CustomVehicleControllerManager manager = CustomVehicleControllerManager(newtonworld);
   float gravity[3] = { 0.0, -1.0, 0.0 };
   float mass = 10;
   float mat[16] = {1.0,0.0,0.0,0.0, 0.0,1.0,0.0,0.0, 0.0,0.0,1.0,0.0, 0.0,0.0,0.0,1.0};
   Shape* shape = Shape::Box(1.0, 1.0, 4.0);
   NewtonCollision* collision = ((NewtonDynamicsShape*)shape)->collisions[0];
   vehicle = manager.CreateVehicle(collision, mat, mass, gravity);
   
   CustomVehicleControllerAddTire(vehicle,0,0,0,1,1,1,0.1,0.1,0.1,0.1,0.1,0.1);
   
   vehicle->Finalize();

CustomVehicleControllerBodyStateTire* CustomVehicleControllerAddTire(CustomVehicleController* vehicle, float x, float y, float z, float mass, float radius, float width, float suspensionDamper, float suspensionSpring, float suspensionLength, float lateralStiffness, float longitudinalStiffness, float aligningMOmentTrail)
{
   CustomVehicleControllerBodyStateTire::TireCreationInfo tireInfo;
   tireInfo.m_location[0] = x;
   tireInfo.m_location[1] = y;
   tireInfo.m_location[2] = z;
   tireInfo.m_mass = mass;
   tireInfo.m_radio = radius;
   tireInfo.m_width = width;
   tireInfo.m_dampingRatio = suspensionDamper;
   tireInfo.m_springStrength = suspensionSpring;
   tireInfo.m_suspesionlenght = suspensionLength;
   tireInfo.m_lateralStiffness = lateralStiffness;
   tireInfo.m_longitudialStiffness = longitudinalStiffness;
   tireInfo.m_aligningMomentTrail = aligningMOmentTrail;
   return vehicle->AddTire(tireInfo);
}

Then I get some debug assertion crash. Just setting the steering looks like it takes another C++ class. And of course if you get one little value off, the whole thing blows up. And there's no documentation.

The implementation looks really nice, but I am just trying to make a point that the integration experience for this kind of stuff is less than optimal. This is why you've had convex fracturing for about a year now, and we still don't support it.

[FSA]

This is why you've had convex fracturing for about a year now, and we still don't support it.

Me too