bugs in io_scene_obj addons #46165

New Issue

Lee June · 2015-09-19T13:55:40+02:00

Lee June commented

2015-09-19 13:55:40 +02:00

Broken for 2.74, 2.75 and 2.76

When I try to import an obj file, which is said to be exported by zmodeler, I get this
[quote]

File "E:\greensoft\3d\blender-2.74-windows64\2.74\scripts\addons\io_scene_obj\

import_obj.py", line 796, in

  vec[:] = [float_func(v) for v in line_split[1:]]

ValueError: could not convert string to float: b'1.#QNAN'
[/quote]

Then I checked the obj file and found something like following
[quote]
vn 1.#QNAN -1.#IND -1.#IND
vn 0.970273 0.199445 -0.137085
vn 1.#QNAN -1.#IND -1.#IND
vn 0.894082 0.387011 -0.225478
vn 1.#QNAN -1.#IND -1.#IND
[/quote]

So I changed 2 lines in "def get_float_func(filepath):". Because '1.' is placed before 'QNAN', I think the change can be done by simple replace
[quote please remember this line appears twice]
return float
[/quote]
with
[quote]
return lambda f: float(f.upper().replace(b'.#QNAN', b'').replace(b'.#IND', b'').replace(b'.#NAN', b''))
[/quote]
But this should be checked wether it is a univerisal way to deal with all 'QNAN' and 'IND'.

And I when I checked scripts\addons\io_scene_obj\import_obj.py in blender 2.74/2.75/2.76, I found that all of them share the same 'get_float_func' function. So the fix will be possible for 2.74/2.75/2.76

Thanks.

Broken for 2.74, 2.75 and 2.76 When I try to import an obj file, which is said to be exported by zmodeler, I get this [quote] ``` File "E:\greensoft\3d\blender-2.74-windows64\2.74\scripts\addons\io_scene_obj\ ``` import_obj.py", line 796, in <listcomp> ``` vec[:] = [float_func(v) for v in line_split[1:]] ``` ValueError: could not convert string to float: b'1.#QNAN' [/quote] Then I checked the obj file and found something like following [quote] vn 1.#QNAN -1.#IND -1.#IND vn 0.970273 0.199445 -0.137085 vn 1.#QNAN -1.#IND -1.#IND vn 0.894082 0.387011 -0.225478 vn 1.#QNAN -1.#IND -1.#IND [/quote] So I changed 2 lines in "def get_float_func(filepath):". Because '1.' is placed before 'QNAN', I think the change can be done by simple replace [quote please remember this line appears twice] return float [/quote] with [quote] return lambda f: float(f.upper().replace(b'.#QNAN', b'').replace(b'.#IND', b'').replace(b'.#NAN', b'')) [/quote] But this should be checked wether it is a univerisal way to deal with all 'QNAN' and 'IND'. And I when I checked scripts\addons\io_scene_obj\import_obj.py in blender 2.74/2.75/2.76, I found that all of them share the same 'get_float_func' function. So the fix will be possible for 2.74/2.75/2.76 Thanks.

Lee June commented

2015-09-19 13:55:40 +02:00

Changed status to: 'Open'

Lee June commented

2015-09-19 13:55:40 +02:00

Added subscriber: @retsyo

blender-admin commented

2015-09-19 13:55:40 +02:00

blender/blender#55265 was marked as duplicate of this issue

blender-admin commented

2015-09-19 13:55:40 +02:00

#54403 was marked as duplicate of this issue

Lee June commented

2015-09-19 13:58:36 +02:00

how about ignore the normal if the value is invalid, and do a 'calculate the normal' after importation?

Bastien Montagne commented

2015-09-19 14:30:24 +02:00

Added subscriber: @mont29

Bastien Montagne self-assigned this 2015-09-19 14:30:24 +02:00

Bastien Montagne commented

2015-09-19 14:30:25 +02:00

Yeah… never saw such thing in an .OBJ file, and pretty sure this is not covered by the format definition at all. In fact, this heavily looks like a bug in zmodeler exporter to me. Anyway, will add some more safety checks here…

Bastien Montagne commented

2015-09-19 15:28:07 +02:00

Added subscriber: @ideasman42

Bastien Montagne commented

2015-09-19 15:28:07 +02:00

OK, have a patch which basically uses try/except around float 'parsing' func… Makes parsing of the file about 4-5% slower though (total import about 2-3% slower).

Would like to summon @ideasman42 here though, I really do not feel like adding that extra stuff for what is quite obviously a broken file - we cannot support all stupidity of external app world in Blender, and think we can expect a reasonable level of format-correctness for our importers?

Note that those 1.#QNAN, -1.#IND etc. are windows-version of nan and inf, that is, invalid of infinite numbers. Think those should never ever be exported in an .obj!

OK, have a patch which basically uses try/except around float 'parsing' func… Makes parsing of the file about 4-5% slower though (total import about 2-3% slower). Would like to summon @ideasman42 here though, I really do not feel like adding that extra stuff for what is quite obviously a broken file - we cannot support all stupidity of external app world in Blender, and think we can expect a reasonable level of format-correctness for our importers? Note that those `1.#QNAN`, `-1.#IND` etc. are windows-version of `nan` and `inf`, that is, invalid of infinite numbers. Think those should **never ever** be exported in an .obj!

Bastien Montagne commented

2015-09-20 11:17:46 +02:00

Changed status from 'Open' to: 'Archived'

Bastien Montagne closed this issue

2015-09-20 11:17:46 +02:00

Bastien Montagne commented

2015-09-20 11:17:47 +02:00

So, talked with Campbell on IRC, we agree that we shall not try to support broken .obj (if we start there, we'll never end), bug is in the app that is exporting such files, not in Blender anyway.