Blender ACES unable to import OBJ

[Endertainer]

So I have Blender 2.93 with ACES 1.2 installed. And whenever I tried to import my Mineways OBJ I got this error message.

Though, when I open a blender file with an already imported file it does work. And even the prep material seems to work (But the texture color space needs some adjustment).

And with that, I was wondering if the Addon could support ACES. Also, why am I using ACES? Well, I just found it interesting.

[StandingPadAnimations]

I don't think MCprep has ACES support(though it would be interesting)

[Endertainer]

I don't think MCprep has ACES support(though it would be interesting)

Well, I do found a workaround. You need to import and prep the scene in a separate version of Blender, the one without ACES. When the file is then open in ACES, it works (Though, I haven't done much to see if things are broken, but from what I can tell it does work nicely). Now it's just the matter of adjusting the texture color space.

[TheDuckCow]

Thanks for sharing this, and especially the screenshot, very helpful.

It unfortunately looks like an inherent issue in the OBJ importer. Let me know but I'm guessing you'd get the same error if you went to File > Import > Import obj. Sadly that's not MCprep code, MCprep just uses blender's built in OBJ importer, so your workaround in the meantime would be your best option. Does this also happen in all versions of blender (maybe try e.g. 2.92)? If it's consistent across, you may benefit all users of ACES by submitting a bug to blender itself. I can help you prepare that report if you do come to this conclusion.

[StandingPadAnimations]

ACES isn't really built into Blender itself. It's installed the same way Filmic used to be installed

[Endertainer]

Thanks for sharing this, and especially the screenshot, very helpful.

It unfortunately looks like an inherent issue in the OBJ importer. Let me know but I'm guessing you'd get the same error if you went to File > Import > Import obj. Sadly that's not MCprep code, MCprep just uses blender's built in OBJ importer, so your workaround in the meantime would be your best option. Does this also happen in all versions of blender (maybe try e.g. 2.92)? If it's consistent across, you may benefit all users of ACES by submitting a bug to blender itself. I can help you prepare that report if you do come to this conclusion.

Ok. So I tested it on Blender 2.83 and 2.92, and both have ACES. And during the test, both of them failed to import OBJ files either from MCprep or Blender's importer. Here's the MCprep error from 2.92:

I also tried importing models from a normal version of Blender 2.92 and it works just as expected. It seems like this issue only occurs in versions with ACES installed.

ACES isn't really built into Blender itself. It's installed the same way Filmic used to be installed

And yes, ACES isn't installed to Blender by default. It's something that needs to be installed manually, and it's not an addon. For how to installed ACES I followed this tutorial by Mario Cazares. Who knows if Blender would implement ACES into the main version.

[StandingPadAnimations]

Perhaps the obj importer can't handle ACES

[StandingPadAnimations]

Trying ACES out myself, it seems that it's actually due to the default color space option in config.ocino. I know it's one of these options:

roles:
  color_picking: Output - Rec.709
  color_timing: ACES - ACEScc
  compositing_linear: ACES - ACEScg
  compositing_log: Input - ADX - ADX10
  data: Utility - Raw
  default: ACES - ACES2065-1
  matte_paint: Utility - sRGB - Texture
  reference: Utility - Raw
  rendering: ACES - ACEScg
  scene_linear: ACES - ACEScg
  texture_paint: ACES - ACEScc

But I'm not sure which one. Perhaps you can change then one by one to the correct color space(ACES comes with it's own sRGB color space) and see which works. Just keep in mind that you have to reimport after changing an option

[StandingPadAnimations]

I'll mark this as user troubleshoot for now since it's more of a config thing, but keep the known issue label just in case

[StandingPadAnimations]

config.ocino can be found in the color management folder

[TheDuckCow]

Jumping back here and adding this sample of an error report from a user using ACES on Windows, Blender 3.1.2, from error report -N1pWg-42dKol6oTYDNt:

827, in wrapper
res = function(self, context)
File "<addon_path>/prep.py", line 513, in execute
mat, err = self.generate_base_material(
File "<addon_path>/prep.py", line 570, in generate_base_material
generate.set_cycles_texture(image, mat, self.useExtraMaps)
File "<addon_path>/generate.py", line 499, in set_cycles_texture
util.apply_colorspace(node, 'Non-Color')
File "<addon_path>/util.py", line 59, in apply_colorspace
node.image.colorspace_settings.name = 'Non-Colour Data'
TypeError: bpy_struct: item.attr = val: enum "Non-Colour Data" not found in ('ACES - ACES2065-1', 'ACES - ACEScc', 'ACES - ACEScct', 'ACES - ACEScg', 'Input - ADX - ADX10', 'Output - sRGB', 'Role - matte_paint', 'Role - scene_linear', 'Role - texture_paint', 'role_data', 'role_matte_paint', 'Utility - Linear - sRGB', 'Utility - Raw', 'Utility - sRGB - Texture')

It might be interesting to see if the only change to support ACES (at least in a basic level) would be to attempt one of these colorspaces (I'd have to look up which one would be correct though).

[StandingPadAnimations]

I know I'm posting on a dead issue, but I've also noticed this error for AgX. I believe it has something to do with the OBJ importer itself

[StandingPadAnimations]

I finally figured out the source of the issue.

It turns out the Python version of the OBJ importer has this issue, but the C++ version doesn't. While it was originally assumed we were using the C++ version, it seems to not be the case.

I'll self assign this task to myself

[StandingPadAnimations]

I got it working, we had to switch

bpy.ops.import_scene.obj(
				filepath=self.filepath, use_split_groups=True)

to

bpy.ops.wm.obj_import(
				filepath=self.filepath)

This does mean no split groups, but we could emulate that behavior by splitting the OBJ afterwards

[StandingPadAnimations]

I've opened a pull request for this feature

[zNightlord]

I got it working, we had to switch

bpy.ops.import_scene.obj(
				filepath=self.filepath, use_split_groups=True)

to

bpy.ops.wm.obj_import(
				filepath=self.filepath)

This does mean no split groups, but we could emulate that behavior by splitting the OBJ afterwards

For this, it is in 3.5
https://wiki.blender.org/wiki/Reference/Release_Notes/3.5/Pipeline_Assets_IO

[StandingPadAnimations]

Perfect. That does mean people using 3.1 - 3.4 will lose some functionality, but 3.5 brings it back

[StandingPadAnimations]

I think I'll also look into adding support for this in Blender's Python importer, but no gurantees

[StandingPadAnimations]

It seems to be simple enough, check if the colorspace options exist, and if they don't continue on

[StandingPadAnimations]

Ok looking further in the issue, it'a actually the MTL files to blame.

As mentioned here ampas/aces-dev#117, the MTL file defines some texture stuff like alpha for Blender to interpret, which seem to be the source of the issue (as Blender attempts to assign colorspaces to these textures).

The C++ importer doesn't seem interpret these definitions (at least not in the same way as the old Python importer), which might be an oversight on the Blender side. In any case, we now know where the issue lies.

[StandingPadAnimations]

Sure enough, the MTL (this is from an OBJ I generated with Mineways for the new header detection feature) defines like like this:

map_d ATLAS-Alpha.png

Now that we know what to look for, I think what we could do is the following

Step 1. Check if the user is using a non-standard colorspace
Step 2a. If no, goto Step 3
Step 2b. If yes, comment the lines of the MTL starting with map_d
Step 3. Import OBJ
Step 4. If Step 2b was done, then we uncomment the lines

This however means no alpha textures when imported, but I believe prep materials should aliviate that

[StandingPadAnimations]

Anyway, I'll hopefullt get this done by the end of the day

[StandingPadAnimations]

Finally pushed the changes, more info on it can be found here: #373 (comment)

Tldr: we change the contents of the MTL file just enough for the OBJ importer to not care about colorspaces