Hi.
I'm trying to work out the best way to use the BEPU physics engine to setup the physics for a robot. The robot is modular and each module has a moving part that rotates. I need the robot to be dynamic as the aim is to simulate how the modular robot can move around an environment.
The first type of physics object that I thought would work was a CompoundBody, and I have been using the internalOrientationMatrix and internalCenterPosition properties to get the sub-bodies to move the way I want them to and I change them at each update. This doesn't seem to be the type of thing CompoundBody was made for as the documentation says sub-bodies are meant to be fixed so I was wondering what people's opinions were on the best way to achieve what I want.
That said I have managed to get something which seems to work pretty well using the CompoundBody entity.
Any advice people can give me would be much appreciated.
Also I have been getting a StackOverflowException in BEPUphysics.dll when attempting to alter a CompoundBody (such as calling activate() or changing the internalOrientationMatrix) that is a sub-body of another CompoundBody which is dynamic. This only occurs when I change the child CompoundBody after the parent has been added to the Space. It will probably not be an issue for me as I can work around it, but reporting it in any case.
Cheers.
Which physics object for a robot?
Re: Which physics object for a robot?
The ideal solution for building a robot would be the modules connected by constraints. The constraints would keep the robot together, serve as motors when needed, and possibly supply friction.
Unfortunately, BEPUphysics does not have explicit support for all the constraints necessary in v0.10.0. v0.11.0 is currently planned as a constraint overhaul version which will help out in a lot of ways. It isn't impossible to do all of this in v0.10.0, it is just significantly more difficult than it needs to be.
One possible solution (other than creating custom constraints) would be approximating the constraints using other, already existing constraints. Motorization could be faked to some degree through applying impulses cleverly, though it won't be exactly correct.
If you're able to get something that looks 'good enough' using compound bodies, it might be less work overall just to keep working in that direction.
As for the exception, it should be fixed for the next version. Thanks for the report.
Unfortunately, BEPUphysics does not have explicit support for all the constraints necessary in v0.10.0. v0.11.0 is currently planned as a constraint overhaul version which will help out in a lot of ways. It isn't impossible to do all of this in v0.10.0, it is just significantly more difficult than it needs to be.
One possible solution (other than creating custom constraints) would be approximating the constraints using other, already existing constraints. Motorization could be faked to some degree through applying impulses cleverly, though it won't be exactly correct.
If you're able to get something that looks 'good enough' using compound bodies, it might be less work overall just to keep working in that direction.
As for the exception, it should be fixed for the next version. Thanks for the report.