prep materials system doesnt work with radeon pro render (a new render engine thats in beta for now)

[xNoodlePlayz]

title ^^^

[TheDuckCow]

Thanks for logging this issue.

I would love to provide at least basic support here, and we already have some level of a framework in place to extend based on how Eevee, Cycles, and Blender Internal are all already handled separately. However, I am not familiar with this new renderer as of yet.

Would you be able to share what manual changes you would need to make in any of these areas? e.g. what is the end shader nodes you use? I imagine it will breakdown into these areas, would be curious to see what thoughts you have on any of these sections.

• Basic UI drawing (perhaps the blender UI is broken in some way out of the box? Would love to see screenshots and console outputs)
• Prep materials (broken out into solid, transparent, reflective/non reflective, and emission)
• Create sky (shader nodes for the world background)
• Swap skin (I'm curious, I'd almost expect this to already be working as-is, can you confirm?)
• Item spawner (I presume the items spawn ok, but without correct looking materials?)
• Swap Texturepack (I would expect this to work ok if the base material of the blocks to be textureswapped were already fixed and looking ok)
• Animate textures (Again, I would expect this to work fine if the base material is already OK)

To be clear, support may be limited and I can't promise all of these areas will be supported, but the first step is understanding first what work is required. It could be simple in some cases, more complex in others.

[StandingPadAnimations]

Maybe we could have a special folder in the MCprep folders for prepping materials. Basically, the actual material setup can be outsourced to the py files in the folder. All developers would need to do is:

• Make a new file with a function that sets up materials
• Add the import and call the prepping function in the prepping operator(using some if statements)

This would make it so people can develop py files that users can copy to the MCprep addon, without needing to maintain a fork

[StandingPadAnimations]

Basically, a MCprep API so to speak

[TheDuckCow]

This could be an option - though tbh, I think the "sync materials" feature gets people close if they are willing to do a one time setup to create a library (this feature is not well advertised and seldom used). Possibly paired with a way to replicate an equivalent layout to other materials quickly. Another approach: enclose all materials into a node group, so someone could manually connect the according inners. Not sure if that will generically translate to other render engines, but I'm hoping they have close equivalent texture nodes and use "material out" the same.

[StandingPadAnimations]

This works, but doesn't sync materials go by a per block basis? It's be interesting to have a "default" material that has a special name. Then when prepping it uses that material for every material, just changing textures

[TheDuckCow]

Yeah exactly, it works per block - hence the supporting idea feature to "replicate" quickly across other materials. Sort of like specifying a default material as a base. I'm definitely open to ideas, and not to shut down the idea to create py files per engine which could have a lot of benefit (even just for Eevee+Cycles+Blender Internal), but also like the idea of creating solutions which a user can easily resolve their issue using the UI, meaning they can always make it up to date vs needing to explicitly support a multitude of changing render engines.

[StandingPadAnimations]

Maybe the default material could be named something like "default_mcprep_renderengine" with the render engine in lowercases.

[TheDuckCow]

Definitely an interesting thought. I'm warming up to this idea, as it would also move material definition out of code and back into UI asset files which makes it easier for people to update on their own. Will need to think how it applies to also supporting multiple styles (ie SEUS or Specular or Simple), but that could just be another tag which is after the engine name either in the material name or filename.

Moving to something like this also makes the "replicate materials" feature unnecessary, and would still allow us to play well with resource pack remapping.

[StandingPadAnimations]

Commenting on this again as I'm working on implementing #274: it seems like AMD Prorender can use Cycles nodes now.

[StandingPadAnimations]

@xNoodlePlayz same comment as I gave on #237 (comment) (same request as yours but regarding Octane instead), the best route for now would be to fork MCprep and support for Radeon Pro Render on your own

[StandingPadAnimations]

As mentioned in #237 (comment), I'm just going to close this issue since 3rd party engine support isn't a trivial thing to add