Add TRI Homecart mesh files #18
Conversation
|
The Even once we've adjusted our distribution channels to tolerate larger files (e.g., YCB) whether by fetching them at runtime or otherwise, larger files still come come with costs -- more CI time downloading on every build, slower git clones (it's in this repo's git history forever), slower loading when viewing in MeshCat, etc. If there is a good reason we need a high-resolution visual mesh, that information should appear in one of the PR description(s) to provide context. I've also posed in Anzu asking about the license file for the Wood texture file. I don't think we own it. |
|
I am not certain but I think the wood texture file came from Cody based on photos I sent him of the actual cutting board surface, but it may also be that he or someone found a matching texture file based on the photos. |
There was a problem hiding this comment.
I believe the texture file came from here: https://ambientcg.com/view?id=Wood049
All ambientCG assets are provided under the
Creative Commons CC0 1.0 Universal License.
This applies to the downloadable asset files and the "preview spheres" (material preview renders) shown on the site.
and the textures are labeled as being public domain. If size is an issue we can just down sample it and push a smaller resolution version of the texture file.
It's not required, but it would be polite to give credit via:
Created using <asset name> from ambientCG.com, licensed under the Creative Commons CC0 1.0 Universal License.
Reviewable status: all discussions resolved, platform LGTM missing
|
That sounds like a good plan for the texture file. The remaining problem is the extreme LOD in the homecart's mesh. |
|
Let me tack a crack at decimating the mesh. If results aren't good I'll pass it off to Cody. |
|
Looking as Russ' screenshot, I would be surprised (but happy!) if decimation worked. My intuition is that we will need to nuke the casters, 80/20 guide channels, through-holes, etc. in order to reach a suitable size. The goal I'd set is the order of ~10x reduction in size. |
In general I agree with your assessment, Jeremy, on the practical methods needed for reducing the homecart base mesh size. However, if we remove the casters, they should be replaced with cylinders or boxes to preserve the true homecart height. |
There was a problem hiding this comment.
512x512 texture
Decimated homecart_baseplate.obj
The holes in the baseplate are a bit mangled, but the overall shape looks reasonable and I got the size down by an order of magnitude.
Reviewable status: all discussions resolved, platform LGTM missing
There was a problem hiding this comment.
Let's see how the above baseplate renders. The corners are perhaps a bit sketchy so manual cleanup may still be the best route forward.
Reviewable status: all discussions resolved, platform LGTM missing
|
FWIW, Cody said he had used a different texture file for the wood (based on photos I sent), not the creative commons one and I think there are a few home-cart models floating around. There may already be a much more decimated version of the one in question here? In any case, I asked Cody about this just to give him a heads up and he does have time to help clean it up if automatic decimation isn't perfect. |
|
I mentioned this to Cody to see if he already had a simpler mesh. Note that his texture file for the cutting board surface is basd on photos I sent him of the actual surface, not the CC woodgrain. This is his response: The most poly dense area was the wheels, which were about 35k each. I just ended up replacing them with a blockier, lower poly version. There's still a bit of clean up and fiddling to be done, but the whole setup is currently at 22,790 tris, it should hopefully stay under 25k and it'll be cleaner than decimating.
|
There was a problem hiding this comment.
This looks great to me. @allisonh-tri -- the last note from Cody says there is more fiddling to do. Can we perhaps coordinate tomorrow so that I can either land it or understand specifically what I should be waiting for? I ultimately need a final decision on all of the files (and licenses) for all of the files in this PR. Thanks!
Btw - @IanTheEngineer -- thanks for your contributions, too.
Reviewable status: all discussions resolved, platform LGTM missing
|
Sure thing! I told Cody to wait until you confirm you want him to continue. I'll ask him if he can finish his changes today. If you'd like he can kick off the PR in Anzu, and/or he can give you the files directly. |
|
my goal is to get the files into this PR. Whatever is easier for Cody to accomplish that (via anzu, on this repo, or direct to me) is fine. thanks! |
In RobotLocomotion/models#18 (homecart_basecart.mtl) I ran into a texture map specification that specified a scale option in the map_Kd line. This defeated the simple regex expression that I had implemented in meschat.cc. meshcat.cc doesn't need to parse these options properly; it only needs to successfully extract the filename so that the file can be shipped over the websocket. I've updated the parsing line according to the mtl specification to ignore options. To reproduce the problem, run meshcat_manual_test with the change to box.obj.mtl but without the fix to meshcat.cc. You will see that the box appears in meshcat without a texture and a warning from meshcat.cc is printed to the console. The change to meshcat.cc resolves the problem.
|
+@rpoyner-tri for platform review, please? |
There was a problem hiding this comment.
From f2f discussion with Russ: -@rpoyner-tri +@ggould-tri 
Reviewed 18 of 32 files at r1, 17 of 17 files at r2, all commit messages.
Reviewable status: 1 unresolved discussion, platform LGTM from [ggould-tri] (waiting on @RussTedrake)
ur3e/LICENSE.TXT line 1 at r2 (raw file):
Per https://github.com/ros-industrial/universal_robot/blob/melodic-devel/ur_description/package.xml
nit: all-caps ".TXT" filename is inconsistent with our practice elsewhere (and confuses reviewable's sorting )
|
Previously, ggould-tri wrote…
Is that accurate? |
There was a problem hiding this comment.
Reviewable status:
complete! all discussions resolved, platform LGTM from [ggould-tri] (waiting on @RussTedrake)
ur3e/LICENSE.TXT line 1 at r2 (raw file):
Previously, jwnimmer-tri (Jeremy Nimmer) wrote…
Is that accurate?
jwnimmer@call-cps:~/jwnimmer-tri/drake$ find . -iname 'license.txt' ./LICENSE.TXT ./doc/pydrake/LICENSE.TXT ./doc/third_party/dracula/LICENSE.txt ./doc/third_party/pylons/LICENSE.txt ./doc/third_party/github-styling/LICENSE.txt ./manipulation/models/jaco_description/LICENSE.TXT ./manipulation/models/iiwa_description/LICENSE.TXT ./manipulation/models/franka_description/LICENSE.TXT ./manipulation/models/allegro_hand_description/LICENSE.TXT jwnimmer@call-cps:~/jwnimmer-tri/models$ find . -iname 'license.txt' ./tri_homecart/LICENSE.TXT ./ycb/meshes/LICENSE.txt ./ur3e/LICENSE.TXT
I meant elsewhere in this same PR. But point take; objection withdrawn.
In RobotLocomotion/models#18 (homecart_basecart.mtl) I ran into a texture map specification that specified a scale option in the map_Kd line. This defeated the simple regex expression that I had implemented in meschat.cc. meshcat.cc doesn't need to parse these options properly; it only needs to successfully extract the filename so that the file can be shipped over the websocket. I've updated the parsing line according to the mtl specification to ignore options. To reproduce the problem, run meshcat_manual_test with the change to box.obj.mtl but without the fix to meshcat.cc. You will see that the box appears in meshcat without a texture and a warning from meshcat.cc is printed to the console. The change to meshcat.cc resolves the problem.
In RobotLocomotion/models#18 (homecart_basecart.mtl) I ran into a texture map specification that specified a scale option in the map_Kd line. This defeated the simple regex expression that I had implemented in meschat.cc. meshcat.cc doesn't need to parse these options properly; it only needs to successfully extract the filename so that the file can be shipped over the websocket. I've updated the parsing line according to the mtl specification to ignore options. To reproduce the problem, run meshcat_manual_test with the change to box.obj.mtl but without the fix to meshcat.cc. You will see that the box appears in meshcat without a texture and a warning from meshcat.cc is printed to the console. The change to meshcat.cc resolves the problem.
Relates to RobotLocomotion/drake#17387.
This change is