Scaling up the colors and displacements?

[René]

Some time ago I made a stone from an octahedron with a lot of textures, and I want to use it now, only ten times bigger. Is there an easy way to scale up the colors and displacements according to the size of the stone?
For the colors I can use a transform shader but for the displacements I have no solution, except to adjust everything manually.

[cyphyr]

Short answer ... not really.

Displacements are driven from colour (grey scale) values which define how much an area is displaced. So if you have a pure white spot driving your displacement then the area covered by that spot will be 100% displaced by the value set in the displacement. It could be 1m or a 1000m. If the spot is 50% grey the same displacement values will be halved so 0.5m or 500m.

(the above is true for "clamped" values that go from 0% or black to 100% or white/colour. Un-clamped values can go below 0% black and have a negative displacement to over 100% white and have an extreme positive displacement, hint: avoid un-clamped valued for displacement in most cases)

So changing the scale or size of a PF will have no effect on the amount of displacement on an object, although it will change where the ups and downs occur.. However it is uniform so if you scale your object by 10 all you have to do is multiply the displacement by 10.

Hope this helps.

[René]

Thanks for the answer. So I do have to change the displacements manually; I was afraid of that. I wouldn't mind if there were like 5 power fractals but there are a lot more. I run into this problem frequently when I want to reuse a texture on a different scale, it's so much work that it is easier to start from scratch. To bad that there isn't a node that takes care of this automatically; it would make life easier that's for sure.

[WAS]

This is why I believe basic settings like this in nodes should handle input. Positions,scales, etc should allow scalar and vector inputs.

When it comes to packaged/sold terrains and functions, they would prove invaluable to the end-user for control without exploring dozens and dozens of shaders.


I will add though... you can transform your entire displacement setup to scalar/vector and scale Than you have control over displacement multipliers again when rebuilding.

[WAS]

Here is another example, default scene at 0.1% of it's original scale. It's important to note that your displacement multiplier should match your scale for accurate results.

I didn't alter the fractal warp so it's applying at it's original scale, woops. Oh wait, no I guess fractal warp was scaled too. I'm crazy.

[Oshyan]

This is why I believe basic settings like this in nodes should handle input. Positions,scales, etc should allow scalar and vector inputs.

Yep, agree. However with the current engine *each* setting that we want to be exposed for input from other shaders needs to be manually coded, as far as I understand. So making *all* settings pluggable would be a huge undertaking. There might be a way to generalize this but I would guess it would require some other redevelopment of existing back-end systems, and might also have an overall performance impact. So for now we expose inputs based on how valuable they'll be to people. We'll take this into consideration.

- Oshyan

[WAS]

This is why I believe basic settings like this in nodes should handle input. Positions,scales, etc should allow scalar and vector inputs.

Yep, agree. However with the current engine *each* setting that we want to be exposed for input from other shaders needs to be manually coded, as far as I understand. So making *all* settings pluggable would be a huge undertaking. There might be a way to generalize this but I would guess it would require some other redevelopment of existing back-end systems, and might also have an overall performance impact. So for now we expose inputs based on how valuable they'll be to people. We'll take this into consideration.

- Oshyan

Yeah I believe Matt explained this before when I initially requested it. Which is unfortunate. It would probably be beneficial to start looking towards a new framework (especially considering also cross-platform scenarios) for the future of TG, but I understand that would be a big undertaking. One day we may see it, which I think would open up a huge avenue for dynamic flow.

[Tangled-Universe]

+1 for having the transform nodes allow for scaling displacement as well. That would be *extremely* useful in many cases.

[digitalguru]

just reading this and had a thought - rather than manually coding inputs to all the shaders, could an expression system work better?

so you could right click on a nodes parameter value and enter text, so for example - node1.paramaterX could equal
;

(node2.parameterY * 2)

[WAS]

just reading this and had a thought - rather than manually coding inputs to all the shaders, could an expression system work better?

so you could right click on a nodes parameter value and enter text, so for example - node1.paramaterX could equal
;

(node2.parameterY * 2)

Markup for a node system? That just sounds odd.

[Oshyan]

Tell that to SideFX and Houdini.

- Oshyan

[WAS]

Tell that to SideFX and Houdini.

- Oshyan

I literally just gone using their trial and seemed to be a normal node system.

Do you mean the geometry system? At which point, they're just operators.

[Oshyan]

There are tons of fields throughout Houdini and you can use all kinds of references, math operations, etc. etc. in them (in text). Like Terragen's ability to use values outside of "normal" settings in the slider ranges (e.g. negative radius for planets), it's not immediately obvious, but for those who know how to use it, it can be incredibly, incredibly powerful.
http://www.sidefx.com/docs/houdini/network/expressions.html

- Oshyan

[WAS]

Ah, well that's just raw haxe scripting (subset operators of the high-level programming language Haxe). Wouldn't really be a markup representation of TG functionality, but just exposing TG's scripting. Houdini uses Haxe, and employs Haxe Scripting for hooking. This can be done by just allowing raw programming input in some plane which drives all of TG -- unless Matt really wants to switch languages and rebuild TG.

This is already somewhat available with the SDK, it's just not dynamic within TG.

[Matt]

What does any of this have to do with Markup?