Height Field Collision Issue

Report any bugs here and we'll post fixes

Moderators: Sascha Willems, Thomas

Re: Height Field Collision Issue

Postby Julio Jerez » Sat Dec 11, 2021 1:05 pm

That happens sometimes when recreating the project in cmake, what I do is that I delete and recreate it again.
please try sync, I made many classes renaming and then delete your generate cmake solution and try to recreate again.

I believe I had all of the dClasses renamed to ndClass, but maybe I missed some.
I still have to rename the native types, like dInt32 to ndInt32 but that can be done on another pass at renaming.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Esharc » Sun Dec 12, 2021 1:39 am

Thank you, I will sync today and try to remake all the project files again.

*EDIT*
I tried deleting all the generated CMAKE files and recreating the projects, and it still does not work in debug configuration.
Esharc
 
Posts: 120
Joined: Tue Jan 10, 2017 5:23 am
Location: South Africa

Re: Height Field Collision Issue

Postby Julio Jerez » Sun Dec 12, 2021 5:39 am

I do not know what that could be.
I just stepped in function ndSkyBox::ndSkyBox(GLuint shader) in debug
and I did not see any error.

the only thing I can think of is
1-Place a break point in file ...\applications\ndSandbox\toolbox\ndSkyBox.cpp line 167
I had problem in the pass with opengl when loading texture or making midmap. I had the loop that when an error occurs, it will flush the gl stack.
place a break point there see if you get an error.

2-there used to be an application called glDebugger that we very good to for tracing these kind of errors, but for many years does not even download anymore, we are left with the moronic RenderDoc which I have never seen it working.
It seems all vendors are advandone openGL and we are out of luck debugging.
but the library that I am using has some very limited debug/log functionality

in file ....\newton-4.00\thirdParty\glatter\include\glatter\glatter_config.h
go to line 74 and uncomment those lines.
It will open a console window and trace all the gl call and will show if there was an error. I do not enable because it makes if very slow with flooding the console window.
Other than that, I do not know what else could be wrong.

one last thing, remember to click build Installer in windows, at least once.
Some people forget that and the assess are not copied to the destination folder and you get gl errors.

last trees questions.
1-what version of visual studio?
2-does is print any message to the debug windows?
3-Are you building static libraries or dlls?

I found one problem in the cmake script, I was exporting the pdb, but that only works for dlls, cmake say that when issuing pdb for libs, it creates artifacts. whatever that means.

please sync again to get that change.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Esharc » Mon Dec 13, 2021 3:20 am

Thank you for all the changes, I synced this morning and transferred all the changes to my project, and the only change I had to make was dFloat64 to ndFloat64 and dFloat32 to ndFloat32. Then all compiled fine as expected.

Regarding the Sandbox in Debug configuration, I have no idea what is going on there, I will have a look further when I have a little time to spare. Currently running through all our tests and making sure the changes are correct.

I have tried the solutions you suggested and none work, there were no errors at the breakpoint at line 167 of ndSkybox.cpp, and no get time to print to the console window for the gl calls before the exception is thrown. When I make the project files I make no changes, just create the project with 2015 compiler selected. Same in Visual Studio when I load the project. I just build it and run after making sure to build Install

I am using Visual Studio 2019
The only message printed in the debug window of Visual Studio is Exception thrown at 0x000000A4 in ndSandbox.exe: 0xC0000005: Access violation executing location 0x000000A4.
I am building dlls

I will debug this further when I have a little more time on my hands. For now I get enough information from the release configuration when running the sandbox application.

Fortunately I have Newton 4 working in my project, so I can continue with my tests for now.
Esharc
 
Posts: 120
Joined: Tue Jan 10, 2017 5:23 am
Location: South Africa

Re: Height Field Collision Issue

Postby Julio Jerez » Mon Dec 13, 2021 11:18 am

Esharc wrote:Thank you for all the changes, I synced this morning and transferred all the changes to my project, and the only change I had to make was dFloat64 to ndFloat64 and dFloat32 to ndFloat32. Then all compiled fine as expected.

yes I expect that would be the next problem, on a second pass I will rename the native types the alone with the utility functions. and that should be all.

on the debug config, I do not really know what is going on there. I have never seen a project that fail in debug and not in release unless it was intentional.
it seems a graphics problem which is outside my scope, meantime you can try Release with debug, that is almost a debug build without all the baggage of the debug build.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Esharc » Tue Dec 14, 2021 1:57 am

Thanks for that tip for the ReleaseWithDebug. It works fine, I just changed it so that it uses ndNewton_d instead of ndNewton so that I have full debug capability from the engine.

But I see now that there is an assertion that happens when InitWeights() is called. The array of me->GetJointForceIndexBuffer() is 0 when indexing, and then the assertion in ndArray.h with the overloaded [] operator is called.

This happens when running the default demo when starting the application.
Esharc
 
Posts: 120
Joined: Tue Jan 10, 2017 5:23 am
Location: South Africa

Re: Height Field Collision Issue

Postby Julio Jerez » Tue Dec 14, 2021 3:51 pm

Esharc wrote:But I see now that there is an assertion that happens when InitWeights() is called. The array of me->GetJointForceIndexBuffer() is 0 when indexing, and then the assertion in ndArray.h with the overloaded [] operator is called.


you probably have a version between.
This last round of changes has been a nightmare, never I thought that making these last changes to make the solve less branchy was going to be so challenging.
once again, I when back to and older version. I will try one more time this week, and I guess this will take some time, so I will not make any more intermediate commits until I have very solid.

anyway, I finally renamed the last native types: dInt32, dFloa32 to have nd prefix.
I test it and seem stable again.
so if you sync, it should work, and if you get some compiler error please tell me, because is hard to find if there are still duplicate names with 3.14
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Julio Jerez » Wed Dec 15, 2021 9:16 pm

Esharc wrote: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.


on thatquestion, I did not provide a clear answer.
But is quite easy to set general row with newton 4.0
this is because the c++ interface facilitates exposing all the core functionality, so it does not need that many functions.

there are few examples, you can use as templates to copy from.

the simpler one I can thon off is the ndJointPulley
Code: Select all
void ndJointPulley::JacobianDerivative(ndConstraintDescritor& desc)
{
   ndMatrix matrix0;
   ndMatrix matrix1;

   // calculate the position of the pivot point and the Jacobian direction vectors, in global space.
   CalculateGlobalMatrix(matrix0, matrix1);

   AddAngularRowJacobian(desc, matrix0.m_front, ndFloat32(0.0f));

   ndJacobian& jacobian0 = desc.m_jacobian[desc.m_rowsCount - 1].m_jacobianM0;
   ndJacobian& jacobian1 = desc.m_jacobian[desc.m_rowsCount - 1].m_jacobianM1;

   jacobian0.m_linear = matrix0.m_front.Scale(m_gearRatio);
   jacobian1.m_linear = matrix1.m_front;

   const ndVector& veloc0 = m_body0->GetVelocity();
   const ndVector& veloc1 = m_body1->GetVelocity();

   const ndVector relVeloc(veloc0 * jacobian0.m_linear + veloc1 * jacobian1.m_linear);
   const ndFloat32 w = relVeloc.AddHorizontal().GetScalar() * ndFloat32(0.5f);
   SetMotorAcceleration(desc, -w * desc.m_invTimestep);
}


basically, you add a linear of angular row, does matter, the you get the reference to the jacobians from the descriptor, and you override them.
there are many examples if you just do a global search for desc.m_jacobian you will find them all.

you just subclass you joint from ndJointBilateralConstraint and you implement you JacobianDerivative and that should do the trick, let me know if you still have problems.

also do not forget to sync, I finally found that moronic bug that was hunting me for month.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Esharc » Wed Jan 05, 2022 12:35 am

Hello Julio,

Happy new year. Sorry for the long delay in the messages, I was on leave. I will implement your fixes as suggested and let you know if I have any issues further.
Esharc
 
Posts: 120
Joined: Tue Jan 10, 2017 5:23 am
Location: South Africa

Re: Height Field Collision Issue

Postby Esharc » Wed Jan 05, 2022 8:32 am

Hi Julio,

I could sync with the latest Newton and add it to my project and build without any issues between Newton 3.14 and 4.0. Thank you for this.

Currently I am a little stuck with ndContact and ndContactSolver. We have a ghost object that does not have a body, only a collision shape that we use for various testing of intersections/collisions with other bodies/ghost objects in the world.

In Newton 3.14 we would iterate over all bodies in the AABB of the ghost object using NewtonWorldForEachBodyInAABBDo and then use NewtonCollisionCollide to determine if the ghost object is colliding with a body and NewtonCollisionIntersectionTest to determine if the ghost object is intersecting with another ghost object.

I do not see any of these functions in Newton 4.

What I currently have is ndBodiesInAabbNotify which will have all the bodies in the AABB of the ghost object which I can iterate over. This solves the NewtonWorldForEachBodyInAABBDo.

I am now trying to get the ndContactSolver and ndContact created so that I can test for collisions using the CalculateContactsDiscrete funtion in the solver. But I cannot set the bodies for ndContact, nor can I set the m_contactBuffer and m_intersectionTestOnly in ndContactSolver since they are private.

Is this the intention and I am following the wrong path, or will you be able to add public setter functions for them so that I can set them in my class?
Esharc
 
Posts: 120
Joined: Tue Jan 10, 2017 5:23 am
Location: South Africa

Re: Height Field Collision Issue

Postby Bird » Wed Jan 05, 2022 10:38 am

In Newton 3.14 we would iterate over all bodies in the AABB of the ghost object using NewtonWorldForEachBodyInAABBDo and then use NewtonCollisionCollide to determine if the ghost object is colliding with a body and NewtonCollisionIntersectionTest to determine if the ghost object is intersecting with another ghost object.

I do not see any of these functions in Newton 4.


I am doing something very similar and am also in need for these function in Newton4
Bird
 
Posts: 623
Joined: Tue Nov 22, 2011 1:27 am

Re: Height Field Collision Issue

Postby Julio Jerez » Wed Jan 05, 2022 2:08 pm

Currently I am a little stuck with ndContact and ndContactSolver. We have a ghost object that does not have a body, only a collision shape that we use for various testing of intersections/collisions with other bodies/ghost objects in the world.


you got the correct insight,
those function of 3.14 are no longer needed, but you are right there is not function on the ndContactSolver to calculate collisions.

later I will add a function so that you cna do something like this.

1- after you can for all objects is aabb.

for can do this

Code: Select all
collision myshape.
ndContactSolver solver;
for  each object i in aabb
        contacts[size];
        solver.CalculateContacts (myShapeMatrix, myshape, object[i].Matrix, object[i], contacts)
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Julio Jerez » Wed Jan 05, 2022 2:43 pm

ok if you sync you find two new functions in ndContactSolver
Code: Select all
   D_COLLISION_API ndContactSolver();
   D_COLLISION_API void CalculateContacts(
      const ndShape* const shapeA, const ndMatrix& matrixA, const ndVector& velocA,
      const ndShape* const shapeB, const ndMatrix& matrixB, const ndVector& velocB,
      ndFixSizeArray<ndContactPoint, 16>& contactOut);


they don't do anything yest, I will populate them later, but you can tell me if you can make your code logic, with that interface.

again, there is not continues or discrete in newton anymore, is it just the distance calculation. and the app can extract the information.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Julio Jerez » Wed Jan 05, 2022 4:26 pm

ok this is how it used.

Code: Select all
   ndContactSolver solver;
   ndFixSizeArray<ndContactPoint, 16> contactOut;
   ndBodyKinematic* bodyA = contactJoint->GetBody0();
   ndBodyKinematic* bodyB = contactJoint->GetBody1();
   const ndShapeInstance& shapeA = bodyA->GetCollisionShape();
   const ndShapeInstance& shapeB = bodyB->GetCollisionShape();
   solver.CalculateContacts(
      &shapeA, bodyA->GetMatrix(), bodyA->GetVelocity(),
      &shapeB, bodyB->GetMatrix(), bodyB->GetVelocity(),
      contactOut);


as you can see much simpler that 3.14
notice that the contact is not necessary, I am using because I am calling form a contact callback which provide a joint, this way I can verify that is producing same results. and it is.

there is one small thing I have to do, but for now you can test it.
what I have to do is that when hitting a compound, I have to check if it hit a sub shape
so that the hit point set to the sub shape, and no to the root.
that is not reported by the contact solver, is just report a shape pointer.
so I have to add some reflection so that the shape tells me if it is a sub shape.
that does not exist yet.
I do it later.
Julio Jerez
Moderator
Moderator
 
Posts: 12249
Joined: Sun Sep 14, 2003 2:18 pm
Location: Los Angeles

Re: Height Field Collision Issue

Postby Esharc » Fri Jan 07, 2022 3:19 am

Thank you for the changes, I have implemented my ghost objects as you suggested, and it is much simpler as you said.

I did see two issues though:

1. In the CalculateContacts function you specify that the max size of the contactOut array must be 16, but you set the size of the contactBuffer to D_MAX_CONTATCS (128). Later you loop through the returned contacts in the contact buffer and push them into the contactOut array. But you have asserts in the ndFixSizeArray class to make sure that the element being pushed in will fit in the array. So it will then assert if the number of contacts in the contact buffer is more than 16.

2. In the SetShape function of ndShapeInstance you have a line of code
Code: Select all
m_shape = m_shape ? shape->AddRef() : m_shape

This caused issues for me because m_Shape is null when that function is called. I changed it to
Code: Select all
m_shape = shape ? shape->AddRef() : m_shape

and that fixed the problem. It makes sense that it should be checking the function parameter instead of the class member before adding the reference, I assume this is just a typo?
Esharc
 
Posts: 120
Joined: Tue Jan 10, 2017 5:23 am
Location: South Africa

PreviousNext

Return to Bugs and Fixes

Who is online

Users browsing this forum: No registered users and 1 guest