procedural coordinate system, hierarchic or not ?

[radiance]

Hi all,

As many might have noticed we now have various procedural textures that you can use in combinations to form a hierarchy making more complex procedurals.
The flexibility/power of these lies in the scaling values used, with the float, float2 or float3 scaling nodes.

Currently they are not hierarchic.
I'm wondering if we should make them hierarchic or not.

what do you think ?

hierarchic basically means that the root procedural's scale will influence it's children.
currently (with no hierarchy) you change the scales of all children.

so imagine you've made a wood material with 5 levels deep, various procedurals, scaled in various ways.
with the hierarchic method, if you would scale the root (eg the first one), the whole thing will scale.
with the non-hierarchic method, only the root node will scale, so you need to change the scale of all the children too.

there are pros and cons to this and i'd like to hear what people think would be best as we have to adopt a standard for the 2.2 final that needs to last a few weeks at least.


Radiance

[greg.thoman]

Since some situations might require one or the other, would it make sense to toggle hierarchic scaling? That way the user could fix a scaling issue on an internal layer and then scale the entire texture, keeping ratios intact.

[radiance]

Since some situations might require one or the other, would it make sense to toggle hierarchic scaling? That way the user could fix a scaling issue on an internal layer and then scale the entire texture, keeping ratios intact.

well, the more 'options' the slower octane becomes (especially in this area), that's why i'd like to hear first what people think.
if there is a majority for one of the 2 options, i'll likely implement that.

Radiance

[greg.thoman]

I see. My needs would be Hierarchic most of the time.

[pixelthekid]

First, I have to applaud you for adding this functionality to Ocatane. It really opens up a ton of possibility and makes the renderer much more valuable. Thanks!

I would also vote for a hierarchic mode or behavior.

[atome451]

I see. My needs would be Hierarchic most of the time.

Me too...

[Proupin]

what would happen to children that are connected to more than one parent (let's say feeding the same turbulence to various materials), and you choose to scale the root of one of those materials? with the heriarchic method, would it scale the children thus affecting the other material as well? or would it have a ripple effect on children but not actually modifying the children's scale param?... I vote non-heriarchic and instead work on separate scales (world units).

[kubo]

let's say you have this "master" node with a 0.5 scale, if it's children have a 0.5 scale also, that would mean they have a global 0.25 scale, right? if so, could they have values above 1? cause if that's the case I don't really mind which way we go, either one could be achieved with a little bit more input just as long as is documented, but if the "parent" limits its children scale and they can't go higher I would vote for non-hierachic approach, because you can always input individual related scales.

[radiance]

I think i will go with non-hierarchic for 2.2, and hierarchic in 2.3, as i need some time to figure this out as it's not that simple, like you say, with shared nodes etc...

Radiance