-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Collada DAE support #19109
Comments
It's probably worth investing in some documentation along this front. In terms of conserving implementation effort, though, my vote would be instead to (1) support DAEs natively in the first place for visualizers and renderers, and (2) support multi-mesh OBJ files for collision meshes (probably directly, or in the worst case with a pre-processing tool). I think that would be the best investment. Possibly we should support DAEs for collision meshes as well?
Nope. The code snippet you posted is copyleft, but the artwork itself retains its original license. Similar to a compiler, the input and output files being processed retain their distinct license, without any change from blender. See https://www.blender.org/about/license/ at "Your Artwork". |
I've also encountered this OBJ with multiple objects problem several times. I think that's a fairly common scenario when the meshes are generated from CAD files (e.g. a STEP -> OBJ conversion), and indeed when I load such OBJs in Blender I can see they're composed of several different objects, one for each component in the CAD model. In Blender you may be able to get away with merging all the objects together before exporting to OBJ. |
Oh, great news about the license! Re: merging the geometries; the output from the blender conversion worked (it loaded as a single object) without any additional modifications required. |
Just came across this issue, wanted to point out there's some successful work converting More specifically on the format_model_and_generate_manifest.py file. I kinda remember there's some issues to take into account when doing this like assimp/assimp#849. Maybe the code there could be extracted in favor of a |
@SeanCurtis-TRI I'd like to propose that https://drake.mit.edu/doxygen_cxx/group__geometry__file__formats.html not only list the formats we do support, but also specifically nack the commonly-requested formats that we don't support. So it would gain a section header for DAE that would say "not supported for any role", with a hyperlink to this issue. WDYT? (Similarly for STL, but linking to a different issue.) |
As I refreshed myself on this topic, I collected some thoughts regarding the current state of affiars:
re: updating the geometry file document
|
"nack" is "negative ack".
I didn't say everything. I said commonly-requested formats. (It sounds like you agree, in any case.) |
To revisit the big picture, our call to action here is either: (1) When given a DAE mesh, throw an error with a hyperlink to a troubleshooting guide that convincingly explains how to convert the model file to use a different supported file format -- either OBJ or glTF. Maybe we provide a small Python program that helps, using either blender or pyassimp. (2) Actually parse and support the DAE meshes, for all geometry endpoints. (This means Meshcat, Meldis, all RenderEngines, implicit inertia calculations, etc.) I think the technical approach here would be to add Obviously (2) is better if we can swing it, but I'm not sure how much work it would end up being. |
What about something in between: (1.5) We provide a python script like I think this would be dramatically better for users. Especially when people are using the AddRemote workflow, and trying to quickly pull in resources from other repositories; we'd like to make it easy for them to just run one thing and have all the changes on disk. |
Yes, that was basically the "Maybe we provide a small Python program that helps, using either blender or pyassimp" trailer on option 1. I'm happy to assign it number 1.5 so we talk about it concisely. If we have such a program that converts just one mesh, teaching it to glob / recurse for all meshes (and perl-pie the citation in other xml files) is trivial after that. The only difficult part is converting any one mesh in the first place, given the giant number of traps that textured mesh-conversion can fall into. My gestalt of the issue traffic so far is that maybe blender (with good import / export options selected) is the only tool that can convert without making mistakes. I guess we might already have a bpy script above, that does the conversion correctly? So maybe the only work for option 1.5 is to rework that script into a supported tool, and mention it from the RuntimeException when the user tried to load a DAE into Drake.
nit: MJCF doesn't allow DAE anyway, so we don't necessarily need to touch that part here. For STL, it's relevant but in #19408, probably just loading STL directly is super simple so we hopefully won't need conversion. |
Let me toss out another option, let's call it Option 3:
I anticipate that most of the DAE in the wild is I don't love having a heterogeneous support matrix for a mesh format, but it might be the kindest option for real users. |
Original title: Provide tools to help convert Collada DAE to Wavefront OBJ
Related to #2941, #14436, and #18844.
Request: We now have stl2obj. I think we should provide something similar for dae. Or at least publish our recommended workflow.
This is most relevant for visual geometries, because the primary difficulties were in preserving the colors/textures during conversion. Meshcat actually supports DAE directly. But Drake's simulated cameras do not support dae, and currently perform badly (#19055) when the visual geometry is specified as a dae asset.
I'll document here my experience in converting this file, which was more challenging than it should have been.
Approach 1: Meshlab.
Result: Meshlab failed to load the colors; unsuprisingly the exported obj was missing the colors, too.
Approach 2: Assimp.
Usage:
assimp export daefile objfile
Result: Drake doesn't like that the exported obj file has multiple objects
Approach 3: Trimesh
Usage: I wrote this simple script:
Result: Drake doesn't like that the exported obj file has multiple objects
Approach 4: Blender
Usage: I wrote this simple script:
Result: That worked! The only drawback is that the generated asset is now infected with GPL.
The text was updated successfully, but these errors were encountered: