[ycb] Convert meshes to gltf

[jwnimmer-tri]

Towards #44.

Example command line:

bazel run //models/tools:obj2gltf -- \
  -s --inputUpAxis=Z \
  -i $(pwd)/../models/ycb/meshes/005_tomato_soup_can_textured.obj \
  -o $(pwd)/../models/ycb/meshes/005_tomato_soup_can_textured.gltf

bazel run //models/tools:gltf_add_ktx2 -- \
  --overwrite --input ../models/ycb/meshes/005_*.gltf

---

This change is 

[jwnimmer-tri]

+@SeanCurtis-TRI for both reviews, please.

I figure we'll do convert and review one directory to check the process, then my next PR can be converting many directories at once.

[SeanCurtis-TRI]

Everything seems correct (if not optimal).

Reviewed 24 of 31 files at r1, 13 of 13 files at r2, all commit messages.
Reviewable status: 3 unresolved discussions, platform LGTM from [seancurtis-tri] (waiting on @jwnimmer-tri)

a discussion (no related file):
Some food for thought:

1. Importing the new .glTF gives a slightly different appearance in blender than the original .obj files. Basically, the specularity seems to be smeared (there's one specular setting that blender arbitrarily sets differently when importing glTF differently from obj).
2. Importing and re-exporting from blender will not be idempotent:
   • the "extensionsUsed" stuff gets stripped.
   • However, the file is much smaller as blender relies on the glTF semantics more directly and only outputs things that meaningfully deviate from glTF default values.

Perhaps some note about updating these models via blender should incorporate some warnings? For example, it's easy to imagine we'd want to upgrade these in the future with more than just diffuse color texture maps, we'd like some guidance?

---

a discussion (no related file):
I hadn't been aware that the default orientation of the .obj files were insane in the first place. But I've confirmed that the glTF files preserve the insanity.

---

---

ycb/meshes/003_cracker_box_textured.gltf line 124 at r2 (raw file):

		}
	],
	"materials":[

BTW This workflow introduces a number of fields in the materials that are, in fact, the default values: baseColorFactor, roughnessFactor, emissiveFactor and alphaMode. I noticed these particularly because I've been playing with materials of late. The trend continues in other elements (e.g. meshes.primitives.mode and bounding boxes for the set of normals and uvs).

Are we worried at all about the bloat?

[jwnimmer-tri]

Reviewable status: 2 unresolved discussions, platform LGTM from [seancurtis-tri] (waiting on @SeanCurtis-TRI)

a discussion (no related file):

Basically, the specularity seems to be smeared (there's one specular setting that blender arbitrarily sets differently when importing glTF differently from obj).

If anything, that would be a bug report / feature request in drake-blender, I think? To the extent that assumed defaults differ, that sound like a geometry-consumer problem, not an asset problem? Or is there something we can do in these asset file to help steer the geometry consumers to be more consistent?

Anyway, I would be more interested in what Meshcat and RenderVtk do with the defaults, less so Blender.

... the "extensionsUsed" stuff gets stripped ...

For this change specifically, I am not worried. Anything import/export in Blender will strip that (as well it should), so any artist/update process 100% of the time will be "export from blender, then run gltf_add_ktx2" by rote. I don't think we need to / should document any of that in this PR. (Or the artist might start from the *.blend file anyway, instead of re-importing.)

---

---

ycb/meshes/003_cracker_box_textured.gltf line 124 at r2 (raw file):

Are we worried at all about the bloat?

Bloat, no. Confusion induced by repeating unnecessary values, yes.

Is anything here enough of a confusion / maintainability problem to deserve attention?

If yes, we could enhance gltf_add_ktx2 to make the necessary corrections (possibly an a follow-up PR).

[SeanCurtis-TRI]

Reviewable status: complete! all discussions resolved, platform LGTM from [seancurtis-tri] (waiting on @jwnimmer-tri)

a discussion (no related file):

Or is there something we can do in these asset file to help steer the geometry consumers to be more consistent?

Not on the asset side. And, to emphasize, the distinction is subtle. I don't think anyone would notice unless they placed them side by side.

Generally, I'm content with things as they are. But I felt it worth pointing things out.

---

---

ycb/meshes/003_cracker_box_textured.gltf line 124 at r2 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

Are we worried at all about the bloat?

Bloat, no. Confusion induced by repeating unnecessary values, yes.

Is anything here enough of a confusion / maintainability problem to deserve attention?

If yes, we could enhance gltf_add_ktx2 to make the necessary corrections (possibly an a follow-up PR).

"Confusion" is a problematic word for me. I'm not sure what might confuse others.

I'm all in favor of deferring action until we see that it causes problems. The files are correct as is, and I don't anticipate many people will crack them open and think, "Oh! I should make sure I added min/max values for my texture coordinates", or "What the hell is my mesh's mode?" So, we can let it ride.

[jwnimmer-tri]

Reviewable status: complete! all discussions resolved, platform LGTM from [seancurtis-tri] (waiting on @jwnimmer-tri)

a discussion (no related file):

Previously, SeanCurtis-TRI (Sean Curtis) wrote…

Or is there something we can do in these asset file to help steer the geometry consumers to be more consistent?

Not on the asset side. And, to emphasize, the distinction is subtle. I don't think anyone would notice unless they placed them side by side.

Generally, I'm content with things as they are. But I felt it worth pointing things out.

Yes, I appreciate hearing your thoughts. It sounds like we're on the same page here.

---

[jwnimmer-tri]

Urgh, my mistake in not opening the Drake twin PR sooner (RobotLocomotion/drake#21227). I thought "surely this will be fine", but there's some extra fixing required in Drake. I'll work on that now.