Joints and constructors

[JoeJ]

Currently i need to create (and allocate) each joint individually with new to initialize by constructor.

But i want to have e.g. an array of joints, to manage memory and avoid dynamic allocation costs.
Is this possible?

[Julio Jerez]

No, the joint do not have default constructors no.

But, having an array of to create them so save memory activity, but not memory size.

The chunk would has to be the Suze of the largest joint, and you will have to initialize the using copy constructors.

I find that too cumbersome.

But if memory concern you, in the engine all objects that can be part of large set are free list.

This is archived via the base class and operator new and delete.

Buy using this each object goes to its own free list, and memory is manage automatically by each free list beam.

This give you the best of all world.
It uses standard cpp, zero memory fragmetation, each memory pool is the size that need to be, and const time allocation.

It is not just joints that goes to free list, it is ton of other objects, bodies, contact points, list elements, tree nodes, and many more,

[JoeJ]

I find that too cumbersome.

It's not your responsibility at all, if you make it an option so your users can handle it on their side.

I'll look at the free list approach, but i guess it's not what i want, because it's still unique objects then.

I'll give an example of what i want:
Game is like GTA. As the player moves around, close up pedestrians and cars switch from animation to simulation.
That means we have to create lots of bodies and joints constantly during gameplay, and initialization becomes a performance problem.
To solve this, we could eventually use big character and vehicle structs which contain all bodies and joints for an instance of the generic model. Because our game is mostly about people and cars, those two structs would already handle most cases, and we might not need to use individual pools for each type of joints and bodies.
To initialize a new character, we only need to get one free block form the pool, loop over bodies and joints to initialize, finally give Newton pointers to the stuff.
If we remove it, We inform Newton to remove the stuff from simulation, and care about deallocation again on our side.

Wouldn't that be nice, and actually little work for you to support?
I declare this my biggest request, followed by scrolling open world support (which ofc. is serious work).

Afaik, the quick add/removal problem was the primary reason why the new Horizon Zero Dawn game uses a hobby physics engine of one of its employees, 'Jolt'. It's on Github, maybe worth a look.

Btw, my experience with 4 is pretty good so far. Finding functionality is harder now, missing the C API, but otherwise everything is easier and more efficient.

[Julio Jerez]

That means we have to create lots of bodies and joints constantly during gameplay, and initialization becomes a performance problem.

this is the same with newton4, you can have the character ready and no added to the world.
them you can added or removed it anytime, this was different in 3.xx
As you used 4.0c, I believe that you will find it it is far easier to used than older 3.xx and Lower.
Removing the c interface add ton of cpp functionality that can be used directly that in c has to be funnel it with callbacks and user data.
On the memory, I say just try to use it, you will see that the memory management is quite efficient.

[JoeJ]

It is not just joints that goes to free list, it is ton of other objects, bodies, contact points, list elements, tree nodes, and many more,

Hmm, i did not think about contacts or nodes. I see there's probably little benefit in managing just bodies and joints with that in mind.

For my IK solver i'm currently using arrays of body / joint infos. Probably i'll just add pointers to Newton objects to keep them related. Then i can create Newton objects as intended.

this is the same with newton4, you can have the character ready and no added to the world.
them you can added or removed it anytime, this was different in 3.xx

I guess that's something implemented per ndModel?
Ha, yes - there are AddToWorld functions. So i already made progress on 'finding functionality'

But that's all stuff i still have to learn first.
Currently working on a smart picking joint to see if the joint interface has changed. Works out well so far.
After that i want to add some static world geometry, which i have never done yet at all.
Then i'll add your car to learn about those things...