gltfpack: Enhance .obj parsing by preserving more information #596
Conversation
Also when the material is using different texture paths for diffuse and alpha, warn about the mismatch - we can't represent a separate alpha mask via standard glTF materials.
|
Looks like some .obj exporters use objects and some use groups to split the data :-/ this doesn't affect correctness of conversion but does mean this PR won't handle some input scenes depending on the exporter that was used. Objects are more popular in my test data set but groups still occur fairly frequently. For now it's probably fine, as groups are more equivalent to meshes but gltfpack doesn't keep mesh names anyway... |
These will be preserved in the output glTF file, and using -km option will disable merging named materials. Also define _CRT_NONSTDC_NO_WARNINGS to avoid MSVC warnings for strdup.
We now assign a node to each individual object in .obj file; this allows us to preserve object names. When -kn is not specified, gltfpack will merge the meshes with the same materials anyway so the result should not change, but with -kn the nodes will be preserved in the output file.
zeux
force-pushed
the
gltf-objext
branch
2 times, most recently
from
7f33cc7 to
39e1476
Compare
This change splits nodes and materials parsing and keeps mesh group parsing loop so that the code looks more similar to what we used to have when we just had one group. That will also make it easier to ensure the relationships between objects and nodes stay 1-1.
|
The textures in .obj are typically using the spec-gloss model. They could be emitted via KHR_materials_pbrSpecularGlossiness, however this extension is deprecated in favor of KHR_materials_specular I think - either way this requires a fair amount of special cased work which I don't think makes sense to do absent specific important use cases. Similarly I don't want to just tackle the roughness factor without considering the rest, so I'd rather keep the model simple (just a color + texture) for now. I would not be surprised if obj2gltf converts textures from spec+gloss to metal+roughness inferring the individual pixel values - this is very much out of scope of gltfpack. Inferring double-sidedness based on transparency is easy but kinda specific... I'm not exactly sure what the motivation there is. |
|
The emissiveTexture and normalTexture here does not seems to be part of the spec-gloss model, could this be added? |
|
Yeah these should work without issues I believe as they fit as is within any material model even without the use of extensions, I'll add them. |
|
Hmm, actually, obj2gltf seems to assume map_bump in .mtl files refers to normal maps, but Sponza example on https://casual-effects.com/data/ at least assumes map_bump refers to actual bump maps (containing height data). Unsure if obj2gltf is correct here, or what the spec says if any. |
|
Oh boy :-/ https://paulbourke.net/dataformats/mtl/ says:
... which is consistent with glTF spec's treatment of baseColorFactor & baseColorTexture. But of course, some files I am looking at have Kd at 0 and map_Kd set to a texture, so the effect of this change is that they render as black. obj2gltf ignores Kd when map_Kd is present which looks like the correct course of action in absence of an official spec. |
Some .mtl files contain backslash-delimited paths; backslash is not valid as a delimiter in URIs and paths like this can't be opened on non-Windows platforms when textures are embedded or compressed.
It's not fully clear what the expected behavior is when both Kd and map_Kd are specified; some online documentation claims that they are multiplied, but some .obj files in the wild have map_Kd and Kd=0, so to stay safe we now only apply Kd/d when there's no map with the same name.
|
Given the amount of irregularities in .mtl I think this is a reasonable stopping point. Future additions will need to be evaluated on a case-by-case basis. map_bump has the aforementioned ambiguity that makes me think that absent a thorough analysis of whether one variant is common place it's not a good idea, and I wasn't able to find reasonable examples for emissive so for now both are not implemented. |
When parsing .obj, gltfpack now:
Before merging:
Fixes #594
Fixes #595