Material Process Nodes

[antongit]

Current state on develop

Pros

1. DiffuseMap and such wrap the feature and the Value/ColorMap node into one processnode.

Cons

1. The Nodebrowser has then the Diffuse and the DiffuseMap nodes visible, both as Advanced. There is a confusion which one should I take?
2. If I want to control the Diffuse feature not from the Texture, but from the ShaderFX, I have to replace Diffuse with DiffuseMap.

Emissive was not wrapped into the Processnode before the Node20.

New state on computecolor-to-gpuvar

There was a decision to remove the DiffuseMap, NormalMap and DisplacementMap nodes.

Pros

1. As there are now only two xxxMap nodes left: ColorMap, ValueMap - there is no confusion between Diffuse and DiffuseMap.
2. It doesn't matter the way the Diffuse feature is controlled - from the Texture or from the ShaderFX, the node stays.

Cons

1. User has to create at least 2 nodes to control the Diffuse: Diffuse + ColorMap. And probably also a texture from the drive, then + FileTexture as well.
2. The Displacement, Emissive, Normal nodes come from different categories: GeometryAttributes and ShadingAttributes, so if I'm new to patching the Materials there is no way to know where and what to look for. Just typing and guessing.

General

• Diffuse can be moved to the PBRMateralBase node (like Metalness and Roughness), because there is nothing to configure, it just takes just one value (be it a value or texture).
• Normal, Displacement and Emissive nodes cannot be moved into the PBRMaterialBase because of the many pins they have. So we're not talking about "Standard Features should be already inside", but it just depends on how many pins the feature brings with it and the decision to bloat the Material node or not.
• The Displacement and Emissive nodes take already two Maps: Map and Intensity, so they can't be wrapped into a single processnode (xxxMap). On the develop I've decided to constrain the Intensity of the Displacement to the Float32 value, which is theoretically wrong, but it was convenient to have these xxxMap nodes for the Node20.
• Not that good: ColorMap and ValueMap nodes have a lot of Texture related pins hidden (UV Modes and so on), which is a bit cumbersome. And if one will animate Scale or Offset there, it will lead to the recompilation, as I've understand @tebjan.
• From the User point of view, I'm not sure that it is good to have the distinction between the ColorMap and the ValueMap. Yes, one takes a Texture and a Fallback RGBA, another one takes a Texture and a Fallback Float32. But... would it be cool if there will be just one Map node, which takes a Texture and a Fallback Value (Color or Float)? Otherwise I have to always think "wait, yes, displacement is just one value, so I'll drive it from the Grayscale Texture, so I have to take ValueMap, not the ColorMap". Yes, one get used to it, but it's a short stopper even then.

[antongit]

This is related to vvvv/VL.StandardLibs#310

[antongit]

The decision after the talk is:

PBRMaterial nodes are:

• PBRMaterial (the simplest)
• PBRMaterial (Metallic) (old name PBRMaterialBase (Metallic))
• PBRMaterial (Metallic Texture) (old name PBRMaterial (Texture))
• PBRMaterial (Specular) (old name PBRMaterialBase (Specular))
• PBRMaterialBase - removed

The Diffuse feature is going into the PBRMaterial processnodes.

The PBRMaterial (Metallic Texture) is still in question. @joreg wants to have it, because it's easy to test textures loaded from the internet. @antongit has never used it.

In general @gregsn and @azeno argues to remove many PRBMaterial nodes and leave only the barebones. @antongit is arguing, that it will be just very cumbersome to build a PBRMaterial node everytime. The thing is, that PBRMaterial (Metallic) covers everything which can be done and made with the PBR Material's Metallic Workflow. So why not to offer this node.

[tebjan]

@antongit for now, remove the PBRMaterial (Metallic Texture)

[antongit]

Please note one of the points from my initial Issue:

The Displacement, Emissive, Normal nodes come from different categories: GeometryAttributes and ShadingAttributes, so if I'm new to patching the Materials there is no way to know where and what to look for. Just typing and guessing.

Try to type 'Normal' in the Nodebrowser, you'll be already overwhelmed with the choices (advanced should be on). And then... which one to take...

But of course the categories are correct and right. One should just learn it, probably.

[gregsn]

I think it would be great to have a Category per Interface.

Nodes in our material patches would have the following choices: Stride, Material, Geometry, Tesselation, FlatTesselation

In the same go one would rename the GeometryAttribute node and category to Geometry. It's category would have subcategories for Tesselation, Displacement, Surface and MicroSurface.

[gregsn]

following the same argument we'd end up with these choices for Metalness Map, which should reflect what we see here: Following this pattern we'd have a direct translation of the stride feature-set into our node-set without the need to reinvent anything here. So Stride, Material, IComputeScalar category comes with BinaryScalar, Float, ShaderClassScalar, TextureScalar, VertexStreamScalar choices. To be discussed: How does that work together with the ShaderFX node-set?

[tebjan]

We just have Metalness with a GPU float input, that's it. Nothing else needed, because we have generics. But for Materials we added ColorMap and ValueMap to resemble the choices in GameStudio. But they are not really required, since one can just connect any ShaderFX node directly there.

[gregsn]

see also: vvvv/VL.StandardLibs#226

[tebjan]

I've now added Value, Map, and PerInstance nodes for Color and Float into a new Input category in Materials. Should we close this issue for now?