Control a Transform Shader from external input?

[digitalis99]

I'm working on several projects that all involve a lot of water animation.  Rather than setting up keyframed Transform Shaders for each project, I'm trying to create a more automated network (using get frame number) I can just drop in place and attach to the water node.  I have two problems:

1) The Transform Shader has an input node, but it doesn't seem to do anything with it.  I'm assuming it expects a vector input, hence my network setup, but nothing I've done sets the translate values....even using a constant vector.

2) I only want to translate along one or two axis'.  It's not clear to me how I could take the output of the scalar to vector and make one or more of the axis values constant while allowing the others to change as the frame changes.

I'm really new to TG2, so go easy on me.

[dandelO]

Have a look here at Hetzen's get frame animator in my 'rescale noise' thread, that should give you a good basis to start from.

http://forums.planetside.co.uk/index.php?topic=12144.msg122215#msg122215

[digitalis99]

That answers my #2 question perfectly, thanks!  As for #1, though, I'm not getting anywhere.  Is there no way to translate a PF via any mechanism other than a keyframed transform shader?

[Tangled-Universe]

I'm probably a bit dense here, but to me question 1 and 2 are the same and Martin gave you the answer to both.

His answer provides a way to use the redirect shader to selectively transform along one axis.
Using a multiplier function together with the get frame function you can control the speed of translation.

I use that method to translate water/clouds at a constant rate, based on the get frame input.

[digitalis99]

I understand that's what it's "supposed" to do, but it's not...at least for me.  There must be something obvious I'm missing.  The PF's are affecting the water shader, but they aren't being moved as the frames progress.

[digitalis99]

I'm losing my mind, here.  I've read the shallow node reference till my eyeballs bled.  Pretty much enough info in there to frustrate instead of help.  I read through the entire thread dandelO referred to.  I inserted the clip from that thread into my node network and tried a wide variety of network configurations to get this darn PF to move, but I haven't gotten it to move at all unless I insert a transform shader between it and the water shader (like in my original attachment) and keyframe the transform shader.  I've tried to input a variety of different values to the input of the transform shader, but I'm convinced the input to that shader does absolutely nothing (would be nice to have a definition of what it does, if anything, in the node reference).  I tried the recommendation (thanks Tangled) of using a Redirect shader instead and feeding scalar values to one or more of the axis' inputs.  That resulted in no translation over time as well.

Clearly, you guys all understand how this works.  I understand and completely agree with the theory that you guys have pointed me to thus far, I just don't see it having any effect at all.  Surely I'm missing something painfully obvious to you, but oblivious to me.   

Any chance someone could throw me a bone in the form of a clip file?  Once I see a functioning example, I'm sure I'll be able to figure out what I'm doing wrong.

[dandelO]

I see the problem now and I think I can clear up your confusion here. I think you might be misunderstanding the function of the 'input' node of a transform shader.
The actual 'input' node serves only to connect the transform shader to an existing network. The transform shader must be keyed to create a transformation of any other node that feeds it's 'shader' input.

In this manner, a transform shader is a shader that basically does in one node what the get frame animator does, but there are problems with this. The main problem/difference is that the shader *must be keyframed over time. The problem you face with keying a transform shader is that there is only one(currently uneditable) interpolation method for motion, which creates an ease-in/ease-out effect. This isn't always required and that's where, and why, you'd want to use the 'get frame number' method, instead. It doesn't have this ease-in/out problem as it moves everything according to frame number in an equal measure.

Again, the 'input' of a transform shader simply allows you to connect the shader(that is plugged into the 'shader' input) you are transforming with keyframes to be connected to your node network. There is no way that I know of to drive a transform shader to change over time/frames by an outside source, manual keying is your only option.

The get frame number method allows you to input a set of constants that will change a function in a set and fixed manner over time, according only to what frame you are currently on and the value of your input constants. In other words, *THE* reason to use the get frame animator method is to get around the currently uneditable interpolation method that Terragen applies to keyframed parameters.

When the time comes that Terragen allows you to control the motion interpolation(the next major update, I believe), then you could keyframe a transform shader and not have to worry about this ease-in/out problem, removing the need for the get frame number functional method for consistent movement at all.

[dandelO]

Yes, after having had a look at your attachment, you are trying to drive transform shaders with the function network into their inputs. It won't work that way, your only method at the moment is to transform the shader feeding the 'shader' input by keyframes. Or, to simply use the get frame number on its own to move your shader/function positions.

[Matt]

You can transform a shader by function nodes if you use the Warp Shader. It has a 'warper' input which takes any shader that can perform displacement. If you have a displacement shader that represents the offset (translation) you want to apply to your shader, then the Warp Shader will translate the shader by that displacement.

In Terragen 2.3, the general approach is this:

1) Create a Redirect Shader. This is a shader that can displace in 3 directions: X, Y and Z. Create 3 "Displacement Shaders". Plug a Displacement Shader into each of the 'X shader', 'Y shader' and 'Z shader' inputs of the Redirect Shader. You now have a 3D displacement shader where you can specify the displacement in X, Y and Z.

2) Plug the Redirect Shader into the 'warper' input of the Warp Shader. Plug the shader that you want to be transformed into the 'shader' input of the Warp Shader.

3) Function nodes can now be fed into each of the Displacement Shaders that feed the Redirect Shader. Those functions will define the translation that is applied to the shader.

In future versions we will have a Vector Displacement Shader which can be used instead of the Redirect Shader and 3 Displacement Shaders, making this process a bit simpler.

A note about the main 'input' input of the Transform Shader, Warp Shader, and most other shaders (red nodes). Most shaders in Terragen are designed to operate as layers upon previous layers. The 'input' is the previous layer. The Transform Shader might be transforming shaders that layer themselves over the previous layer. The Transform Shader's 'input' is the previous layer.

Function nodes (dark blue nodes) operate differently. Their 'input' is usually the primary input for the function they perform.

Matt

[digitalis99]

Thank you, thank you, thank you!  That cleared up a lot of confusion for me.  I finally accomplished what I wanted to accomplish.  Once I have the results tweaked to what I'm looking for, I'll post the resultant clip here.  Hopefully someone would find it useful.

@Matt- Yes, I'm glad you realize having that many nodes to accomplish a relatively simple goal is cumbersome.  Your explanation of what the input does on most shader nodes is great.  That should be added to the node reference in some form, I think, if for no other reason than to keep people like me from asking questions.   

[AP]

That Vector Displacement Shader concept sounds great as there are other apps that have this already. It would certainly make for adding details to my stones a lot quicker as well.   

[digitalis99]

As promised, I've messed with my node network enough to say it looks reasonably good, so I'm posting it as a clip.  Simply load the clip and attach the output of the lower-most merge shader with the input of your water shader.  Don't forget to disable the wave/ripple generation of your water shader, as only the color and reflectivity needs to be added by that.

The animation is generally self-perpetuating.  You define the velocity and direction of each of the sets of ripples.  At 30fps, this looks reasonably good.  Sure, there's room for improvement, so please comment or post back your modifications if you make some that look cool.  I designed this to be as plug-and-play as possible.

The settings in the clip are for very calm, open water movements.  I'm sure you can modify them to get rougher waters.

Remember, I'm still quite new to TG2, so if you have any constructive criticisms, I'm all eyes.  Of course, thanks to those in this thread and others that supplied most of the knowledge I gained to get this far.

[Hetzen]

There's a good understanding of the concept there Digitalis. I've not given this a sequence render to check out, but I've looked at your network.

A couple of things that will help this out. One, Vector to Displacement will cut down on the Redirect node clutter, although the principle is exactly the same. Two, and probably more importantly, it would be better to create your wave displacement shape outside of the six water nodes. Have a go at using six PFs that drive one flat water node. The water node has a lot more calculation than a shape giving PF (depth and reflection being the heavy hitters) that will bog down render times. Best feed one water node with one merged displacement signal, than trying to combine six. This will mean you coming up with your own wave noise in the PFs, but that's quite easy to do. Best plug that into a planet input to get your shapes right, before using the water node to work out reflection/refraction/depth fall off.

All the best.

Jon

[Hetzen]

Sorry, I need to mention, that the warp shader works in colour space. Ie, it warps colour rather than displacement (although it needs displacement to feed it). You then use that colour shift as a feed into a displacement shader.

So if you replace your six water nodes with PFs, then you need to make sure you're outputting colour in those PFs, and it's a good idea to dial down the colour noise close to 1 rather than the default 5. Then feed that into one displacement shader, that then feeds into one flat water node.

Sounds confusing, but once the concept clicks, it's actually very intuative.

[Matt]

Hetzen, the Warp Shader warps both colour and displacement.