sure, but also snow from bottom cause z axis will paint it both ways lolDade wrote: ↑Wed Jan 15, 2020 3:42 pmYes, snow is a classic example: you use snow from the top and grass/terrain from the side.juangea wrote: ↑Wed Jan 15, 2020 12:29 pm Oh yes there is, it simplifies mixing procedural textures in some situations, like in nature creation (rocks, tree barks...) , you can use different textures to create more variety, I would not disable that option, just simplify it for when you want to use just one texture.
Triplanar mapping / stochastic texturing
Re: Triplanar mapping / stochastic texturing
Re: Triplanar mapping / stochastic texturing
It is the backface, you don't see them on a terrain.
Re: Triplanar mapping / stochastic texturing
Yes here and there you can get away with these tricks and example like with rocks which juangea mentioned also sounds ok. But I would be very surprised if someone used multiple textures on triplanar more than 10% of the time and even then you would be probably ok without that.
First of all I'm not saying we shouldn't have the ability.
But having all these inputs and nodes exposed for rare cases is overkill. So I would suggest packing it all into image node (triplanar checkbox that switches 2d mapping input into 3D mapping and you're good... if this is technically doable) and it should also by default disable using uv's in that case.
For cases where you actually want multiple textures, maybe then keep a separate triplanar node..? Not sure. But a basic triplanar usage should be very straightforward without busy nodes all over the place imho.
Re: Triplanar mapping / stochastic texturing
The idea proposed by Juangea here (viewtopic.php?f=5&t=1638&start=100#p19403) sounds good to me.lacilaci wrote: ↑Wed Jan 15, 2020 3:57 pm First of all I'm not saying we shouldn't have the ability.
But having all these inputs and nodes exposed for rare cases is overkill. So I would suggest packing it all into image node (triplanar checkbox that switches 2d mapping input into 3D mapping and you're good... if this is technically doable) and it should also by default disable using uv's in that case.
For cases where you actually want multiple textures, maybe then keep a separate triplanar node..? Not sure. But a basic triplanar usage should be very straightforward without busy nodes all over the place imho.
Re: Triplanar mapping / stochastic texturing
This is how it looks now.
Good? Did I forget something?
(You'll have to delete old triplanar nodes and add new ones instead because I renamed some sockets)
Good? Did I forget something?
(You'll have to delete old triplanar nodes and add new ones instead because I renamed some sockets)
Re: Triplanar mapping / stochastic texturing
hm. looks ok.
btw is there a warning if someone connects triplanar to bump(regular bump), that they need to use triplanar bump?
Re: Triplanar mapping / stochastic texturing
Looks good to me
Better and more clear workflow, no entangled node network required for mapping, easy understanding
Thinking about the text, I would out more "multiple textures" or "multiple input" instead of "individual textures", "individual" word drives me to think about it as single one, it’s a minor thing and a totally subjective thing, so it’s not important if you don’t agree and don’t change it, it’s just what I felt when I saw the nodes for the first time
Better and more clear workflow, no entangled node network required for mapping, easy understanding
Thinking about the text, I would out more "multiple textures" or "multiple input" instead of "individual textures", "individual" word drives me to think about it as single one, it’s a minor thing and a totally subjective thing, so it’s not important if you don’t agree and don’t change it, it’s just what I felt when I saw the nodes for the first time
Re: Triplanar mapping / stochastic texturing
There is now:
Note, this only covers this exact case, the warning is not shown if there are some other nodes between the bump inputs and the triplanar texture. But if I check all such conditions, it will become a performance problem.
Sounds better, changed.