Hello, everybody!
I have run into a pesky issue I am not sure how to battle. I have a database of hundreds of models in OBJ format I have to load and render automatically. I made a script that works wonders.
The issue is that the OBJ models get loaded, but the materials are messed up.
The model should look like this:
As far as I investigated, this is caused by various materials being in the same polygon group, and Blender messing with their priorities.
Being this a database, I can’t go one by one trying to solve this issue. Anyone has any clue on how I can solve this issue? Is there any more in-depth OBJ importer we could use instead of the one that comes with blender?
Here is the obj, in case anyone wants to try it.models.rar (345.2 KB)
I took a closer look at your problem and your model and can confirm that it happens even in blender 2.92
.
The most promising feature of your obj is, that (nearly?) every face is dublcated, thus defined as front and as back face as well:
# Line 23318:
f 2087//862 2185//862 1985//862
f 1985//861 2185//861 2087//861
# line 23862:
f 2087//862 2277//862 2185//862
f 2185//861 2277//861 2087//861
(lthere might be earlier examples, I just happen to search for “2185//”)
Don’t know if thats the cause but might be worth investigating:
- are there faces which appear even 4 times? (perhaps with different point indices?)
- Perhaps you can write a script, collapsing the pairs.
- or find a bug in //scripts/addons/io_scene_obj/import_obj.py.
Anyway I think even if that’s the reason that would be super nice bug to report at https://developer.blender.org/ esp. as it it so easy reproducable provided one has your asset.
I do not have another addon. you can try converting it into other compatible formats before importing tho.
Here some things I tested as well:
- loaded with Meshlab.exe.: looks fine at first glance, but from certain views there are glitches as well.
if I select “backface culling” they disapear!!
→ strong hint that there are overlayed faces!
- there are [l]ines-statements in your obj as well, but these are imported correctly
- replaced all [g]roup statements with [o]bjects . > no improvement
I doubt that the [g]roup statements or the mutliple materials are the reason. these are normal cases for obj and for blender and (at first glance) handled correctly.
Thanks for all the info. I already sent a bug report to Blender, but they told me they can’t reproduce the bug in 2.92
I will keep this updated in case I found anything new.
1 Like
can you post a link to the bug report? Do they have your obj?
Anyway, I still think there is something fishy going on in your obj. Esp as I see different colored faces in meshlab as well. → I still think there are even more overlaying surfaces (the example above are only from the same obj-group.
Here it is:
https://developer.blender.org/T88589
Yes, they have the obj. They have loaded it successfully.
I was finally able to generate an obj, that can be imported into blender:
model_unique_groups.obj (1.8 MB)
Has to be imported with “geometry > split groups” tho!
The trick is to name the obj-[g]roups uniquely. together with the mentioned import settings blender is able to separate the different objects.
And that’s what causing the problem: the faces are indeed defined dublicated (front and back) with different matierials. the main corpus is for example defined in meshgroup 215 and 216. and already the first faces are the identical!
here is the python sript to generate the uniquely named groups:
counter = 0
with open("model_normalized.obj", "r") as f_in:
with open("model_unique_groups.obj", "w") as f_out:
for line in f_in:
if line.startswith("g "):
line = line.strip() + "." + str(counter) + "\n"
counter += 1
f_out.write(line)
(this is of course an blender independent python script just processing ascii data.)
Hope that helps!
I will add a commentary to the bug report, as well.
“jetzt habe ich mir aber ein Bienchen verdient”
We have tried the code and seems to work perfectly! Thanks!
