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.
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
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?
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.
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.
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. ;D
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.
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.
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.
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
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. ::)
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. ;D
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.
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
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.
Hetzen, the Warp Shader warps both colour and displacement.
Thanks Hetzen. I originally did a lot of work using PF's instead of the water shaders, but could never get anything I liked. I tried all the different Perlin flavors, different scales, and a few other things I don't understand just for the heck of it...it only resulted in stuff that didn't look right. After I put water shaders in place of all the PF's I had, it looked much better (probably mostly because I didn't understand how to manipulate the PF's to get things to look just right). Render times didn't seem to take any hit at all, at least with a scene containing only a view of water edge to edge. Maybe the render times would be worse once atmosphere and objects were added?
If you have any PF's that you've used that you liked the result of in comparison to actual waves, I'd love to see them. ;D
BTW, I found, for the animation to look somewhat reasonable, whatever was used for the displacement shader had to contain relatively little noise. Noise moving in a constant direction on the surface just looked fake. Smooth undulations moving in the same direction were much more passable.
Quote from: Matt on December 01, 2011, 05:48:55 PM
Hetzen, the Warp Shader warps both colour and displacement.
I didn't know that. I thought the warp shader only affected colour space. And redirect affected only displacement.
My appologies.
Just to illustrate my point a little regarding using moving PF's as the wave generators, go to this Vimeo video to watch the output. Far away from the camera, it's somewhat convincing. Close up, though, it's definitely not.
http://vimeo.com/33034544 (http://vimeo.com/33034544)
It would look a lot better if you put a small value in the Y of your constant vector, instead of 0. This will make your wave peaks move up and down, as the fractal noise passes through the water plane.
I never thought of that....which is why you're here! Thanks!
"Captain, his pattern suggests 2 dimensional thinking..."
In messing with Hetzen's idea, I realize I'd like to do something but don't know how. What's new, right? The ridges formed by the noise are far too sharp, seemingly no matter what the noise flavor. How does one go about rounding off the ridges to make the waves more sine like rather than curved triangles?
Maybe just some large a bit stretched and warped perlins would be best as main waves, perhaps play a little with buoyancy, noise variation and clumping (even negative or quite high values sometimes have interesting effects). Then have the some smaller waves only raise in height when the big wave is highest, but keep their movement small or none. The smallest may be ridges.
I studied your setup, and changed according to Jon's ideas. I'm not (yet) really into animation, but it looks interesting enough to have a go at it some day. Thanks for sharing anyway.
I actually figured it out last night. The key was to use "unclamped multifractal" as the noise variation method. That smoothed out the transitions perfectly. I've started a thread over in image sharing to continue development of this process, since my initial question(s) have been answered here.
http://forums.planetside.co.uk/index.php?topic=13608.0 (http://forums.planetside.co.uk/index.php?topic=13608.0)
Haven't had a look at your clip, digitalis99, but you seem to have got things sorted out now by the looks of things.
I've been doing much the same thing in the last couple of weeks with the noise constantly moving over the plane, as Hetzen mentioned.
Two transform shaders and a single fractal have proved quite useful. An initial wavy-type fractal which is moving along on all 3 planes, with a constantly rising, or falling, Y motion so that there will never be a repeat of the wave pattern. The second transform shader simply moves/shrinks/shifts the initial fractal in the opposite direction, giving more octaves to the surface and a mask for foam to follow(a secondary fractal but blended by the first set's colour output), and also means there's less to control, instead of lots of fractals shifting over time. If I get any decent sequence rendered I'll post to the forums, I have literally 10's of different wavy water .tgd's(as I'm sure a lot of us do here), each have their own merits and downfalls, the trick is to find that one magic setting in the easiest manner and then we'll be cooking! Who'd have thought such a seemingly simple looking effect would prove this hard. Proper animated water, with foam, breakers and constant random motion is probably the TG2 Holy Grail. Well, one of them at least! We have many grails to find in here!
I'll have a look at your clip later on, cheers for posting! :)
* Something I've found that might be of help. I've found it a little easier to use the colour output of the water's wave fractal to drive a separate displacement function, as the displacement(from the displacement tab of the same fractal) can differ greatly to what you expect from the colour output. When you can see that your colour preview is working as expected to give a decent result for a surface, only to find that the displacements from itself don't match that pattern, it can make a lot more work than is required to bring them together. At least, I've found it more useful to simply use the fractal for colour only, anyway. *