Use nodegroup option in prep material

[zNightlord]

Check against existing requests

• I have checked existing feature requests, and my idea is different

Describe the context

This somewhat have been discussed before in Discord, a "Custom" shader for users to change or tweak rather hardcode like current pack formats and use in prep material, a more forward version of sync material.

Beside the nodegroup restructure this also bring mixing PBR textures as a feature later on.

This feature will be in exprimental flag as planned before.

Related to #431 since with this we can store LabPBR pack format as nodegroup.

How do you imagine your feature works?

Due to current code, Texgen functions are mixed with some extra "processor" depends on the pack format

• Seperate RGB, SEUS packed channels
• Mix Color, Tint for grass vegetation biome
• Inverts, Roughness and Normal
  ...

What Texgen supposed to is only create the image texture nodes right?

So splits the texture nodes out, the rest in a shader nodegroup.
The default nodegroup sockets should exposed are: Diffuse, Alpha, Tint, Roughness, Metallic, Normal, Emission (Emission likely optional)

What about emission nodes?

We do the same for it. Split it.

So does it mean LabPBR, MER (Bedrock) or some custom water shader can easily added by the user?

Yes as long as the nodegroup is Blender material nodetree

What about current pack formats?

We introduce a function that create a nodegroup tree if not exist and add the nodes in it.

Why not put those existed pack formats into a blendfile?

Just in case the download process blendfile got corrupted, we still have it as backup and reuseable code reason.

Other questions like:
Since we are dropping 2.7, should we stop using the non principled "original" nodetree?

What existing workaround (or closest thing to a workaround) do you have today (within Blender, MCprep, or any software)? If there is no workaround, explain why you feel this way.

I think I already demonstrated everything. I will add images later if things are still unclear.

[StandingPadAnimations]

We already have #274 (which is half-developed and exists in the MCprep source code already) which allows users to create their own materials. The problem with a nodegroup is that it abstracts too much from the user, which goes against MCprep's design goals

[zNightlord]

Yeah this idea of "custom" sounds abstract.
It can be in 2 ways.

Us someone can program, what we possibly no longer can or easily control the options essentially it jumps over the reflective, solid, emission, emissive nodes...

From user perspective they don't have to convert something like LabPBR into code and even extends further to something like parrallax (oh dear)

A forward version of sync material is you can directly work in your current blendfile change that nodegroup.

The goal is to somehow make thing more convenient, migrate to more asset way.

These are the idea image and one from the prototype which I added a few things

[StandingPadAnimations]

From what I can tell, this behavior can be replicated with the Default Materials proposal (just create a default material with the nodegroup). There's not any reason to replace the current material setup with a group node (especially considering group nodes are harder to edit)

[zNightlord]

If you don't count many things I strangely layouted in "How do you imagine your feature works?" yes it is likely adding another similiar feature, add another level nodegroup for material or customize material nodetree.

I opened this issue after #431 so

[StandingPadAnimations]

Even with "How do you imagine your feature works?", I don't see how this has to be seperate from custom default materials.

When custom default materials is used (at least in the proposal), MCprep will only provide image textures, that's it. Default materials can be split per pack format (and I want to also allow users to be able to select any custom default material found in material.blend, so other formats could be supported too).

The only advantage this proposal has is not hardcoding the pack formats, and again that could be done by extending the custom default materials proposal (heck, we could eliminate hardcoded material generation with custom default materials only, and that would be virtually identical to this, but far more flexible). This just seems like unnecesary abstraction in comparison

[StandingPadAnimations]

With that I'll be closing this. I think it would be better to extend (or propose an alternative route) #274