A while back when I was messing around with something I accidentally made a setup that ranged a noise from a start scale to an end scale with a smooth transition in growth. I didn't bother saving anything because it wasn't what I was after at the time and I thought, "Ach, I'll remember how I did this next time I need it..."
I can't. :(
So, the thing is this. I had a Voronoi which started at a default scale of 1m at the origin and grew outwards to a scale of 100m(say) over a smooth gradient.
For the eyes of me, I can't remember how I done it. The closest I can get to what I'm talking about is something like this;
[attachimg=#]
[attachimg=#]
Using a modulo scalar is subdividing the cells themselves but not the scale of the actual noise, the Arctan2 scalar is creating the gradient. I'm not sure if I used either of these nodes before when I had it working! ::)
The network I vaguely remember having was a bit different than the simple one here that shows the above noise, I know I had a couple/few more function nodes but I am at a complete loss as to what they were, or where they were.
______________________________
This pic' is just a screen capture of a default Veronoi noise with an inaccurate pinch filter on it that crudely shows the effect I mean, if I'm not being clear above...
[attachimg=#]
Cheers, if anyone can help. :)
You can see a little better with a Perlin noise and modulo scalar where I am stuck.
[attachimg=#]
It's only subdividing the pattern as it appears according to the gradient, like it's just a distribution shader, not actually altering the scale of the pattern itself.
You might guess that this is part of the 'other idea' I mentioned in the waves thread I posted a few days ago. I figure, if I can make it work correctly again, I can use it to modulate the scale of a sin function according to the distance of the gradient, i.e. near waves would be tighter and at the starting scale, whilst the further into the distance, the wider and calmer the wave would become, towards the end scale...
Am I talking crap? Maybe confused that I had it working before and it isn't actually possible? I'm 99% sure I did.
It's usually that 1% that bites my arse, though! :D
With your waves Martin, you can use a bias scaler to get a pinch on a range, then use the modulo to subdivide that by a fraction of 1. Then use that to drive your sin function.
I'll have a think about your scaling on noise and post back later.
I don't remember. Did you post anything here on the forums? Maybe we could do some UberSearches to help find more information.
I think I remember that thread....It was about different sizes of fake stones and I think you showed a function which did what you're describing now...
Let's search for it...
Haven't found yet what I have in mind, but this might have pointers as well:
http://forums.planetside.co.uk/index.php?topic=1414.0
http://forums.planetside.co.uk/index.php?topic=3283.0
I'm just curious what kind of use you would have for this? what exactly could be done with this? I'm really not a math person so maybe thats why.
Its really cool though, so dont get me wrong.
Cheers, folks. Appreciate the help. :)
Hetzen, great! I look forward to your experiments.
While you're here(completely different subject)... On at least two occasions that I've posted animations here we got onto the subject of the key-frame interpolation easing in and out and you tried to help me with a nod towards the 'get frame number' node, which I think you said should feed a simple constant scalar that would then drive the camera without any easing. I've tried repeatedly to make this work but never to any use. Can you shine any light on your method?
Calico/Martin, I never posted the thing I was talking about above anywhere, don't think I even spoke about it at the time. I was playing with functions trying to make a spiral noise to use as a cloud shader for some whirlwind tests, I gave up on function nodes and just used a spinning simple shape shader and cut into that shape with shaders to make a cloud mask(I posted a thread called '30f whirly' around about that time).
I remember not having much success creating a scaled spiral noise but I did come across the radial method I described above. Brilliant! I thought I'd easily remember what I did and didn't even bother to save it, let alone post it here. Sh*t! :D
I'll have a trawl through these threads, Martin, cheers...
Quote from: Themodman101 on April 18, 2011, 11:50:09 AM
I'm just curious what kind of use you would have for this? what exactly could be done with this? I'm really not a math person so maybe thats why.
Its really cool though, so dont get me wrong.
I'm no maths guy either, Themodman, which is why I ask the question now. I'm sure some of these guys are robots in here! ;)
The reason I'm trying to scale a noise over a range is to use as a basis for a wave function to use on a water object.
The scale of small breaker waves on the shore would increase over the gradient making the next wave behind it wider, the following one wider still, etc. I'd make a gradient that fitted the scene. The appropriate amount of displacement would be added to each increasing wave to make the nearer ones rougher and the further ones smoother(but that's the easy part).
I'm just using a Perlin noise and an Arctan2 gradient here to show what I mean, I haven't put it into a scene yet, still on the shader-preview windows stage, as you can see from the screenshots above.
Cheers! :)
Good post from Matt from one of the threads Martin linked. ^^
QuoteQuote from: Matt on January 29, 2008, 11:04:21 AM
The noise scales itself by multiplying the position input by the inverse (reciprocal) of the scale. When the position input has a large value (i.e. it is far from 0,0,0), small changes to the scale have large absolute changes to the position because it is a multiplication effect. Therefore whatever function you use has more effect on the noise shape at larger distances from the origin, regardless of what function you use.
It is possible to cancel out this effect by dividing part of your function by the distance from the origin, but you need to make sure that there is also a constant component to your scale function which you don't apply the divide to. Difficult to explain without providing an example... but hopefully you can see what I mean.
Matt
I'm not worried about the continuous distortion away from the origin, this would be easily masked to a localized area for what I plan anyway.
Cheers to Mogn(the robot version of Goms, I believe) for the info on the scale-by-altitude thread, too. I'll probably not get back here until tomorrow as I'm busy tonight so, thanks everyone in the meantime. :)
I think you are following the wrong approach with the simple shapes, unless you can bend them alongside the coastline (try the warper with the terrain as input for the redirect). The get altitude, then sinus, then subtract from terrain works better IMHO. Only if you just need a straight beach, it would probably work.
Cheers, man. I'm not using simple shape shaders any more, it's all changed.
I'm using a sin scalar now to make the waves. The scaling of this sin function from point A to point B is what I want to fix here.
Say I have my waves running left to right along the X axis, I want to then be able to 'grow' their scale along the Z axis, according to a gradient.
The attached TGC will shift the noise left.
To change the direction the noise travels, enter a positive or negative value in the constant vectot 'Direction'. ie -1,0,0 will move the noise right. 0,-1,0 will move it up. 0,-1,-1 up and forwards.
The way this works....
Get Frame returns a single number (scaler), and we can multiply the effect the Get frame has with another scaler. So entering 10 in the speed multiplier will mean what ever the Get frame is, our out come will be 10 times that. So rather than move 1m per frame, we are now moving 10m per frame.
When you multiply a Scaler (in this case 10 on frame 1) with a Vector, the single number of a constant tries to multiply x,y,z of an input vector by that amount. So at frame 1, 10 will be multiplied by our 'Direction' vector in x,y,z (-1,0,0), which gives a return of (-10,0,0).
Get position returns a vector value for x,y,z. So when we add the vector worked out above, we get (x-10,y,z) on frame 1. On frame 2 the answer will be (x-20,y,z). And so on.
When you plug that into a perlin function, it will offset what ever point the get position is looking at at render time, by -10m in x, in effect shifting the perlin pattern left.
Why is this usefull?
Well, because 1/ there are no keyframes to worry about, just direction and speed. 2/ TG automatically adds an ease out and in on each key frame, which is no good if we want to animate something that has a constant speed, like clouds, water, etc.
As for your scaling noise from a central point, not found anything yet.
Quote from: dandelO on April 18, 2011, 01:36:51 PM
Cheers, man. I'm not using simple shape shaders any more, it's all changed.
I'm using a sin scalar now to make the waves. The scaling of this sin function from point A to point B is what I want to fix here.
Say I have my waves running left to right along the X axis, I want to then be able to 'grow' their scale along the Z axis, according to a gradient.
I've gone a long way into doing what you're describing here Martin. You're on the right tracks. But this is just the easy bit. Wait until you get into backwards moving white horses. Lol.
Something like this:
Using a constant for scale input to the noise.
Modify the vector (limit to a range).
Abs(vector) for 4-fold symmetry.
Ahh, great. Thanks very much, Hetzen. That explains why I wasn't able to move my CAMERA with the get frame node! :D
I had it all mixed up in my head, thinking that you were converting the actual keyframe with the 'get frame number' into a steady movement with a constant, and not just the element of the scene that's moving, I get it now, it's really great, cheers, man!
Mogn, that's cool but it isn't quite what I was meaning I don't think. The pattern isn't actually increasing in scale from the origin outwards. I am having a look at the file you uploaded in this old post; http://forums.planetside.co.uk/index.php?topic=1414.msg14135#msg14135
This seems to be more in line with my problem but where you've altered the noise scale based on altitude, I would like to alter the scale based on distance from the origin(or even better within a 'point A' to 'point B' range).
Cheers folks! :)
With a look at Mogn's scale-by-altitude setup I've had quite a bit of success!
I can now rescale noise along any direction so that's great. Cheers, man! :)
[attachimg=#]
[attachimg=#]
[attachimg=#]
[attachimg=#]
[attachimg=#]
[attachimg=#]
Getting there slowly...
Cool!
Could you post a node view for the first one,please?
[attachimg=#]
It really distorts away from the origin badly. In the snapshot the camera is 50m above the ground, any further and the stretching overtakes the scaling.
Or use a divide scalar with an input of 10 instead of multiplying .1.
Probably makes more sense that way.
Thankies!
At least it's a very promising starting point and it shows that
it's possible,so let's play. ;)
Nice progress , DandelO :)
I wonder if, replacing the gradient with a Perlin somehow, we could use it to vary the scales of a PF.
Getting a bit sidetracked from the whole point I was asking about rescaling noise but it's good fun...
[attachimg=#]
[attachimg=#]
Nice work on all of these! The last one looks really cool!
A big shiny one then!
That one is a bit ragged round the edges ^^.
Last one for now.
There's far less noise here. It's a smaller image but took the same time as the big one to render. I'll do a bigger one another time at this setting.
[attachimg=#]
[attachimg=#]
Would like to touch it :) Looks very nice DandelO!
And thanks for the file!
This is very interesting, Martin. You could well be doing modern church windows! Push a cave into a vertical wall, inset a vertical plane, add a light inside the cave and project your wonderful (and perhaps more colorful) pattern on the plane...
Again very nice!
Didn't find that much time yesterday,but i think i could improve the effect a little bit
by reducing the .1 to .05 or even .025 and then connecting the mixers output to an
add scalar with a constant scalar set to 6 or 9.At least it increased the area of the
effect.But as usual the further away from the 0/0/0 point the more stretching.
Gotta play some more.
Thank you for sharing the tgc file. I am beginning to understand the function nodes, but I am a long way from using them effectively.
Weird render settings!
To get an extremely clean looking function render in the very small or sharp details I've found it best to use 'Ray trace everything' in the renderer, even an AA of 2 will give cleaner results than a render detail of '1' without RTE. All the flat 2D images have AA=2
The problem using RTE is that once you introduce displacement, the surface of the planet, even at render detail '1' is terribly optimized.
RTE, detail=1, AA=4...
[attachimg=#]
To get around it and have a lovely smooth RTE render with displacement you'll want to first disable GI relative detail, create a fill lighting instead(because of the next step) and then raise the render detail to way past '1', until you find a good balance of displacement and subdivision.
The 1280px image on the 2nd page was RTE, detail=8, AA=4. The 700px image was RTE, detail=10, AA=4.
You'd be alarmed using detail '10' in most cases but here it's the cleanest option and it's still fast to render since there is no GI used, the detail slider is really only being used to smooth the planet surface and do the shadows.
Last one of these. Rescaled
RTE, Detail=10, AA=3. Still a little raggedy at some of the extreme edges, but nice and smooth displacements.
Try it on clouds ;D
Not sure DandelO but i think it would be smoother and maybe render faster too.
Yeah , i see clouds everywhere recently ::)
Good idea...
Quick clouds.
[attachimg=#]
How is the render time comparing to the planet object ,DandelO ?
Depending on the clouds, it's both quicker and longer. At the density above, which was edge sharpness=100 and density=1, it would take much longer to do a big render than the planet. But with less samples required for less dense clouds, it's much quicker than the planet and you don't need to increase the render detail. A balancing act...
Quote from: dandelO on April 20, 2011, 02:25:03 PM
Depending on the clouds, it's both quicker and longer. At the density above, which was edge sharpness=100 and density=1, it would take much longer to do a big render than the planet. But with less samples required for less dense clouds, it's much quicker than the planet and you don't need to increase the render detail. A balancing act...
:) Curious about the new bigger one with greater detail!
Quote from: dandelO on April 20, 2011, 02:25:03 PM
Depending on the clouds, it's both quicker and longer. At the density above, which was edge sharpness=100 and density=1, it would take much longer to do a big render than the planet. But with less samples required for less dense clouds, it's much quicker than the planet and you don't need to increase the render detail. A balancing act...
Is that *with* raytraced atmosphere, and if so what sample level and antialaising value?
- Oshyan
Yes, with RTA. The small one with clouds above took me about 10 minutes for me to render on 2 cores. There were 2 cloud layers, around 60 cloud samples each which was quality=1. AA was 4 with 1/16 sampling.
I edited the clouds and managed to bring it down a lot by lowering the quality and densities but I haven't optimized a full render for clouds yet.
The first 700px surface image on page 2 took 15 minutes to render with ray trace everything and the render detail tweaks I mentioned before.
Cool, thanks for the details. I'm always interested in how these settings affect various scenarios, especially unusual ones like this. There are settings coming in a future update that will allow you to tune the raytraced terrain detail (including sub-surface detail!) separately from master detail, thus allowing you to more easily use GI, or get more detailed underwater terrain without tricks. In the case of your RTA terrain renders, you would just increase the detail multiplier for raytraced terrain.
- Oshyan
I know, I know! Last one, for now.
I don't think this shader is on the periodic table. ;)
Almost got rid of the jaggies with render detail=12 and AA=6. I used 1/16th minimum samples, I wish I could have left that at 1/4 or higher but the 15 minute 1280p render from page 2 has turned into a 1h15m render at this setting already. Maybe AA=4 with max samples would do it, I might go again... :D
[attachimg=#]
Bigger here (http://fc02.deviantart.net/fs70/f/2011/110/5/b/rescaled_v3_by_dandel0-d3egm8t.jpg).
8)
In case you're still interested this is what came up with
[attach=#]
[attach=#]
[attachimg=#]
750m+1500m camera height btw.
I hope it'll be useful for you or anyone else.
Cheers,J.
Just a note on the above render settings I posted.
Render detail=12, which was what my last render setting ended up being for smooth displacement on the planet surface in this scene, is equivalent now (in TG2.3) to; Render detail='1' + Ray detail multiplier='4'.
* This still seems to lengthen the GI prepass time at the moment but nowhere near as much as the previous 2.2 settings of 'render detail=12'. (4x as quick as that would be? I think so...) So, still best to keep GI detail relatively low, or off completely but it's definitely much more usable now if you can balance it out, I'm loving it!
I can ditch the fill lighting in this scene easily now, anyway.
Great feature, can't wait for the element-based ray detail multiplier that you mention, Oshyan!
Quote from: dandelO on April 21, 2011, 07:40:51 PM
Great feature, can't wait for the element-based ray detail multiplier that you mention, Oshyan!
I believe you're using what I was talking about...
- Oshyan
Ahh, right. I thought you meant in a future update there would be a ray detail multiplier for each object in the scene, like one on the lake object, one on the planet, one on the plane etc. My mistake.
I still find I'm multiplying GI prepass time when I edit the ray detail multiplier, do you have a list of all the specific elements this parameter affects?
I'm guessing; Subsurface transparency detail, reflection detail, RTE subdivision of planet/sphere/lake objects/etc. and their shadows.
The part I don't quite understand is this, at default RDM settings(0.25), is this equal to a 1/1 balance between render detail and GI relative detail? I ask because raising the RDM is also raising the GI calculation time and I'm not sure. For instance, if I go for render detail=1 GI=1/1 with ray detail multiplier=1, does that mean that the GI is now relative to '4'?
And sorry for the mix up, I just thought you'd meant that it would be an element-based parameter at a later time. It's brilliant, regardless of that! :)
To the best of my knowledge your list of what it affects is pretty complete. The default RDM setting is what everyone has been working with to this point and it's responsible for the lower detail you sometimes see underwater. Increasing it to 1 gives a theoretically equal relationship with main detail, so e.g. terrain rendered with Raytrace Everything would then be equivalent in detail to normally rendered terrain, or underwater and reflected surfaces would have the same level of detail as other surfaces. I'm not sure whether it should be affecting GI calculation times, but as far as I'm aware it does not influence the GI Relative Detail *except* likely in areas where the raytracer was always being used (i.e. GI calculations for raytraced scene elements). The latter is just a guess though. I'll see if Matt can clarify.
- Oshyan
Cheers. And that sounds about right actually, since this entire surface is rendered with the ray tracer it stands to reason that the GI for that would be impacted, too.
Still, much quicker than before with the render detail tweak so, great!
Sometimes I just need it pointed out to me. :D
The GI prepass is rendered using the ray tracer, similar to ray trace everything. Ray detail multiplier affects the detail in the surfaces in this pass, so it does affect render time.
Ah right, makes sense considering you're using RTE, of course!
- Oshyan
Quote from: Matt on April 21, 2011, 08:25:57 PM
The GI prepass is rendered using the ray tracer, similar to ray trace everything. Ray detail multiplier affects the detail in the surfaces in this pass, so it does affect render time.
Does it affect it as much as main detail? My impression is no...
- Oshyan
Quote from: Oshyan on April 21, 2011, 08:27:08 PM
Quote from: Matt on April 21, 2011, 08:25:57 PM
The GI prepass is rendered using the ray tracer, similar to ray trace everything. Ray detail multiplier affects the detail in the surfaces in this pass, so it does affect render time.
Does it affect it as much as main detail? My impression is no...
- Oshyan
Definitely not. The equivalent settings,(the default RDM setting and a final render detail=12) would be impossible for me, even at GI=1/1.
It's
so much quicker with just the RDM increased appropriately. :)
I manually inserted the Ray Detail Multiplier into the renderer, and set it to 1. Is that the way to do it or unnecessary?
Guys please excuse the ignorance but I 'm a bit lost - where is this "Ray Detail Multiplier" you 're talking about ? All this talk has me eager to try it myself ! :)
thanks,
nick
It was a feature for alpha 64-bit testers. Never got it work, as I have a 32-bit version. I don't know if it's officially included now. If you cannot find it, best forget about it.
Ah ok, thanks for that Dune, I thought I was (not) seeing things ;)
I only use the 32 bit version, too.
The RDM is in the render node's internal network in a separate node called 'render subdivision settings', you'll find it next to the 'render pixel sampler'.
And it works a treat! Brilliant feature that I've wanted for ages.
Does anyone have any information on the other render subdivision settings; 'fully adaptive', 'force all edges' and 'jitter shading points'?
I've played with those settings since Oshyan posted a .tgd which included the (experimental at that time) 'render subdivision settings' node a few months ago. I couldn't find any difference in output or render time with different combinations when placing it inside the default micropolygon renderer, which is the only one I've played with so far to test it out, I didn't use the ray tracer.
Is this a ray tracer only set of options? I'd love to know how they work, the names of the options suggest that you could sacrifice some quality for a smaller render time with fully adaptive selected or, vice-versa by forcing all edges. Probably all wrong.
Like I say, I'd just like to know how they work...
The Render Subdivision Settings node is found inside the Renderer nodes but I don't think it shows up by default at present as the settings are very experimental still. TGDs with that node available have been shared on the forum however and you can copy/paste it inside your Renderer node's internal network to get access to those setting.
dandelO, many of the settings in subdiv settings node were added to address some issues in animating TG scenes. So that's mostly where it's useful to tweak them (aside the Ray Detail Multiplier). We're still working on fine-tuning how they work which is why the node is not included by default. When it's officially included and available we'll document those settings. For now it's a fairly safe assumption that if you're not animating, you can leave all by RDM at default.
- Oshyan
Ah. When I read the change log say... 'which is currently a hidden node', I thought that meant it was just tucked inside the renderer hidden from general view, not that it wasn't actually visible in a .tgd. Sorry.
It's fine, it's not a secret really, just not made generally available. If people have access to it and want to use it, that's fine. Just know that doing so is unsupported and "at your own risk". ;)
- Oshyan
Quote from: Oshyan on April 22, 2011, 05:32:04 PM
[...] many of the settings in subdiv settings node were added to address some issues in animating TG scenes. So that's mostly where it's useful to tweak them (aside the Ray Detail Multiplier). We're still working on fine-tuning how they work which is why the node is not included by default. When it's officially included and available we'll document those settings. For now it's a fairly safe assumption that if you're not animating, you can leave all by RDM at default.
Oh great - now I 'm even more intrigued ! Seeing as I 'm in the middle of actually setting up an animation scene... :)
I can't wait for it to be available, even as a clearly-stated
unsupported, experimental feature.
nick