Open nicolas-schreiber opened 1 year ago
A small comment to creating a Mujoco Database similar to your https://github.com/kevinzakka/mujoco_scanned_objects with the YCB Objects I think that is a great Idea, however, I found that a lot of the settings, especially of the convex decomposition greatly depend on the specific use-case. Creating a widely useful dataset while supplying the tools for creating a custom dataset might make sense. (which I guess you are kind of doing with obj2mjcf)
It really depends on the required accuracy. With a higher number of allowed convex subcomponents and a higher allowed number of triangles per subcomponent might increase the accuracy of the decomposition but would increase required simulation time
Hi @nicolas-schreiber, thank you so much for starting this discussion!
Absolute paths and configurable naming should be pretty straightforward to add and I agree that supporting them is a good idea. URDF support does feel a little out-of-scope but I also see its usefulness.
Regarding configuring things like inertial parameters and more MuJoCo-specific things, I'm still a bit torn. On the one hand, I have indeed run into cases where it would have been very useful and I don't know what the API to support such a use case would be (maybe parsing it from a yaml file?). However, it does feel like this is transcending the scope of a pure "mesh converter" and sometimes, tuning these parameters is more of a back and forth process where you actually use the output XML in simulation and tune from there (at which point you're done with obj2mjcf
).
Regarding V-HACD, I completely agree. I'm actually extremely unhappy with some of the results (I tried a bunch of YCB objects this weekend and it was a disaster). It seems the new update that was pushed (v4) performs worse than the older version, yet the authors claim the contrary (e.g. see this thread). Plus there's a bunch of raised issue that shake my confidence in the tool. I think trying out the older version (which I think pybullet uses) is an excellent idea.
Finally, I think more generally we should add extensive unit tests with a bunch of OBJ files ranging from simple to very "edge case" and make sure updates to obj2mjcf
correctly handle them.
Hi @kevinzakka, thank you!
Yeah, I totally understand the issues with defining the MuJoCo Specific parameters, and I also do not yet fully understand their impact, I'd just suggest to add an argument to set them commandline-side when using obj2mjcf
. One could easily do that afterwards by hand, but it might make automation easier.
Regarding V-HACD, as far as I understood PyBullet is still using V-HACD 2.0, but they fully integrated the V-HACD Code into their repo so there could be some changes to the original 2.0. I am now using mostly the pybullet version with default config and am fairly happy with it. It also seems to greatly reduce the amount of subcomponents compared to 4.0 with better looking results. I could create a testing branch of obj2mjcf
that uses the PyBullet version if that's ok for you.
The main code of the pybullet decomposition consists of only these four lines:
import pybullet as p
p.connect(p.DIRECT)
p.vhacd(in_path, out_path, log_path, *args)
p.disconnect()
And all configuration options can be found here on side 59: https://raw.githubusercontent.com/bulletphysics/bullet3/master/docs/pybullet_quickstartguide.pdf
This keeps everything in Python, possibly also more convenient than calling the TestVHACD
executable using a subprocess
The rest of your code should be pretty much identical, since the format of the output file seems to be the same
Regarding Unit tests, I fully agree that they would be very useful for consistent and safe development, they could also help us to better evaluate the quality of different convex decompositions
I could create a testing branch of obj2mjcf that uses the PyBullet version if that's ok for you
That would be absolutely lovely, go for it! I'll merge the branch if we decide it's better :)
Got it working here: https://github.com/nicolas-schreiber/obj2mjcf/tree/feat/pybullet_vhacd I should do a bit more documentation and testing, seems to be working with the XML Generator and the other obj2mjcf options. Still got a lot of log outputs in the console though
Hi @nicolas-schreiber, sorry last week was very busy. I'll check this out sometime this week :) Cheers!
Hey Kevin, I'd definitely be interested in a URDF conversion -- any plans to continue with this?
Hi Kevin,
in my pull request https://github.com/kevinzakka/obj2mjcf/pull/12 you asked about other features I could find useful for this library. I thought about creating kind of a feature-request or issue in here where others can more easily add their comments.
A few thoughts on obj2mjcf I would have are following:
absolute paths: Add the ability to create the Mujoco XML-Files with absolute paths to the actual object files, I found that they usually work better than relative paths, even if one has to recreate the xml files each time you move the files.
Creating URDF-Files: I know obj2mjcf's main purpose is for Mujoco, one could, however, easily add methods to extend it for URDF-files compatible with pybullet for example
Configurable node names in the XML Files: right now with the YCB Object files all the obj-files are called
textured.obj
. obj2mjcf then creates a foldertextured
with antextured.xml
and names the body, model, materials and similar all something withtextured
. This causes problems when using the XML-Files since multiple nodes, for example mesh-nodes, with the same name is not allowed. (well, that would not be a problem if all thetextured.obj
files were named after their YCB Object, but they aren't). So it would be interesting to look into how to make these names configurable. Even more so if one would like multiple instances of one YCB-Object in a running Mujoco SimulationConfigurable Mass, Solimp and Solref for the XML File, I saw that you added the free joint and some default values for physics, but depending on the context one might require specific values here. The mass could then possibly even be applied per subcomponent after the decomposition
Alternative Decompositions: Of course you can not integrate every single Decomposition Library there is into this Library, but I found, in particular with the YCB Objects, a lot of the VHACD Decomposition does not make too much sense. I had better success with using the PyBullet VHACD Version. In terms of metrics/volume error the PyBullet Version might not be much better, but the chosen convex subcomponents make much more sense than the VHACD 4.0. This could be a matter of configuration but I attempted optimizing the VHACD 4.0 configuration to achieve as good results as with the pybullet version but I was unsuccessful
I would be very happy to work with you on these tasks since I now have some experience with the topic, especially with the YCB Objects, and it would be helpful for my experiments too ^^
Edit: Put the Images into a table to declutter