Import: Factor texture node creation out into its own function

[scurest]

This adds a function make_texture_block that makes this string of three nodes given a TextureInfo object

This should be way more maintainable than having it duplicated all over the place. There were lots of bugs because of inconsistent duplication that this should fix:

• metallic roughness images weren't checked if they were None, causing an exception if they were missing
• the metallic roughness mapping for TEXTURE_FACTOR didn't have the special case for Blender >= 2.81.8 fixed in master by d11b687
• specular/diffuse textures didn't have their label set
• occlusion nodes didn't have their location set

The texCoord field on KHR_texture_transform was also ignored.

All the stuff where a texture transform was stored on images was removed (it didn't really make sense anyway; what if the image was used twice with different transforms?). It can just be read from the TextureInfo object.

I also removed the stuff for setting the UV map after a mesh was created because all it did was set the UV map to TEXCOORD_n anyway. What was the point of the blender_texcoord stuff? Did I need to keep it?

Doing #687 will be trivial after this since only one place will need to be updated.

[julienduroure]

I also removed the stuff for setting the UV map after a mesh was created because all it did was set the UV map to TEXCOORD_n anyway. What was the point of the blender_texcoord stuff? Did I need to keep it?

There was a reason, but I currently don't remember why. Will try to find the reason by testing it

[julienduroure]

Hello @scurest

I also removed the stuff for setting the UV map after a mesh was created because all it did was set the UV map to TEXCOORD_n anyway. What was the point of the blender_texcoord stuff? Did I need to keep it?

OK, I maybe remember why ... Material is created before the mesh. So UV is not existing yet when creating the material.

Same way that a same material must be duplicated, dependant if vertex color is used or not, we should have to perform the same for UV (UV data / vertex color is on primitive side, and material is on material side). But this never has been implemented for UV, only for vertex color

[scurest]

Material is created before the mesh. So UV is not existing yet when creating the material.

Why does that matter?

[julienduroure]

Why does that matter?

In UI, you can't assign an UV if the active object doesn't have this UV. But seems you can do it with API, even if the node is in invalid state until the UV itself is created.

[scurest]

So there's no problem right?

[julienduroure]

Right, no problem when using API.
Didn't check when I first dev it, checked only with UI.

[scurest]

@julienduroure How is this coming?

[julienduroure]

Sorry, very busy weeks ...
LGTM at reading it, but I'd like to add some unit tests for all differents cases used for importing textures.