Hi Page, I'm sorry but in the latest months we changed the Chrono API quite a bit, so I cannot easily compile your code that is referring to an old version. I would recommend you to recompile Chrono with latest version if you can.
While you others' answers, I can just broadly suggest to: - reduce stepsize to 1e-3 just to be sure - check parameters of demo_MCORE_collision_object to see if yours make sense - make sure inertia/masses properties are meaningful and that there are no extreme values - your cube explodes even before touching ground: turn on the contact normals drawing so to see if a collision is happening - turn on the collision shapes drawing to double check if you placed them correctly - put some clear and easy interia properties to body without complex computations to see if they make sense Il giorno lunedì 22 gennaio 2024 alle 08:25:02 UTC+1 Page ha scritto: > Hi Dario, > > Thank you for your feedback. I am currently using multi-core modules to > test collisions, but there is a strange phenomenon. Do you have any > feedback? Here is the code and video > > Page > > 在2024年1月18日星期四 UTC+8 23:08:40<[email protected]> 写道： > >> Hi Page, >> the answer about collision parameters has a very simple answer: *no, >> there are no one-fits-all parameters*. >> If you understand what they are meant for (if not, please refer to docs >> <https://api.projectchrono.org/development/collisions.html#collision_tolerances>) >> >> you can easily understand that they depends on size and speed of the >> objects at least. >> The default values are already set to meaningful values, but that's all. >> Anyway, usually in few iterations one can spot the trade-off that is best >> for him. >> >> About best settings: *it's difficult to say without knowing your >> specific system*. >> In general it's better to use NSC formulation to allow larger timesteps, >> but this makes sense only if the timestep is not already limited by finite >> elements or other stiff objects. >> If using NSC then you can pick either PSOR/BB/APGD, but if you have >> finite elements you need (the more experimental) ADMM+MKL. >> >> For collision detection settings I'm not an expert of Multicore >> collision, so others might give their opinion. >> >> Anyway, I would strongly encourage you to ask yourself: *are all those >> millions of faces really needed*? Can't the mesh be simplified, at least >> for collision detection? >> Even with the best hardware I don't think you will ever be able to reach >> *real-time >> with millions of faces*. >> >> Dario >> >> Il giorno giovedì 18 gennaio 2024 alle 03:02:31 UTC+1 Page ha scritto: >> >>> Hi,all >>> >>> I found that different simulation scenarios need to adjust different >>> parameters, such as: >>> >>> SetDefaultSuggestedEnvelope(0.03); >>> >>> SetDefaultSuggestedMargin(0.001),etc. >>> >>> It takes me a long time to adjust the parameters each time I simulate >>> different scenarios. Is there a common setting that works for most >>> scenarios? >>> >>> My model has many Faces, in order to improve efficiency, I used >>> multicore module, I found that the model of hundreds of thousands of faces >>> reached real-time with multi-threading, but the face simulation of 10 >>> million did not reached real-time, I want to know how to simulate the model >>> of millions of face quickly, and how to set the fastest simulation. Choose >>> what solution type, solution model, and related Settings for collision >>> detection. >>> >>> Best regards, >>> >>> Page >>> >> -- You received this message because you are subscribed to the Google Groups "ProjectChrono" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/projectchrono/c83eace2-000e-4187-989d-b5ef62c5a6e0n%40googlegroups.com.
