Forum Replies Created
-
AuthorPosts
-
BenjaminBlocked
Hi Alex,
Thanks a lot for your explanation. It is a bit confusing about the code. I was looking for the part that iterates the element inside the final bounding box. This is what I found. I actually tried to stop at this statement in the debug mode.
intersector->intersect(it1, it2, outputs);
Then it will go to this statement
return impl->computeIntersection(e1, e2, impl->getOutputVector(e1.getCollisionModel(), e2.getCollisionModel(), contacts));
and finally reach to this function in MeshMinProximityIntersection.cpp
int MeshMinProximityIntersection::computeIntersection(Triangle& e2, Point& e1, OutputVector* contacts);
It seems the loop in the first post is the only iteration I found related to collision elements. But it turns out it is for the bounding box.For the size 30, I found in the most right column of the Qt Creator.
pasteboard.co/MHXMAuh3Znho.pngCan I ask if you can help me how to iterate triangular collision elements in a bounding box?
Regards,
Ben27 July 2021 at 10:13 in reply to: [SOLVED] Question about calling header of SofaMeshCollision from SofaBaseCollision #20083BenjaminBlockedHi Alex,
Thank you so much for your response.
It seems the structure has been changed in version 20 compared to version 19. The calling used to work in the old version. That’s why it confused me.
I might test my algorithm by creating a component in SofaMeshCollision. Then create a new plugin if it works.
Best,
Sam7 February 2021 at 00:49 in reply to: [SOLVED] Question about variable meaning in collision component #18548BenjaminBlockedHi Hugo,
Very appreciate your help. It solves my problem.
Regards,
Ben23 January 2021 at 22:19 in reply to: [SOLVED] Question about variable meaning in collision component #18380BenjaminBlockedHi hugo,
Sorry for the late update. I have tried your method, but it seems if I need to use the old position in the collision detection, calling the position from solver is hard to make for me. From what I found, the solver updated every time before the collision detection is triggered.
So I am trying to add additional function in BruteForceDetection (my version) to store the old position. I want to store the position along with point index, so that I can compare old position and current position based on the index. The code I am using to get the position is
core::behavior::MechanicalState<defaulttype::Vec3Types>* mstate = mstate = dynamic_cast< behavior::MechanicalState< defaulttype::Vec3Types >* >(getContext()->getMechanicalState());
Then call the position by usingmstate->read(core::ConstVecCoordId::position())->getValue()
. However, the mstate in BruteForceDetection return null (0x0). Can I ask if I am using the right statement?Also, I have noticed in TriangleModel.h or other collision model head files. The statement for returning a point position is
model->mstate->read(core::ConstVecCoordId::position())->getValue()[(*(model->tetra))[index][0]];
Can I ask if I want to return all the points position in the object, how I should do?Really appreciate your support.
Regards,
Ben20 November 2020 at 03:21 in reply to: [SOLVED] Question about variable meaning in collision component #17771BenjaminBlockedHi Hugo,
Sorry for late reply and thanks for the explanation.
I have sort of figuring out the usage of CollisionElemenIterator. But there is another problem appears. My collision algorithm requires to compare the node positions in previous frame and current frame. Does SOFA store all nodes’ old positions? From what I have seen in Intersection either BaseProximityIntersection or other intersection methods, none of then applied the node position from previous. All of them are using current position to detect the collision. Could you give me some advice on this one?
Regards,
BenBenjaminBlockedHi @twxu,
I also have the same problem as you. Can I ask if it is possible to tell me how to align the mesh from two different object?
Regards,
BenBenjaminBlockedHi Francois @fleonard,
Thanks for your reply.
What I am thinking is to replace the detection algorithm in SOFA with my algorithm. The part of code in SOFA I’d like to replace is the addCollisionPair in BruteForceDection.cpp. So the same outputs as the old code (contact time, contact point, etc.) will be given by the new algorithms and the SOFA will use these outputs to do the response as it used to be. And the other parts of codes like response won’t be modified.
I haven’t reach to the freeAnimationLoop right now. I saw your old post saying it would be considered when implementing your collision dectection. Can I ask why?
Regards,
BenBenjaminBlockedHi Hugo,
I am also currently working on Continuous Collision Detection. Do you know if anyone is familiar with this part? Do you have suggestions how to build the unit test to test the collision part in SOFA?
Regards,
Ben -
AuthorPosts