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.
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.
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.
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.
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.
Quote from: WASasquatch on October 09, 2018, 02:15:37 PM
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
Quote from: Oshyan on October 09, 2018, 06:31:19 PM
Quote from: WASasquatch on October 09, 2018, 02:15:37 PM
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.
+1 for having the transform nodes allow for scaling displacement as well. That would be *extremely* useful in many cases.
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)
Quote from: digitalguru on October 25, 2018, 05:18:15 AM
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.
Tell that to SideFX and Houdini. :D
- Oshyan
Quote from: Oshyan on October 27, 2018, 03:56:29 PM
Tell that to SideFX and Houdini. :D
- 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.
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
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.
What does any of this have to do with Markup?
Expressions: Yes, some day.
Transform displacement, or Adjust Displacement shader: Yes, maybe soon.
Quote from: Matt on October 27, 2018, 07:47:54 PM
What does any of this have to do with Markup?
Markup is representing data in a human-readable flowing fashion. For example, the XML file is markup of a TGD project...
His original post representation classing example is similar to some basic markups for languages.
Digitalguru's example didn't uses classes. It was simply an "expression", using a node ID (the name of a node), a member parameter, a constant (2) and a basic math operation (multiply). The syntax looks similar to what's seen in many 3D programs. That's why Oshyan suggested you look at Houdini, because they do something similar.
Quote from: Matt on October 27, 2018, 09:46:22 PM
Digitalguru's example didn't uses classes. It was simply an "expression", using a node ID (the name of a node), a member parameter, a constant (2) and a basic math operation (multiply). The syntax looks similar to what's seen in many 3D programs. That's why Oshyan suggested you look at Houdini, because they do something similar.
Errr I've always been under the impression classes were classes because of the classification naming convention -- this just incorporating the data differently -- hence the markup part as it can be anything way you want it as it's just decompiled, broken up into it's bits for the master language (parsed).
Eg. A relating to B relating to C being passed X (or more directly C relating to B and so on to the compiler/parser
a.b.c(x)
Yeah I guess we're just describing them differently. I guess I thought you were talking about something else because you seemed to think Houdini expressions were very different from Digitalguru's example.
Quote from: Matt on October 27, 2018, 09:52:11 PM
Yeah I guess we're just describing them differently. I guess I thought you were talking about something else because you seemed to think Houdini expressions were very different from Digitalguru's example.
Indeed, similar to how houdini stretches expressions by it just being a visual representation of the haxe script, which is than a subset of the haxe language.
I'm more familiar with expressions within programing not this idea of expressions for nodes.
His initial example didn't lead me to a "node like" example in my head, but more scripting, at which point that's where I was referred in my head to the SDK, and the XML markup of TG.