Can't import OBJs that were exported with Apple's Model I/O API (Patch included) #71618

New Issue

Peter Wunder · 2019-11-15T23:56:50+01:00

Peter Wunder commented

2019-11-15 23:56:50 +01:00

System Information
Operating system: Windows 10 1903 (18362.418)
Graphics card: Nvidia GTX 1070

Blender Version
Broken: 2.80

Short description of error
OBJ files that were generated using Apple's Model I/O API trip up Blender's MTL parser, making it impossible to import them.

Exact steps for others to reproduce the error
Download the following files.
They were generated by downloading the publicly accessible .usdz model of the AirPods Pro from Apple's product website and converting it to .obj using this tool I wrote: https://github.com/SamusAranX/USDConverter/blob/master/USDConverter/main.swift

airpods_pro_ios13.obj
airpods_pro_ios13.mtl

Try to import the .obj into Blender as you would with any other .obj file.
Get an error message telling you that the list index is out of range.

I wrote a silly little patch for myself, but re-applying it after every update is getting to be tedious, so I finally created an account here.
My patched import_obj.py file is here: https://gist.github.com/SamusAranX/de1663abe2346fc0dc49791ec9d5205a
I don't have a compehensive test suite, but for me, at least, it has reliably worked without breaking anything else so far.
I'm new to contributing to Blender, so please forgive me if this isn't the proper channel for this.

**System Information** Operating system: Windows 10 1903 (18362.418) Graphics card: Nvidia GTX 1070 **Blender Version** Broken: 2.80 **Short description of error** OBJ files that were generated using Apple's Model I/O API trip up Blender's MTL parser, making it impossible to import them. **Exact steps for others to reproduce the error** Download the following files. They were generated by downloading the publicly accessible .usdz model of the AirPods Pro from Apple's product website and converting it to .obj using this tool I wrote: https://github.com/SamusAranX/USDConverter/blob/master/USDConverter/main.swift [airpods_pro_ios13.obj](https://archive.blender.org/developer/F8096791/airpods_pro_ios13.obj) [airpods_pro_ios13.mtl](https://archive.blender.org/developer/F8096789/airpods_pro_ios13.mtl) Try to import the .obj into Blender as you would with any other .obj file. Get an error message telling you that the list index is out of range. I wrote a silly little patch for myself, but re-applying it after every update is getting to be tedious, so I finally created an account here. My patched import_obj.py file is here: https://gist.github.com/SamusAranX/de1663abe2346fc0dc49791ec9d5205a I don't have a compehensive test suite, but for me, at least, it has reliably worked without breaking anything else so far. I'm new to contributing to Blender, so please forgive me if this isn't the proper channel for this.

Peter Wunder commented

2019-11-15 23:56:50 +01:00

Added subscriber: @GordenFreemant

blender-admin commented

2019-11-15 23:56:50 +01:00

blender/blender-addons#64264 was marked as duplicate of this issue

Stephen Swaney commented

2019-11-16 00:09:09 +01:00

Added subscriber: @StephenSwaney

Stephen Swaney commented

2019-11-16 00:09:09 +01:00

What exactly is the problem?

Also, a diff would be nice.

What exactly is the problem? Also, a diff would be nice.

Peter Wunder commented

2019-11-16 15:14:05 +01:00

This is the problem.
The .mtl files generated by Model I/O don't use Ks x y z, they do Ks scalar with just one number.
I don't know if there's actually any official .mtl standard that this violates, but it'd be great to support this in Blender anyway.

Regarding the diff, is this okay?

diff --git a/import_obj.py b/import_obj.py
index c565bd0..76cb351 100644
--- a/import_obj.py
+++ b/import_obj.py
@@ -324,6 +324,11 @@ def create_materials(filepath, relpath,
                         col = (float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3]))
                         context_mat_wrap.base_color = col
                     elif line_id == b'ks':
+                        # Adds support for MTL files exported by Model I/O
+                        # Those files often just have one number instead of three following the "Ks"
+                        if len(line_split[1:]) < 3:
+                            line_split[1:4] = [line_split[1], line_split[1], line_split[1]]
+
                         spec_colors[:] = [
                             float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3])]
                         context_material_vars.add("specular")

![bug.png](https://archive.blender.org/developer/F8106160/bug.png) This is the problem. The .mtl files generated by Model I/O don't use `Ks x y z`, they do `Ks scalar` with just one number. I don't know if there's actually any official .mtl standard that this violates, but it'd be great to support this in Blender anyway. Regarding the diff, is this okay? ``` diff --git a/import_obj.py b/import_obj.py index c565bd0..76cb351 100644 --- a/import_obj.py +++ b/import_obj.py @@ -324,6 +324,11 @@ def create_materials(filepath, relpath, col = (float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3])) context_mat_wrap.base_color = col elif line_id == b'ks': + # Adds support for MTL files exported by Model I/O + # Those files often just have one number instead of three following the "Ks" + if len(line_split[1:]) < 3: + line_split[1:4] = [line_split[1], line_split[1], line_split[1]] + spec_colors[:] = [ float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3])] context_material_vars.add("specular") ```

Harley Acheson commented

2019-11-16 18:25:18 +01:00

Added subscriber: @Harley

Harley Acheson commented

2019-11-16 18:25:18 +01:00

The report seems a little confusing. It reads like "Apple has files in a new format and when I convert them myself using a particular library the resulting output is not valid"

But it appears to be a much simpler bug.

As far as I can see, MTL material files have material color statements (Ka, Kd, Ks, Tf) that are generally r g b values (0-1) separated by spaces. But the spec does say that the "g and b arguments are optional. If only r is specified, then g, and b are assumed to be equal to r."

Your supplied "mtl" file contains many lines that are a single value like "Ks 0". In this case our import should treat this as if it were "Ks 0 0 0".

If our import is indeed barfing on single values there then that is the bug to be reported, along with this kind of detail and sample files. But if you also want to submit a fix for this problem you'd really need to handle ALL of these color statements (Ka, Kd, Ks, Tf), not just Ks, since all can take single values.

The report seems a little confusing. It reads like "Apple has files in a new format and when I convert them myself using a particular library the resulting output is not valid" But it appears to be a much simpler bug. As far as I can see, [MTL material files ](http://paulbourke.net/dataformats/mtl/) have material color statements (Ka, Kd, Ks, Tf) that are generally r g b values (0-1) separated by spaces. But the spec does say that the "g and b arguments are optional. If only r is specified, then g, and b are assumed to be equal to r." Your supplied "mtl" file contains many lines that are a single value like "Ks 0". In this case our import should treat this as if it were "Ks 0 0 0". If our import is indeed barfing on single values there then **that** is the bug to be reported, along with this kind of detail and sample files. But if you also want to submit a fix for this problem you'd really need to handle ALL of these color statements (Ka, Kd, Ks, Tf), not just Ks, since all can take single values.

Stephen Swaney commented

2019-11-17 01:11:10 +01:00

Thanks, Peter. That is exactly I was looking for.
The fix looks good. It even has comments!

Handling the other K* statements would be nice for completeness, but I have no idea if they are common in MTL files.

Ka - material ambient is multiplied by the texture value
Kd - material diffuse is multiplied by the texture value
Ks - material specular is multiplied by the texture value

Thanks, Peter. That is exactly I was looking for. The fix looks good. It even has comments! Handling the other K* statements would be nice for completeness, but I have no idea if they are common in MTL files. - Ka - material ambient is multiplied by the texture value - Kd - material diffuse is multiplied by the texture value - Ks - material specular is multiplied by the texture value

Bastien Montagne self-assigned this 2019-11-18 10:29:14 +01:00

Peter Wunder commented

2019-11-18 10:37:58 +01:00

I updated the diff for all three of the K* statements.
I took a look at Tf as well, but it's apparently not supported by Blender at all, so there were no changes necessary.

diff --git a/import_obj.py b/import_obj.py
index 7be5b75..7ec1168 100644
--- a/import_obj.py
+++ b/import_obj.py
@@ -317,13 +317,25 @@ def create_materials(filepath, relpath,
                 elif context_material:
                     # we need to make a material to assign properties to it.
                     if line_id == b'ka':
+                        # expand single value to three values
+                        if len(line_split[1:]) < 3:
+                            line_split[1:4] = [line_split[1], line_split[1], line_split[1]]
+
                         refl = (float_func(line_split[1]) + float_func(line_split[2]) + float_func(line_split[3])) / 3.0
                         context_mat_wrap.metallic = refl
                         context_material_vars.add("metallic")
                     elif line_id == b'kd':
+                        # expand single value to three values
+                        if len(line_split[1:]) < 3:
+                            line_split[1:4] = [line_split[1], line_split[1], line_split[1]]
+
                         col = (float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3]))
                         context_mat_wrap.base_color = col
                     elif line_id == b'ks':
+                        # expand single value to three values
+                        if len(line_split[1:]) < 3:
+                            line_split[1:4] = [line_split[1], line_split[1], line_split[1]]
+
                         spec_colors[:] = [
                             float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3])]
                         context_material_vars.add("specular")

I updated the diff for all three of the K* statements. I took a look at Tf as well, but it's apparently not supported by Blender at all, so there were no changes necessary. ``` diff --git a/import_obj.py b/import_obj.py index 7be5b75..7ec1168 100644 --- a/import_obj.py +++ b/import_obj.py @@ -317,13 +317,25 @@ def create_materials(filepath, relpath, elif context_material: # we need to make a material to assign properties to it. if line_id == b'ka': + # expand single value to three values + if len(line_split[1:]) < 3: + line_split[1:4] = [line_split[1], line_split[1], line_split[1]] + refl = (float_func(line_split[1]) + float_func(line_split[2]) + float_func(line_split[3])) / 3.0 context_mat_wrap.metallic = refl context_material_vars.add("metallic") elif line_id == b'kd': + # expand single value to three values + if len(line_split[1:]) < 3: + line_split[1:4] = [line_split[1], line_split[1], line_split[1]] + col = (float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3])) context_mat_wrap.base_color = col elif line_id == b'ks': + # expand single value to three values + if len(line_split[1:]) < 3: + line_split[1:4] = [line_split[1], line_split[1], line_split[1]] + spec_colors[:] = [ float_func(line_split[1]), float_func(line_split[2]), float_func(line_split[3])] context_material_vars.add("specular") ```

blender-admin commented

2019-11-18 10:41:01 +01:00

This issue was referenced by blender/blender-addons@4fd8ee12db

This issue was referenced by blender/blender-addons@4fd8ee12dbaba9fb21dad8f3c2a8718fb69f27a0

Bastien Montagne commented

2019-11-18 10:45:35 +01:00

Changed status from 'Open' to: 'Resolved'

Bastien Montagne closed this issue

2019-11-18 10:45:35 +01:00

Peter Wunder commented

2019-11-18 10:52:12 +01:00

Ooh, that's even better. Thanks for the quick fix!

Philipp Oeser commented

2019-11-18 10:53:51 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2019-11-18 10:53:51 +01:00

That was the same as blender/blender-addons#64264 (OBJ import gives error for Ke / emmisive (single value instead of color)), right?

Bastien Montagne commented

2019-11-18 11:05:55 +01:00

Added subscribers: @filibis, @pipelineTDBadBoy, @HasKha, @Nocturnial, @BrendonMurphy, @DJJudd, @mont29

Bastien Montagne commented

2019-11-18 11:06:08 +01:00

Indeed, thanks for the headup :)

Alex Fleming commented

2019-11-18 12:06:41 +01:00

In #71618#812440, @lichtwerk wrote:
That was the same as blender/blender-addons#64264 (OBJ import gives error for Ke / emmisive (single value instead of color)), right?

It was the same, but the merged fix did not include the Ke (emmisive) parameter. Is it possible to add that in? Even though Ke is not in the original OBJ spec, it is defined in the PBR Extension, and is supported by Blender if defined in the three-tuple format: Ke 0.0 0.0 0.0.

Additional info:
http://exocortex.com/blog/extending_wavefront_mtl_to_support_pbr

This is my first time commenting here, so please let me know if I'm breaking any etiquette rules. :)

> In #71618#812440, @lichtwerk wrote: > That was the same as blender/blender-addons#64264 (OBJ import gives error for Ke / emmisive (single value instead of color)), right? It was the same, but the merged fix did not include the Ke (emmisive) parameter. Is it possible to add that in? Even though Ke is not in the original OBJ spec, it is defined in the PBR Extension, and is supported by Blender if defined in the three-tuple format: Ke 0.0 0.0 0.0. Additional info: http://exocortex.com/blog/extending_wavefront_mtl_to_support_pbr This is my first time commenting here, so please let me know if I'm breaking any etiquette rules. :)

Nocturnial commented

2019-11-18 12:12:08 +01:00

Removed subscriber: @Nocturnial

Bastien Montagne commented

2019-11-18 12:14:14 +01:00

@pipelineTDBadBoy I’d suggest you actually check the commit first, you'll see that it did include fix for Ke as well…

Alex Fleming commented

2019-11-18 13:33:52 +01:00

My apologies, I assumed the pasted code in the thread was the commit. I'm still learning how things work here. Thanks again, this fix is very helpful!!

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Can't import OBJs that were exported with Apple's Model I/O API (Patch included) #71618