Ogre Next (aka v2) JSON material support

[jamieson]

Basic support for a metallic workflow producing OGRE Next JSON materials. Closes issue #148

Changes and dependencies outside of the new materialsv2json module:

• Depends on material.gather_metallic_roughness_texture() from PR Export Metal-Roughness maps #172, any change to that function will need to test JSON material export.
• Implements channel separation in util.image_magick(). Done with a kwarg, so should have no impact.
• Adds the config parameter MATERIALS_V2JSON and checks it inside scene.dot_scene().

JSON Materials features:

• Sets the diffuse, emissive, metalness, roughness, specular (colour), transparency, alpha_test, two_sided and workflow as required
• Leaves default the blendblock, macroblock, sampler, shadow_const_bias, brdf, detail_diffuse[x], detail_normal[x], detail_weight[x], fresnel, receive_shadows, reflection
  See the notes in MaterialsJSON.md for the rational.

Metalness texture fetching expects a single image with the metal texture in the Blue channel and the roughness texture in the Green channel. The channels are expected to have been split via a 'Separate RGB' node before passing to the Principled BSDF. This is in line with the glTF standard setup. Doing something else will have sub-par results or simply fail. It can't handle more complicated node setups.

This code will always attempt an export but it will have poor results if given a specular workflow material.

[sercero]

How does this work?

From what I have seen it seems that you check the option "MATERIALS_V2JSON" and now blender2ogre exports the OgreV2 material .json as well as a OgreV1 material definition.

@paroj do you think that perhaps it would be better if it was a combo list selection?

Something like material_output: ogrev1 / ogrev2json?

Because it seems to me that if you are using Ogrev2 you're not using v1 and vice versa.

[jamieson]

The config variable stops the v1 generation at scene.py:196. If MATERIALS_V2JSON is True it will call dot_materialsv2json() instead of dot_materials().

I defer to you two about whether it should be a picklist or not, I have no preference and would be willing to write the change.

I also see the CI is failing. I have only tested this with Blender 3.5. It looks like emission_strength_texture was added to node_shader_utils in this commit from Sep 2020 which appears to be first included in blender v2.91.0.

Is there a desire to ensure compatibility with a specific version of Blender? If so is there a preferred way of handling features not usable in older versions?

[sercero]

I don't know what is the official support list, but I think that at least the following versions should be supported:

• blender-2.83.x (LTS+EOL)
• blender-2.93.x (LTS)
• blender-3.3.x (LTS)
  (all the LTS versions so far)

So, there should be a check to see if emission_strength_texture feature is present or not and act accordingly.

I also think that the config variable to export the material version should be a picker.

Let's see what @paroj thinks of this...

[paroj]

Is there a desire to ensure compatibility with a specific version of Blender?

CI must not fail. Therefore blender 2.82 must work for now.

If so is there a preferred way of handling features not usable in older versions?

Not use the feature - otherwise it is untested which equals to broken after some time

[jamieson]

Updated branch as per review, using detect_converter_type() and removed emission_strength_texture usage.

[paroj]

thanks