Page MenuHome

Wavefront OBJ: faster exporter, continued
Needs ReviewPublic

Authored by Howard Trickey (howardt) on Apr 19 2021, 8:47 PM.
Tags
None
Tokens
"Love" token, awarded by Dragon.Studio."Love" token, awarded by printerkiller."Love" token, awarded by Bit."Love" token, awarded by kursadk."Party Time" token, awarded by kioku.

Details

Summary

This is a continuation of D8754, starting afresh from the soc-2020-io-performance branch, making the outstanding changes requested in D8754, and then making a local branch that deletes the importer.

Diff Detail

Repository
rB Blender

Event Timeline

Howard Trickey (howardt) requested review of this revision.Apr 19 2021, 8:47 PM
Howard Trickey (howardt) created this revision.
source/blender/io/wavefront_obj/exporter/obj_export_mtl.cc
258

I would strongly advise against copying this functionality from the old exporter. Legacy MTL has no specifier for metalness, it should not be mangled in.

Ka is the tint that gets applied to ambient lighting. Kd is the tint that gets applied to the direct diffuse. Always try to keep Ka the same value as Kd unless you have artistic reason to do otherwise.

In modern files it is usually pretty safe to ignore Ka on import but always try to keep it valid to avoid bugs in other software.

source/blender/io/wavefront_obj/exporter/obj_export_mtl.hh
73

This writes the metallic mask to the reflection texture. This texture is only ever used for matcaps and cubemaps. This is another bug from the old exporter.

I originally thought I would use the opportunity of this new exporter to fix those bugs. But then figured it would be better to first have a release that matched as close as possible the old behavior, so that users wouldn't complain, and then follow up with functionality altering bug fixes. I'm interested in Sybren's thoughts. I don't have a super strong opinion.

I originally thought I would use the opportunity of this new exporter to fix those bugs. But then figured it would be better to first have a release that matched as close as possible the old behavior, so that users wouldn't complain, and then follow up with functionality altering bug fixes. I'm interested in Sybren's thoughts. I don't have a super strong opinion.

I agree that most of the overhauls needed for robust MTL IO should be done at a later time. It's just the offending incorrect code detailed above could be left out and shed the bugs it causes in the process.

I originally thought I would use the opportunity of this new exporter to fix those bugs. But then figured it would be better to first have a release that matched as close as possible the old behavior, so that users wouldn't complain, and then follow up with functionality altering bug fixes. I'm interested in Sybren's thoughts. I don't have a super strong opinion.

I do have a strong opinion here: first get the fast import/export working with the same feature set. That way anybody can benefit from the new speed. After that, improve things. That way even more people can benefit, but also people who won't be able to upgrade to the new behaviour still have the benefit of the new speed.

Will this properly handle Collections instanced as Empties— Including arbitrarily deep recursive layers of subcollections and highly interdependent global-space modifiers?

The old .OBJ exporter is currently the only code in Blender that is actually able to reliably convert collection instances into mesh data, to my knowledge.