Forcing body to position/orientation

[PJani]

I just got idea how to deal with joints pulling apart.

If there are more bodies connected with multiple joints, example: ragdoll.
The engine should build undirected joint "graph" of body rig, to create "information" how mass is distributed between joints in in relation, so they don't start pull apart body rig.

Example if have first body connected to world() using hinge and second body connected to first body using ball and joint and i pull second body "hard" enough then the first body will start to "lose" its pin of rotation.

[JoeJ]

I also think OpenCL is the right path to go.
Including Pjanis tip on deleting the line from the project file could be added to a readme file.
The Installer problem is something Intel needs to fix.

...undirected joint "graph" of body rig, to create...

Sounds similar to Featherstone solver, i'm sure Julio has absorbed a lot of that and similar ideas
I've tried all major physics libraries, and newton turned out to be much better than all of those.
Ragdolls come to rest even when autosleep is off, and i found it useable for powered ragdolls too,
which was totally impossible with other libs, because of terrible jittering and explosions.

Unluckily there is no more ragdoll demo in the sandbox to try,
but you could quickly convert the 'applications\tutorials\Tutorial_103_AddingJoints' tutorial to the newest changes,
to see if there are problems with joints too.

Edit:
I did myself, only needs to change 3 lines in RigidBodyUtil.cpp:

NewtonBody* const body = NewtonCreateDynamicBody (world, collision, &matrix[0][0]);
// ...
NewtonBodySetMassMatrix___ (body, mass, mass * inertia.m_x, mass * inertia.m_y, mass * inertia.m_z);
//...
NewtonBodySetCentreOfMass___ (body, &origin[0]);

and delete the Platformarchitecture line.

The Demo works, but there is no way to stress the few bodies with user interface, so it does not really help.

[Julio Jerez]

I just got idea how to deal with joints pulling apart.

that is an idea, however the joint should just work. I do not like teh idea to find a work around to a bug or an ill implemnetation.
for me and impelmentation soudl haev a reason expection of robustness an dteh video you show if for form that, teher must be a big bug eiteh on yor side or my side.
I rather see if I can run the same test you are using and figure out a solution.
It is possibel you can upload a test demo linekd toi a dll, somewhere that I can test?


Also Joel I added a quick fix to eth penetration bug, can you please see if this make it better before I promote to the other pathway of the collsion system?
I test wi teh big box and I hammer teh floor hard many time and it seem right. but it is not impemented on face edges yet.
The problem is the it has being so long that I wrote the collsion system for core 200, and 100 that I forget the reasons why I did something that made no sence the secund time and now I see why I did that.

[Julio Jerez]

I will try to make some joint demos, I had negleted them fo some time because all of teh rewriting of the new collision.

[PJani]

I just got idea how to deal with joints pulling apart.

that is an idea, however the joint should just work. I do not like teh idea to find a work around to a bug or an ill implemnetation.
for me and impelmentation soudl haev a reason expection of robustness an dteh video you show if for form that, teher must be a big bug eiteh on yor side or my side.
I rather see if I can run the same test you are using and figure out a solution.
It is possibel you can upload a test demo linekd toi a dll, somewhere that I can test?

Ok i will prepare testbed, i hope it will be finished in few hours. Because main project is too complex at this stage to pack it.

[JoeJ]

Also Joel I added a quick fix to eth penetration bug, can you please see if this make it better

synced to svn but nothing changed.
See the screenshot, white line ist interaction-dragging.
See the tiny black shadow above it on the ground, which is from a small box from the friction testramp in the background.
The small box is inside the ground box (shadow is cheeeply projeted to ground hight)

Same problems for box, cylinder, capsule and sphere(!)


The ragdoll is currently powering and balancing itself


EDIT: wait, maybe i need to rebuild everything first!... but first i'll eat
EDIT2: Indeed i copied the stuff to the wrong folder, now everything up to date, but the problems stay the same.
The capsule seems to react most worse, nice for testing.

[Julio Jerez]

JoeJ. I do not really understand the bug in the image.
I am sure this is some edge case witf the new collision routines.

It is possible for me to get a test case so that I can debug this?
it is very hard for me to repproduce these cases, by makinf demos?

In theory the new collision system is designed to be very robust and efficient with close form shapes like spheres, capsules and champhered cylinders.
in core 200 these function were special cased, noew they the are generalized and also handle the scale.
But there could be a bug somewhere that is scaping my test.

the fastest and eassier way to solve these bug is by debugging and application tah can reproduce it.

[JoeJ]

I am sure this is some edge case witf the new collision routines.

But Spheres and Capsules don't have edges.

To help you, i can do 2 things:

1. Remove newton source from my project and link to dll.
So can use your dubug dll, like we did a while ago.

2. Remove all unnecessary source and libs from my program and give you the remaining source.

What do you like more?

[Julio Jerez]

I mean collision of those round shapes with polygon edges.
I am assuming this is the problem, or are you seem this also with colision between spheres and capsules?

I think if you can link at test demo to a newton DLL, that will help me debug this a great deal.

[JoeJ]

No it's not an edge case, surely not.
It happens at round shape - plane collision.
I drag them against the middle of the floor box - far away from any edge.
I'll add a static sphere and see what happens there...

[JoeJ]

I made large static sphere.
Same problems colliding against it with capsule and cylinder.
Sphere - Sphere is buggy too, but it recovers very quickly, hard to see.

Note that to provke the bug i need to interact with mouse first.
So i think it should be easier or at least the same for you to debug with your own demos.

But let me know again, if you still want my exe and i'll do the changes and send it.

[Julio Jerez]

so you made a big static sphere, and collide with anothe spheres and the collsion fail?

if I complete the serialize function, do you thonk you cna export the scene to a file and send to me?
bascally all you need to do is this, after you create you world.
NewtonSerializeToFile (newtonWorld, const char* const filename);

it will not work now because I have no fixed the serialize function since I broke the dgBody into static and dynamics bodies, but I will fix it soon.
if you do that, you can test if the scene was save by loading in the sandbox demo before you send it to me.

you think you can do that?

[JoeJ]

so you made a big static sphere, and collide with anoteh spheres

Yes.
I see in your sandbox problem is fixed... strange it's not for me.
(i use following peprocessor defines for newton:
PTW32_STATIC_LIB
DG_USE_NORMAL_PRIORITY_THREAD
_NEWTON_USE_LIB
_NEWTON_STATIC_LIB)

The Serialization would be ok and less work.

But i can make the exe too.
I code all my programs in one messy exe, so I need to get rid of a lot contet files that my app loads without filechecks,
but most stuff should be easy to disable with changing some peprocessor defines.
I'll need half an hour and hope you get a non-crashing app.

What do you want?



EDIT: removed unnec. stuff, but now i get linker errors...
I want to build newton debugDll:

1>------ Build started: Project: newton, Configuration: debugDll Win32 ------
1>Linking...
1> Creating library Win32/newton/debugDll/newton_d.lib and object Win32/newton/debugDll/newton_d.exp
1>Newton.obj : error LNK2019: unresolved external symbol "int __cdecl dgGetMemoryUsed(void)" (?dgGetMemoryUsed@@YAHXZ) referenced in function _NewtonGetMemoryUsed
1>Newton.obj : error LNK2019: unresolved external symbol "void __cdecl dgSetGlobalAllocators(void * (__cdecl*)(unsigned int),void (__cdecl*)(void * const,unsigned int))" (?dgSetGlobalAllocators@@YAXP6APAXI@ZP6AXQAXI@Z@Z) referenced in function _NewtonSetMemorySystem
1>Newton.obj : error LNK2019: unresolved external symbol "public: __thiscall dgMemoryAllocator::dgMemoryAllocator(void)" (??0dgMemoryAllocator@@QAE@XZ) referenced in function _NewtonCreate
1>Newton.obj : error LNK2019: unresolved external symbol "public: static void * __cdecl dgMemoryAllocator::operator new(unsigned int)" (??2dgMemoryAllocator@@SAPAXI@Z) referenced in function _NewtonCreate


i don't get dll, bit lib is there, i can build, but not run.
With a little luck you can, i send you pm with link...

[PJani]

oh, i found what is causing my ragdoll to dance...
I will try(is 4.30AM here and i am writing from phone) to explain the cause.
I use compound collisions for almost everything...my main goal using compunds is non homogenius mass and adds or removes of sub collissions during runtime.
now for each body i keep extra compound(which i call shadow compound) which has scaled sub collisions for faster add delete and recalculation of center of mass and moment of inertia. when i put new sub collision into shadow compound i scale it down or up(depends if new compound is heavier or lighter). reference density is 1000kg/m^3(i use densities instead of mass directly...mass is being calculated when i set mass properties).
my conclusion is...rigdoll limbs are so small that they are being scaled down to very small size and then i loose point precission and moment of inertia is being lost...

EDIT: Heh i made some modifications to my scaling(my mistake was using mass instead of density for ratio calculating, go figures), and now ragdoll behaves as it should!
EDIT 2: And to figure this out, i needed to write testbed...0_0

Now i only need to make better limit handling of ball and socket and hinges.

[PJani]

so you made a big static sphere, and collide with anoteh spheres

Yes.
I see in your sandbox problem is fixed... strange it's not for me.
(i use following peprocessor defines for newton:
PTW32_STATIC_LIB
DG_USE_NORMAL_PRIORITY_THREAD
_NEWTON_USE_LIB
_NEWTON_STATIC_LIB)

The Serialization would be ok and less work.

But i can make the exe too.
I code all my programs in one messy exe, so I need to get rid of a lot contet files that my app loads without filechecks,
but most stuff should be easy to disable with changing some peprocessor defines.
I'll need half an hour and hope you get a non-crashing app.

What do you want?



EDIT: removed unnec. stuff, but now i get linker errors...
I want to build newton debugDll:

1>------ Build started: Project: newton, Configuration: debugDll Win32 ------
1>Linking...
1> Creating library Win32/newton/debugDll/newton_d.lib and object Win32/newton/debugDll/newton_d.exp
1>Newton.obj : error LNK2019: unresolved external symbol "int __cdecl dgGetMemoryUsed(void)" (?dgGetMemoryUsed@@YAHXZ) referenced in function _NewtonGetMemoryUsed
1>Newton.obj : error LNK2019: unresolved external symbol "void __cdecl dgSetGlobalAllocators(void * (__cdecl*)(unsigned int),void (__cdecl*)(void * const,unsigned int))" (?dgSetGlobalAllocators@@YAXP6APAXI@ZP6AXQAXI@Z@Z) referenced in function _NewtonSetMemorySystem
1>Newton.obj : error LNK2019: unresolved external symbol "public: __thiscall dgMemoryAllocator::dgMemoryAllocator(void)" (??0dgMemoryAllocator@@QAE@XZ) referenced in function _NewtonCreate
1>Newton.obj : error LNK2019: unresolved external symbol "public: static void * __cdecl dgMemoryAllocator::operator new(unsigned int)" (??2dgMemoryAllocator@@SAPAXI@Z) referenced in function _NewtonCreate


i don't get dll, bit lib is there, i can build, but not run.
With a little luck you can, i send you pm with link...

Are you using static newton?