Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented MTL conversion for ACES and whatnot #383

Merged

Conversation

StandingPadAnimations
Copy link
Collaborator

ACES and other colorspaces like it have issues when it comes to OBJ importing, so we need to convert the MTL so that Blender doesn't throw an exception when importing.

This comments out lines starting map_d from the MTL. The operation itself shouldn't affect MCprep since we don't deal with it anyway.

ACES and other colorspaces like it have issues when it comes to OBJ
importing, so we need to convert the MTL so that Blender doesn't throw
an exception when importing.

This comments out lines starting `map_d` from the MTL. The operation
itself shouldn't affect MCprep since we don't deal with it anyway.

Of course the backup needs to be fixed (right now it will always back
up the file, so we could add a timestamp to the edited MTL that MCprep
then checks for and compares before attempting to convert)
Copy link
Member

@TheDuckCow TheDuckCow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change looking good, I'll want to live test once you make the requested change below to push it into a function.

Always a good idea to make small functions that do very specific things, and avoid nesting (blocks, try/catch etcs) as much as possible. But this will be a very welcome change (also thanks for splitting up these two PRs, feels much cleaner this way).

MCprep_addon/world_tools.py Outdated Show resolved Hide resolved
@StandingPadAnimations
Copy link
Collaborator Author

There is one small thing I need to implement as well: caching

Right now this branch will always copy the MTL to the backup folder, but it doesn't convert the MTL back to its original form. I'm thinking of adding a small "header" at the end of the edited MTL that says the following:

# This section was added by MCprep's MTL conversion script in order to allow importing without an
# error being thrown
# <timestamp of copied MTL>

The MTL conversion code was added to a seperate function so that we
don't have to deal wtih 2 try-except blocks in the same place. It also
gives more flexability in how we approch conversion
Beyond just not having to perform a useless operation (useful on larger
MTLs), it also prevents edited MTLs from being copied into the
ORIGINAL_MTLS directory, which is important as it keeps the original MTL
intact.

This is done by simply adding a header at the end of the MTL file whose
existance is then checked. The reason we do it at the end of the file is
because:
- It's easier
- It's less likely to interfere with whatever header a world exporter
  may create in the MTL file

At this point, I think it's safe to say that we're ready for review.
@StandingPadAnimations
Copy link
Collaborator Author

Just adding this for tommorow me:

  • Add MTL recovering (since we can reverse the operations MCprep does to convert MTLs)
  • Simplify header checking (inatead of list comprehension, we should just check the last 3 lines since MCprep will always write the header as the last part of the MTL)

Copy link
Member

@TheDuckCow TheDuckCow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for all the nit picks, but it's getting there.

As I said, let me know if you have any interest in making the test *function, otherwise I can do it.

@@ -87,6 +87,64 @@ def detect_world_exporter(filepath):
return 'jmc2obj'


def convert_mtl(filepath):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more thing - can you upload an example of your intended modified, and the corresponding original file?

I'd like to make a unit test that validates this happens, so we can know this continues to work in the future (I'm happy to do that work, unless you wanted to take a stab at it; I'd be saving both files to the test directory and using the original to then bytewise compare the other in a temp space)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MTL conversion simply does the following:

  • Comment out lines that begin with map_d
  • Add a header at the end

Here's an original MTL and the edited MTL

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a bunch. See the followup PR I've created which includes these test files:
#388 (diff will be reduced to mostly just the test file once this PR 383 is merged)

MCprep_addon/world_tools.py Outdated Show resolved Hide resolved
MCprep_addon/world_tools.py Outdated Show resolved Hide resolved
MCprep_addon/world_tools.py Outdated Show resolved Hide resolved
MCprep_addon/world_tools.py Outdated Show resolved Hide resolved
MCprep_addon/world_tools.py Outdated Show resolved Hide resolved
MCprep_addon/world_tools.py Outdated Show resolved Hide resolved
Formatting is now based on PEP8 guidlines
Exceptions are also printed now
The copy operation now performs in a try-except loop for exception
handling
Moved call to convert_mtl outside of try-except (because it already has
exception handling internally) and changed the reporting to a warning
(since it shouldn't affect execution)
All variables should now follow PEP8
Since MCprep will always output its header at the end of the MTL, we can
simply check the last 3 lines of the MTL, which removes an unnecesary
for loop, and makes the code easier to read.
If an exception occurs when writing to the file, we want to gracefully
recover, hence the copying the original MTL back.

TODO: Confirm if `mtl` will be an absolute path
@StandingPadAnimations
Copy link
Collaborator Author

@TheDuckCow Made the necessary changes, although some guarantees may need to be added (like will self.filepath always be absolute?). Other then that, I think this is for the most part done

@TheDuckCow
Copy link
Member

FYI @StandingPadAnimations of a minor merge conflict resolved, in case you do further work that you'll need to pull first. Reviewing shortly!

Copy link
Member

@TheDuckCow TheDuckCow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving this.

Ready to merge, and then I'd move on to look at my PR followup here (don't review until this PR has been merged though; I couldn't use yours as a base since it's a different repo).

Also, is it fair to say that this change is actually somewhat negated now that we are moving to the new C++ obj importer in blender 3.5? I realize it'll still be helpful for the 3.4 and older users, but I just wanted to make sure I am aware.

@@ -87,6 +87,64 @@ def detect_world_exporter(filepath):
return 'jmc2obj'


def convert_mtl(filepath):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a bunch. See the followup PR I've created which includes these test files:
#388 (diff will be reduced to mostly just the test file once this PR 383 is merged)

with open(mtl, 'r') as mtl_file:
lines = mtl_file.readlines()

if bpy.context.scene.view_settings.view_transform not in blender_standard:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI only in my branched, I inverted this logic and returned early, cutting out the amount of indention below.

There it also returns "None" to indicate no conversion happened, which is a useful state imo.

@TheDuckCow TheDuckCow merged commit a48820f into Moo-Ack-Productions:dev Mar 12, 2023
@StandingPadAnimations
Copy link
Collaborator Author

Also, is it fair to say that this change is actually somewhat negated now that we are moving to the new C++ obj importer in blender 3.5? I realize it'll still be helpful for the 3.4 and older users, but I just wanted to make sure I am aware.

From what I can tell, the behavior of the new C++ importer is either an oversight or now it checks for the existance of whatever colorspace it wants to use. As such, it's also good to fix the root of the issue, just in case

@StandingPadAnimations StandingPadAnimations deleted the mtl-conversion branch March 13, 2023 23:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Blender ACES unable to import OBJ
2 participants