Conversation
keenon
left a comment
keenon
left a comment
There was a problem hiding this comment.
I think we should think about the runLcpConstraintEngine() naming. What's the distinction with runConstraintEngine()? Seems that runLcpConstraintEngine() is one possible constraint engine you can use?
| return self->runConstraintEngine(_resetCommand); | ||
| }) | ||
| }, | ||
| ::py::arg("resetCommand")) |
There was a problem hiding this comment.
Do we want default args on this? Generally we have resetCommand = false as default everywhere.
| return self->runLcpConstraintEngine(_resetCommand); | ||
| }) | ||
| }, | ||
| ::py::arg("resetCommand")) |
There was a problem hiding this comment.
Here's another place where we could have default args, if you want them
| +[](dart::simulation::World* self, bool _resetCommand) -> void { | ||
| return self->runFrictionlessLcpConstraintEngine(_resetCommand); | ||
| }, | ||
| ::py::arg("resetCommand")) |
There was a problem hiding this comment.
And the last place where we could put them
| @@ -296,12 +296,20 @@ void World(py::module& m) | |||
| "runConstraintEngine", | |||
There was a problem hiding this comment.
What's the difference between runConstraintEngine() and runLcpConstraintEngine()? It's not immediately obvious from reading it, so maybe we should make the names a bit more explicit?
keenon
left a comment
keenon
left a comment
There was a problem hiding this comment.
Happy Holidays! Seems good, I think just minor changes to the tests and we should be good to go.
| } | ||
|
|
||
| //============================================================================== | ||
| void World::runLcpConstraintEngine(bool _resetCommand) |
There was a problem hiding this comment.
Does it actually make sense to have _resetCommand here? Doesn't the LCP create the impulses in the first place? Why would we ever not want to reset after that?
|
|
||
| // Integrate velocities from solved impulses. Should have non-negative normal | ||
| // velocity after integration. | ||
| EXPECT_TRUE(box->getRelativeSpatialVelocity()[4] >= 0); |
There was a problem hiding this comment.
I think we need one more check here to check that having no friction actually made a difference in this case. Maybe we apply a small horizontal velocity before we run the constraints engine, and check that it's still there afterwards?
It would make sense to apply the same small horizontal velocity to the test for the LCP with friction as well, and check that the friction ends up zeroing out the velocity.
Add python bindings for `Geometry/dAdInvT`
2 participants
Add frictionless LCP.