Implement new Autodetect Textures From Cycles workflow

[tngreene]

Autodetect Textures Workflow was added #137, and now with #399 it is broken - there are no more Texture Slots to fill in 2.8. To be clear about what feature I mean:

1. Instead of unchecking Autodetect Textures and filling in the TEXTURE file paths by hand, for every material, make or reuse an Image Texture Slot with the same image, check a certain Influence box to set it as the Albedo Texture, Normal Texture, or Lit Texture.
2. Warnings are given for not using the correct textures in combinations with Material Options
3. XPlane2Blender uses this to write the TEXTURE.... directive
4. It can also use this to Compile Normal-Textures #299
5. This way the user also sees the Texture in Textured mode of the 3D View

Some problems:

1. As mentioned in #357, users find it annoying to have to keep some piece of data the same across 10s or 100s of datablocks.
2. These warnings are entirely reliant on the user using this feature correctly. If they have not taken the time to change the Influence flags they'll get a lot of meaningless warnings
3. Avoiding writing in the file path by hand once, is I think, a very small feature
4. How relevant and used is Compile Normal-Textures? It was made before PBR. Does it really depend on the Autodetect Textures feature? There are no errors before it. It just seems like that is where the code was stuck.
5. This is by biggest one. There are several ways to get a texture to be mapped in Blender's 3D Viewer. I don't think we should force people to use any particular one anymore, now that I know about EEVEE, Cycles, and the UV Image Editor. Especially on the account of just a few text fields.

If we did want to do some texture checking for the user we'd have to start looking at establishing conventions and documenting them with Shader Nodes or the UV Editor Again. Or maybe we could let the user specify the images they want checked which would be much easier.

This also affects what we want to do with #445. I'm not sure if the converter setting the Texture Slots is a valuable feature if 2.8 immediately ditches it.

[tngreene]

See also this forum post: https://forums.x-plane.org/index.php?/forums/topic/187150-help-decide-what-the-new-texture-workflow-should-be-for-xplane2blender-for-28/

And it is worth noting I have almost never seen a .blend file sent to me without Autodetect being unchecked.

[arb65912]

And it is worth noting I have almost never seen a .blend file sent to me without Autodetect being unchecked.> Than it seems majority do not care for it.

[airfightergr]

Opinion: Autodetect feature is not useful and probably a proper implementation will consume your valuable time from other stuff.

Since this "1 time set and let it as is" feature, does not bother the artist/developer/user to do it. In the contrary, I feel doing a few things manually, gives more control to the user, and we want this.

Probably, the final texture maybe not used inside blender. Someone may use a base/albedo texture to bake stuff on another texture and then use an external program (Substance Painter, Photoshop, Gimp, etc.) to compose the final texture.

Suggestion: Remove it!

[tngreene]

In response to community feedback the resounding response is that this feature is rarely used.

The new plan is to remove the Texture Slot auto-detection and to use "Has a Texture Path Set Or Not" for triggering the warnings. Very simple and a very low amount of code change. Compile Normal Textures doesn't even need a change.

[tngreene]

Actually, we're not scrapping this after all!

• [ ] @alxunru is on his way to making a Shader set up that is WYSIWYG in X-Plane.
• [ ] We'll template that out for Cycles in 2.79
• [ ] We may add a converter that takes any textures slots or filled in manual override texture paths and inserts them into the shader system.
• [ ] In 2.80's updater we'll switch from Cycles to EEVEE and it should just work.
• [ ] As long as the user doesn't make complicated changes to the template, we can autodetect from that
• [ ] The manual override paths will serve as a fallback, instead of being ignored as they currently are

[tngreene]

From #399

• [ ] Replace inspecting Texture Slot's File Paths with the Layer Settings's Texture File Paths, remove Autodetect Textures

  Unit Tests that may need updating: features\texture_composition.test.py features\autodetect\autodetect_textures_2.test.py materials\objects\AOTC_2Mats_PNL.test.py materials\objects\COTC_2Mat_Hard.test.py materials\objects\IST_2Mats_SameSPEC_DifSURF.test.py materials\objects\IST_2Mats_wDraping.test.py materials\objects\SSO_2compatibleMats_Draped.test.py materials\objects\SSO_2incompatibleMats.test.py materials\objects\SSO_3compatibleMats.test.py

(The fact that the other autodetect unit tests didn't fail is very interesting to me!)

• [x] Hide Autodetect Textures in the UI and delete it. If we come up with some new Autodetect system, we'll want people to opt into it
• [ ] If it is a terribly tedious solution, make a forwards compatibility script to run in 2.79 to make your projects Node Ready
• [ ] One day when we do have some conventions it would be nice to provide people templates of shading workflows. EEVEE is not instantly approachable.