Balljoint Constraint Behavior

[Julio Jerez]

sorry dNetwon

you can see it by opening the project: ../opment\newton-dynamics\applications\tutorialsSDK300\CNewtonTutorials

[manny]

It is an all in one library.Can you point me into the right direction?

Hi there,

dNewton is a shell around the Newton C-API and links together various other libraries built around the newton core. It does this to build an easier API - but that's arguable.
I don't want to offend anyone but IMHO it's quite the bloatware since I'm looking for the most light-weight solution in terms of codesize.An example, we've got our own math library in our engine, if we would integrate Newton we would have to link in another math library from and for core_300 - and we would even have to use another math library (dMath) for dNewton and dCustomJoints etc.

Julio, did you make any progress in throwing out the old/dead source code parts? Did you consider moving core joints like ball/hinge from dCustom back into the core project after throwing out the defunct joints?

[JoeJ]

Why do you not rebuild the most important joints with your own math lib? Then you could get rid of cMath and Joint Lib... If code size matters so much.
Notice that Joint Lib is just an example on how to use newtons flexible custom joint system, and it is not core for a good reason:
Joint Lib is easy to understand and adjustable to custom needs - other engines just give you a basic joint and you have to be happy with it.
dMath is nice for Joint Lib because not everyone is willing to deal with simd alignment issues for non performance critical code.

[manny]

Why do you not rebuild the most important joints with your own math lib? Then you could get rid of cMath and Joint Lib... If code size matters so much.
Notice that Joint Lib is just an example on how to use newtons flexible custom joint system, and it is not core for a good reason:
Joint Lib is easy to understand and adjustable to custom needs - other engines just give you a basic joint and you have to be happy with it.
dMath is nice for Joint Lib because not everyone is willing to deal with simd alignment issues for non performance critical code.

You are absolutely right, but I do not want to do this if Julio decides to throw out the old dead joints and replaces them with the new basic joints. I think it would be a good idea to ship the core lib with the basic joints everybody knows.

[Julio Jerez]

when you link static library only the stuff that are referenced are of the final binary, the rest is stripped by the linker.
yes newton wrap the depended libraries that you need but is does that in the form of static lib the result is a single all in one DLL, or static library.
if code size if when worries you, the dNetwon.DLL is 380 kilobyte in size. Probably smaller if you use as static library


I do not understand why of all of the things that are a concern with a physic library,
size if what worry you more when memory is the cheapest commodity on any computer.
when you use newton, assuming you reference every single function of the engine, you are still talking a few dozen of kilobyte in your final binary.
I do not know of any practical library that is smaller than Newton, considering that newton does not just a physics library is also a computational geometry library, an arbitrary Presidion floating point library, a polygonal mesh utility,
a container libraries, and few other thing that I do not even remember.

[manny]

when you link static library only the stuff that are referenced are of the final binary, the rest is stripped by the linker.
yes newton wrap the depended libraries that you need but is does that in the form of static lib the result is a single all in one DLL, or static library.
if code size if when worries you, the dNetwon.DLL is 380 kilobyte in size. Probably smaller if you use as static library

I am aware how the linker/codestripping process works. I am not explicitly worried about code size per se, but rather the size of the codebase and including unnecessary code (i.e. multiple math libraries).
We are building our engine/games on many systems and our golden rule is to avoid external dependencies wherever possible, this has many reasons. Newton would be the only library we are including. We also do not link against DLLs as not all platforms support dynamically linked libraries.

I do not know of any practical library that is smaller than Newton, considering that newton does not just a physics library is also a computational geometry library, a arbitrary Presidion floating point library, a height polygonal mesh utility, a container libraries, and few other thing that I do not even remember.

While that is awesome, you have to understand that a lot of people already have their own container and std. object library implementation, so these things might not be as valuable to those people.
I understand that we can throw out everything we don't see fitting, but this would make merging updates more difficult to us.

Anyways, I would be happy if you would reconsider replacing the broken default joints in the Core300 library with the new working ones. Whatever you do, we're really fond of Newton and we will find a way to align it with our guidelines and integrate it.