NodeMaterial: Add utility to convert normal materials to their node pendants.

[Samsy]

Description

Copying a model to get its properties assigned from a meshmaterial to a nodematerial breaks

Reproduction steps

1. create a MeshBasicMaterial
   2.create a MeshBasicNodeMaterial
   3.copy the meshbasicmaterial into the node one

Live example

Live fiddle test

Line 53

Screenshots

Version

r170

Device

Desktop

Browser

Chrome

OS

MacOS

[Mugen87]

three.js only supports copying materials with the same type, see #28265 (comment).

[Samsy]

Ok I understand,
I'll just override the copy with all the test needed,
Thought, the copy would be fixed by testing if any property exists in both source and target, it would enabled the copy from any material to any material ?

Apart from this, the problem in this particular case would be that it breaks the app entirely when calling copy from a different material

[Samsy]

This may cause a bit of trouble for a lot of usecase

For example, if you load a GLTF using the GLTFLoader, it does not returns a node material

Thought, if you want to override the material, but copy the property of the original, you don't know what comes from the source material, and which property are set ( aomap, lightmap, normalmap, etc.. ) also if you need to change nature type of the material, same trouble, it ends up being a one for one case of testing properties

[Mugen87]

The runtime error occurs because the implementation checks for null for certain node material properties. However, because of the wrong copy these properties end up undefined.

Thought, the copy would be fixed by testing if any property exists in both source and target, it would enabled the copy from any material to any material ?

The problem is that certain properties have different semantics although they have the same name e.g. MeshBasicMaterial.reflectivity !== MeshPhyiscalMaterial.reflectivity. So a blind copy could raise new issues we are not aware of.

[Mugen87]

For example, if you load a GLTF using the GLTFLoader, it does not returns a node material

In general, WebGPURenderer can display assets return from GLTFLoader without further adjustments.

[Makio64]

@Mugen87 is the port of GltfLoader to return node based material is on the timeline ?
I encountered similar issue on a project and did a manual translation but it would be nice if it was support out of the box when we're using webgpu three.

[Mugen87]

I'm not sure we have discussed this aspect yet. AFAIK, it is not planned so far that loaders return node materials.

Maybe we can provide some tooling that helps with the conversion process. E.g. a utility method that converts a material type to its node material pendant.

[Makio64]

I'm not sure we have discussed this aspect yet. AFAIK, it is not planned so far that loaders return node materials.

Maybe we can provide some tooling that helps with the conversion process. E.g. a utility method that converts a material type to its node material pendant.

@Mugen87 But then it means we embed all the old system (chunks shaderlib, etc.. ) when we're using a loader ? 😱

[Mugen87]

No, the shader chunk system is related to the renderer.

[donmccurdy]

Even if we did create tooling that help convert a core material type to its NodeMaterial equivalent — a GLTFLoader rewrite (and it is realistically a rewrite, IMHO...) to output NodeMaterial / TSL could be very interesting. One reason this might be advantageous compared to a material conversion utility would be to support proposed MaterialX shaders / procedural materials contained directly in glTF.

However, it's a hefty amount of work. I'm not in a position to volunteer to build or even maintain at the moment, but happy to discuss ideas.

Related:

• NodeMaterial support in Loader #30114

[DennisSmolek]

One reason this might be advantageous compared to a material conversion utility would be to support proposed MaterialX shaders / procedural materials contained directly in glTF.

From my understanding this isn't stable yet.

Neither is how systems interface with it; will the nodes in the gltf be output as attributes of a regular material with the nodes acting as backing for how those attributes were derived? This would mean the system can read the output material as the simpler standard gltf BSDF.

Or will the system be required to read the MX nodes and generate the material itself? This would mean either using the MX loader code or (like three currently does) use it's own spec conforming loader. Problem there is, the GLTF MX stuff (last time I checked) was going to convert the materialx XML to JSON https://github.com/KhronosGroup/glTF-MaterialX-Converter
Meaning the Matx Loader will have to understand both.

There's a lot to that and getting that to work.

The next thing is the vast majority of systems wont be outputting in MaterialX. Blender for example will still just be the principled BSDF and regular style materials.

---

There will be some need to convert existing threeJS materials to their node versions and it would be helpful if the library supports it, otherwise users will just make this functionality themselves.

In regards to the loader (#30114) I think that outputting directly to a nodeMaterial there makes sense too, in a system where you expect all the materials to be nodeMaterials etc it would be a pain if the loader doesnt. You'd essentially traverse immediately and convert.