-
Notifications
You must be signed in to change notification settings - Fork 26
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
Implemented MTL conversion for ACES and whatnot #383
Conversation
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)
There was a problem hiding this 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).
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:
|
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.
Just adding this for tommorow me:
|
There was a problem hiding this 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): |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
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
43579c9
to
9a067dd
Compare
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
@TheDuckCow Made the necessary changes, although some guarantees may need to be added (like will |
FYI @StandingPadAnimations of a minor merge conflict resolved, in case you do further work that you'll need to pull first. Reviewing shortly! |
There was a problem hiding this 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): |
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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.
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 |
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.