Multiple Outputs per nodetree

Hello. This mock up could be really really useful for easely creating multiple materials from one node tree.

It could also be really useful for the texture editor. He is neglected and we need to elaborate a bridge between the two node editors.

maybe @jacqueslucke could be interrested by this idea ? is it easy to do ?

3 Likes

I see that this can be useful sometimes. I think the main issue with this approach is data block management. Currently, a material node tree is owned by a material.

With this proposal the relation between materials and node trees becomes quite a bit more complicated. Also it is less well defined when e.g. the same material is accidentally controlled by multiple node trees.

Also think about what should happen when you link a material into another file, should all materials be linked?

I’m not fundamentally against this, but there are too many open questions currently. I’m not sure if the complexity of a correct implementation is worth the added user benefit. Node groups can be used to achieve similar functionality without the mentioned issues.

thanks for the response !
i mainly propose this idea because this feature

there’s no way to use cycles powerful node for particles distribution. It’s a huge flaw because cycles dispose of very powerful tools to make such distribution procedural maps that the texure editor simply don’t have.

i’m trying to make whole an addon that auto-scatter whole biomes. If i can do this only by using destructive bmesh scripts it’s quite sad because the solution is right below our eyes.

1 Like

I am interested in how would this work? What do you imagine would be passed to texture editor, an image/buffer @jacqueslucke?

In general it would be really useful if one could sample any results of some previous nodes with different UV vectors. So you can work with pixel data and not with shading points. Sweet dreams.

This approach seems a bit flawed. In general it makes more sense to take textures from a texture editor and pass them into the shader instead of the other way around. Since we do not have a powerful enough texture node editor yet, it is hard to predict how this will work exactly.

1 Like

since we do not have a powerful enough texture node

True This texture editor is really weak. so many important nodes missing… all of them.

I know this isn’t exactly what you want but you can achieve the same thing with node groups. They basically work similarly to functions in programming. You can write universal function and share it between multiple materials. It requires a bit more foresight than just mashing everything into one nodetree, but you will be rewarded by more organized materials with cleaner distinction between what is shared and what is unique per material.

yes but wont you agree it’s more easy to understand and set up ?

and no? this idea was mainly created with sharing info to the texture editor in mind (because it’s just too weak) giving aldebeo info to the texture editor could be really useful.

Why does nobody get what he’s saying? I often want/need to do this.
If you have some shader with a diffuse color output (such as a clothing pattern, grass/rocks, whatever, this is a super commonality) and then you want to put particles (fur, hair, grass) based on the difference you need to take the texture values (white/black) and put them in a vertex group for particle density. Right now, you just “can’t”, even though all the information is already there. It’s freaking frustrating!

1 Like

@jacqueslucke that guy is not a programmer! he just wants to have the vertex color given by the texture in the shader to be used as the weight for a vertex group! It doesn’t have to be complicated :frowning:

well if the particle system will be reworked i surely hope we can make some kind of links between the materials and the particles.