Assigning textures to materials is a pain that wasn't there before.

[danklaue]

I'm getting VERY frustrated porting old Blender projects to new v3.3.3 compatible ones. Having to fill out the texture slots for each material is a redundancy that adds a HUGE amount of work to legacy projects... and I really don't see the point. If each layer exports as a separate object, with its LIT and NML and diffuse texture assigned in the "Scene>X-Plane Layers" menu, why do we need to manually assign texture slots to materials?

Here's the disadvantages:
-Prone to errors that cannot easily be probed.
-Log spits out an error like: Material "X" in object "Y": LIT texture must be "NONE". WHY? This is very cumbersome, as I have to MANUALLY make sure all my materials have textures that match the layer they're on.
-Even IF I assign the LIT texture slot to the texture it's asking me to assign it to, it still exports with this error. Somewhere, there's a mis-match, and it doesn't tell me where.
-This forces me to start all over again with authoring the material, basing it on a material that's KNOWN to export properly, then duplicating it, so that I can assign it the dataref I want to affect the LIT texture. Unnecessary work.
-If I want to re-use a material across layers (say, a material whose LIT texture is controlled by a certain dataref), I have to make a DUPLICATE of that material, JUST to be able to use it in another layer. It becomes very un-overviewable, redundant, and complex.
-IT'S NOT BACKWARD COMPATIBLE. Old projects take frustratingly long to bring to the new paradigm, for no discernible benefit.

[danklaue]

I assigned this a high priority, because I'm starting to convert 50 planes to the latest format, to support PBR and new manipulator features. If I have to spend hours each day assigning textures to materials, this is a process that can introduce lots of errors, and just takes insanely long.

[danklaue]

So, let's say I have a layer for my plane's interior. It's assigned to export as "I3.obj", and its diffuse map is "I3.png", its normal map is "I3_NML.png", and its LIT map is "I3_LIT.png".

I try to export it, I get HUNDREDS of errors that a texture is mis-matched. Instead of getting the ONE object that's at fault, I get ALL the other objects in the Log that are not assigned the same as that one object that's wrong.

It's almost impossible to find the culprit object, if the error reporting algorithm doesn't go with the SMALLER sample size, to help narrow down the error.

[tngreene]

Setting the layer to autodetect textures doesn't work for you?

[airfightergr]

I believe that blender's materials properties should be disconnected from the export. Since we already assign the textures in the Scene tab, I will agree with Dan, is unnecessarily redundant.

Moreover, I might need to assign in blender a few meshes with a kind of material and/or texture, just to bake an effect, but not export with that attributes. Re-assigning another material for the export, then go back and forth many time to tweak...it is getting very frustrating.

With the new PBR materials, most job is done through the normal map. Relative attributes (ie. ATTR_shiny_rat) should be exported optionally, if the developer want that and better will be to have this option relative to the object (mesh), not the material. Now each time I export, I have to open the object in a text editor to remove the ATTR_shiny_rat, when I use GLOBAL_specular in that object.

I believe it must be rethinked in the future how to export attributes out of cycles materials. But for now, better to have what we do in blender with materials, disconnected from X-Plane materials.

[bsupnik]

@danklaue : why are you doing this? You can just leave auto-detect OFF and do none of this work and have none of the annoyance. This isn't a mandatory project upgrade.

The intention of the design is that if you had a brand NEW project, you would be relatively careful about building your materials from the start, you would use a (relatively small) palette of materials and things would be WYSIWYG and just work.

With that in mind, I do have two follow-up comments on the specific report here:

1. If there are any material error reports where it isn't obvious what's going on, then we need to make the error reporting better. This is very much the first revision of the validator, so the errors are probably too terse/cryptic.
2. How many materials do you have, exactly? Given that most materials cause the CPU to do more work in the OBJ, a lot of materials indicates either:

• A lot of redundancy - e.g. somehow basically identical textures were duplicated or
• Poor performance - e.g. if you have 1000 different diffuse attribute shades (instead of tinting your albedo texture) that's not great.
  It may be that, because the old export wasn't material-centric, you've ended up with too many materials. In that case, see also my original comment that migrating to the new work-flow may not be a good idea for your current IP.

@airfightergr: for new projects, I disagree with this 100%. Requiring users to hand-enter the texture that Blender already knows from its own materials (which is what you actually see when working) is counter-intuitive and unnecessary, and results in surprising export results. The blender 3.2 exporter is the only exporter for X-Plane that has this rule; our goal with the revision of the exporter is to create a work-flow where what you do in Blender does match what you get in X-Plane.

With that in mind, I am sympathetic to the complexities of baking, but in the end of the day, any baked work-flow is always going to require some redirection, because the source materials and bake results are never the same.

[danklaue]

Setting the layer to autodetect textures doesn't work for you?

Um, I think that's a separate issue, no? Or does whether I have the "autodetect" check-box enabled or not, affect the materials texture slots detection?

[bsupnik]

@danklaue I think the correct operation is: if auto-detect textures is off then the texture validator should not raise any errors based on "oh, you have incompatible textures in your material" because that data isn't going to matter for the final export anyway. If auto-detect is on, the material's textures do matter because they are going into the OBJ and some combinations cannot be legally exported.

So: perhaps we have the specific bug: "turning off auto-detect textures does not bypass material texture validation"? That would definitely be a bug and it's actually pretty easy to fix.

@tngreene We spoke about this case a few weeks ago - is this something you already fixed and created test cases for? Sorry, I can't remember that far back.

[danklaue]

@danklaue : why are you doing this? You can just leave auto-detect OFF and do none of this work and have none of the annoyance. This isn't a mandatory project upgrade.

Again, I believe auto-detect is a separate feature, which has nothing to do with what I'm commenting on. Especially for legacy projects, I've had bad experiences with auto-detect, as it doesn't seem to do a good job "auto-detecting" the textures I mean to export.

The intention of the design is that if you had a brand NEW project...

Then there should be an opt-out, IMHO.

If there are any material error reports where it isn't obvious what's going on, then we need to make the error reporting better. This is very much the first revision of the validator, so the errors are probably too terse/cryptic.

Terse/cryptic aside, if you have ONE material that's got NML's and LIT's swapped, or you didn't assign a NML, but put a LIT in its stead, ALL OTHER materials output errors, instead of the one that's a mismatch.

How many materials do I have? Say, for instance, I have a cockpit panel with 24 annunciator lights.
That's 24 materials right there. (Each with its own dataref linked to the LIT texture.) (I COULD use show/hide, but sometimes I want that "fade" effect, which necessitates the use of nighttime texture and datarefs set in material tab.)

I leave PBR roughness to the NML map, not to each individual object... although it's nice to have a max. value of roughness set via material.

I need to get all my projects into one version of Blender, exportable via the same exporter, just for maintainability's sake. If I now have to split my projects into "Cockpit object" (support for 10.5x manipulators) and "All Other Objects", and have different versions of Blender/XP2B exporting them, and you have that across a fleet of 100 products, the complexity is just unoverviewable.

[danklaue]

So: perhaps we have the specific bug: "turning off auto-detect textures does not bypass material texture validation"? That would definitely be a bug and it's actually pretty easy to fix.

That'd be AWESOME! I don't use auto-detect in legacy projects, and I'd prefer to be spared having to assign textures to materials individually. New projects, I'm fine experimenting with auto-detect textures.

[bsupnik]

@danklaue re: the one "swapped" lit/normal texture..Blender doesn't know which one is right and which one is wrong, although it might be that we could someday look at ALL errors and use a majority-rules system to decide which texture is wrong. I think the original thinking was: given at least two-mismatched materials, you can go look at them and decide what to do.

Anyway, my contention is that auto-detect and validation are inherently tied together, because auto-detect is how you make your material textures matter, and turning it off is how you let them be meaningless to the exporter.

[danklaue]

Well, if that's a bug, (or a broken feature), that's what the title of this issue should be. It's currently not behaving as you mention, and it'd be VERY welcome to have "auto-detect" affect texture validation, as an opt-out for legacy projects... if that'd work.

[danklaue]

It'd be good to get a status update on this. I was also wondering if perhaps you'd have to set ALL layers "Autodetect Textures" to off, in order for it to work. I haven't tried it yet, but could that be the culprit?

[tngreene]

Believe me, I have heard your "priority high" loud and clear. I'll look at this first thing in the morning. Hopefully some answers will arise.

[danklaue]

Thank you! This and #241 are the most show-stopping bugs for v3.3.3. Otherwise, I've used it extensively for a few weeks now, and it's pretty solid.

[danklaue]

Any updates on this? Is it something that was implemented functionally at some point, but is now a bug? Or is it something that cost a lot to implement?

[tngreene]

Much work was done on #241 given that it was potentially the source of a lot of other bugs, but now that has been handed off to Ben and this is my primary concern.

[tngreene]

Hi @danklaue, please try the commit 19c7944

Having a layer's "Autodetect textures" checkbox unchecked allows you to override Blender's material selection. It won't compare materials and cause errors.

[danklaue]

OK, I tried this commit. It works for me, as described: with "autodetect textures" checkbox disabled, it doesn't require you to link textures to your materials. Very huge relief! Thank you!

[tngreene]

Glad to help! Thanks for sticking with us on solving it.

While the bug here is closed, there is still the remainder of creating unit tests. See #250