ShareNodeMaterial blocks to different node materials

Questions
1

Hi BabylonJS team!

I’d love to hear your thoughts and advice.
My current goal is to dynamically inject parts of NodeMaterial/Frame code into other materials, without modifying the original materials where this code is being used.

Example:
Let’s say we want to switch 20 materials between day and night modes. We do this by multiplying by a color — #ffffff for day, #0000ff for night.
The color value is stored in a shared frame, and that value is then propagated into all consumer materials. As a result, the color updates across every material — even when editing the shared material in the Node Editor.

But the ultimate goal is to transmit more complex logic this way — for example, noise functions or texture projections in world-space coordinates, and similar constructs.

I’ve just started working on this, but it’s already showing promising results — and I really like how it’s shaping up.

Here’s what I’m currently doing:
I created a dedicated material with a frame, cloned that frame into the consumer materials, and used a custom PassThrough block as a marker for where the frame should be inserted. Then I linked all clones to listen for updates of the input block values from the source material.

As a result, I now have synchronized parameter updates (like color, even directly in the editor!) across multiple materials, without having to manually edit each one. This has already solved several related issues — though I realize this is just the beginning.

(I’m also aware that this approach causes some duplicated computation, but in many cases it’s still quite practical and works well.)

I’d really appreciate your feedback, suggestions, and ideas on how to improve or optimize this approach.

What can you recomend about it? Maybe there is different approach that allow to do it a better way?
@Deltakosh @Evgeni_Popov

2

Hey there that looks like a great idea. What is your ask specifically? I feel like you managed to make it work right?

3

The main idea of my request is just to ask you to share your views on possible ways to solve this kind of task. Maybe there’s a more efficient approach that I don’t see or don’t know yet, but you do.

Below I’ve listed some initial issues I ran into. If I later get specific problems I can’t solve myself, I’ll open a separate topic for them (since that might help someone with a different case, not directly related to shared materials or this thread).

I’ve already made a working prototype, but there are still several things I plan to improve:

1. Transferring complex structures.
When I try to transfer more complex setups, I get build errors. I haven’t investigated it yet.

2. Material structure changes.
When such a block is connected, the target materials change their structure (which makes sense, since new blocks are literally added).
Because of that, if you save such a material in the Node Editor, after loading it into a scene it won’t support this system anymore — the “keys” where the shared parts are inserted get removed after integration.
I thought about marking these blocks with a flag and removing them on save, restoring the original keys back. But I don’t yet know which event could be used to catch the moment before saving the material.

3. Parameter sync.
It’s necessary to sync not only input blocks but also other nodes with settings (like gradients or similar parameters).

4. Multiple inputs and outputs.
Need to add support for shared material frames that have multiple inputs and outputs.

4

I’d say it is super specific to your needs and there is nothing wrong about that :slight_smile:

For your questions, we can try to make the system more flexible but we do not plan to “officially” support such feature (as it is too niche for the general framework)

1 Like
5

Thank you for reply! I’ll mark this topic as solved

1 Like