Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Discussion #14

Open
nicolas-schreiber opened this issue Sep 26, 2022 · 7 comments
Open

Feature Discussion #14

nicolas-schreiber opened this issue Sep 26, 2022 · 7 comments
Labels
enhancement New feature or request

Comments

@nicolas-schreiber
Copy link
Contributor

nicolas-schreiber commented Sep 26, 2022

Hi Kevin,

in my pull request #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 folder textured with an textured.xml and names the body, model, materials and similar all something with textured. 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 the textured.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 Simulation

  • Configurable 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

Just some examples here:
First the original Mustard Bottle, then PyBullet VHACD with default parameters, and VHACD 4.0 with default parameters:

Original Pybullet VHACD VHACD 4.0
image image image

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

@nicolas-schreiber
Copy link
Contributor Author

nicolas-schreiber commented Sep 26, 2022

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

@kevinzakka kevinzakka added the enhancement New feature or request label Sep 26, 2022
@kevinzakka kevinzakka pinned this issue Sep 26, 2022
@kevinzakka
Copy link
Owner

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.

@nicolas-schreiber
Copy link
Contributor Author

nicolas-schreiber commented Sep 26, 2022

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

@kevinzakka
Copy link
Owner

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 :)

@nicolas-schreiber
Copy link
Contributor Author

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

@kevinzakka
Copy link
Owner

Hi @nicolas-schreiber, sorry last week was very busy. I'll check this out sometime this week :) Cheers!

@danielpmorton
Copy link

Hey Kevin, I'd definitely be interested in a URDF conversion -- any plans to continue with this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants