Hi All
I'm not going to have a lot of time to work on this, but I came across the TGD from my rainbow test from a few years back (http://www.planetside.co.uk/forums/index.php?topic=3517.0 (http://www.planetside.co.uk/forums/index.php?topic=3517.0)) and thought I'd see if a slightly different approach. might work. The attached image is a very rough test render that is supposed to be a terrain and normal clouds (low fractal octaves for speed), with a green mist in front of it.
My original rainbow model used a hack of low cloud density combined with a high colour value to prduce a coloured cloud. 3 masked clouds of red, green and blue were then superimposed to produce to produce the full spectrum. This experiment attempts to colour a cloud via an external surface shader in the hope of using a single cloud for the colours of the rainbow.
1. The colour is created by converting a colour to RGB scalars, multiplying them by a constant scalar and then re-building the colour (in this case R0 G200 B0)
(previously done by setting the cloud colour to green and then increasing the number to 200)
2. This is then added as a child of a surface layer, blended by the cloud's PF and then fed into the cloud node
For the most part it appears to be working except for the normal clouds in the background which are showing through with complementary colours. I'm open to any suggestions on the clouds settings to try if this is at all possible. The attached TGD was made partly by trial and error rather then any knowledge of the specific cloud settings.
If it works, I can then replace the single colour with the conical rainbow mask. The new deg<->rad conversions are handy :) and have cleaned up the model a bit.
Ben
http://www.planetside.co.uk/forums/index.php?topic=10931.0
And ring constraints are indeed possible, as some recent posts have shown.
ooooo very interesting looking image. I missed it in the search results because of the title of the first post.
Dissecting the clip file now. Different method to mine but the clouds look good. My approach is easy to animate as the entire rainbow moves with the camera. Only the heading and altitude of the sun have to be manually updated if the sun moves.
You can add colour to clouds by replacing the cloud shader with a coloured powerfractal.
Quote from: Tangled-Universe on July 07, 2012, 03:49:00 AM
You can add colour to clouds by replacing the cloud shader with a coloured powerfractal.
But how do you set the colour of the PF to >1 ;). I tried creating a spectrun using mogn's gradient first but the green was not cooperating.
Anyway, it's probably about time I shared it too...
I played around with a twist of Mahnmut's idea, combining our 2 methods.
- second planet added at the camera position.
- distance of rainbow then controlled by cloud altitude and thickness
- easy to move planet with camera for animations
- looking vertically through the clouds avoiding possible altitude-related banding effects (just guessing here but it seems better in this regard)
- additional tweaks to "rain" PF to reduce noise and increase coverage which in turn required lowering cloud colour values which in turn will require some tweaking of the gradients (particulary the green and edges of the primary rainbow)
- The "non-rainbow" rain has been disabled as I deleted part of the mask and will have to re-crreate it.
Low res render below and the TGD. (just replace my terrains with a PF) The network is still a bit messy and I still don't remember exactly what everything does but I'm getting there. It's all spread out for development but should compact pretty well. Feel free to play and if you make any improvements or have any suggestions, post them back here please.
One possible tweak under consideration was adding additional cloud layers for yellow and cyan, mainly to smooth out the secondary rainbow when it gets faint. It's not 100% mathematically accurate but it's reasonably close. Primary and secondary with lightening inside primary and outside secondary.
Ben
I'm not sure what you mean Ben. You can have a colour >1 just by typing in a larger number.
Or, for the blue node fetisjists, add a multiply colour function after the powerfractal ;)
Quote from: Tangled-Universe on July 07, 2012, 05:14:50 AM
Or, for the blue node fetisjists, add a multiply colour function after the power fractal ;)
... The first image above has a grey cloud with a colour PF, but this produces odd effects with the clouds behind (pink in the first image) but not the landscape. The idea was there but it doesn't seem to be compatible with the lighting of the cloud model in TG unless there's some setting that avoids this. If it's possible it should mean being able to use a single cloud layer which in turn should speed up rendering.
In the second image the colour is defined in the cloud node. The high number makes it visible with the low density when it is lit, but in the shadow of an object or another cloud it "disappears" because of the low density. I think it was Matt that put me on to that hack.
The only colours I could set in the cloud node had to have RGB values at either 0 or 255 before increasing the colour number above 1 i.e. red, green, blue, yellow, cyan and magenta. Any other colour would turn to white when the number was increased.
Here's a render at detail 0.4 Renders a LOT faster than my original model although I think a lot of it was due to tweaking the PF for the rain.
With only the rainbow being rendered you can see what happens when the it passes into the shade. Note the absence of colour at the top of the rainbow. With the full model there would also be cloud around the rainbow (simulating the rain)
Thanks for the file Ben. Wanted to see into one of these.
Adding in 3 more cloud layers for the complementary colours.
Setting up the gradients is pretty basic math. Getting the cloud density, colour and response to direct light/shadow is the tricky bit.
* At very low densities (resulting from low values in the mask) the colour disappears, disrupting the smooth blending. That's why there are extra nodes to change the gradient to a range between 0.5-1. A suitable hack for RGB but for a 6 colour setup it would require an additional mask.. trying to do without it for now.[edit] Nope. it's needed[/edit]
* Make the cloud too dense and the colour persists in the shade
*Cloud colour too light the saturation drops, too dark and it just looks wrong (and increases the risk of banding)
Loaded a photograph into Photoshop to measure the colour bands to make the colour distribution a bit more realistic. Running a test render on a primary rainbow (render times are back up with the extra cloud layers)
Here's a small render of the 6 cloud version. It does produce a better gradation of colours and the problems confirm the workings of this hack.
* Note the banding/gaps in the rainbow near the top.. this will be reduced by making the mask range from 0.5-1 instead of 0-1 (or at least increasing it to something above 0) I had increased the cloud coverage by a small amount to try and compensate for this in this render but that was a bad idea.
* Increasing the mask minimum value will in turn improve some of the blending down at the bottom of the rainbow and hopefully soften the outer edges. The masking is there for it but it's rendering too sharply
* You can also just see the continuation of the inner lightened "rain" at the very top right. This area is shaded and it shouldn't be visible so I'll have to drop the density of that cloud.
I'll have to fix the mask range first before tweaking anything else, although increasing the magenta colour value is looking like a prime candidate. Something for next weekend :)
One last quick test rendered overnight. Extended the range of the mask for each colour to the next colour of the same type. e.g. Green drops to 0 where Red and Blue = 1, Cyan drops to 0 where Yellow and Magenta = 1
Detail 0.75, AA 4, default GI
This looks good, Bigben, and I imagine you could get much better render times now with the option to ray trace the atmosphere than you were before in those old rainbow test threads. I know there's been some debate about the speed/quality ratio of using RTA over standard rendered atmospherics but, because I'm such a skinflint for render time, I usually manage to juggle the customiseable AA sampling to get a huge increase in speed(only in some instances, of course) over the default rendering method.
I've been thinking, and I'll test in a bit... In one of these threads linked here, I was able to create the full spectrum with only one atmosphere node, instead of several clouds, and now, with the fantastic 'shadow funtion' option in the atmosphere, I think I might be able to constrain the visibility of that single atmosphere to a disc using altitude constraints and a transform shader to rotate those constraints onto the vertical, one node is far easier to piss around with than loads of coloured clouds. Hmmm...
* I also see Simius Strabus is making great progress with rainbows recently, too. We've found a few ways now that semi-work with convenience but there must be a nice, simple solution to this, juggling 7 clouds is a bit of a long way round, I think. An atmosphere with the spectrum contained within one node is something I'm pretty interested in playing with again.
The render times are much better now :)
The idea behind my original model was that it should be reasonably realistic, particularly for animations. Thus, using a cloud to simulate the distribution of rain, you can get a rainbow to show the variations in the cloud density and thickness. Since this model projects a conical mask outwards from the camera the density of the rainbow will vary with the thickness of rain (that is in sunlight) penetrated. Doing this with a thin disc would be very difficult. ... and a drawback of this is that you have to restrict the range of distances from the camera (previously done with a distance shader, now done with cloud altitude and thickness in the secondary atmosphere) If you don't restrict the range then the combined brightness of the rainbow all the way to the horizon can look odd.
In my first test scene for example the rain surrounds the butte so the rainbow is fainter in front of it because the rest of the rain is obscured by the terrain.
The one flaw with the current model I'm working on is that it doesn't observe the cloud altitude restrictions on the primary planet, so this would have to be defined separately. I'm thinking the rainbow model should not use an internal density shader for the cloud, but rather generate a full density rainbow which is then masked by the density shader of whatever cloud is being used to simulate the rain. This would also make it a much more portable model.
Juggling 7 cloud layers is indeed tricky for building the model, but once the right balance is found (if it can), then no more juggling should be required in use.
Once built most of the network doesn't need to be visible. Required inputs would be:
- altitude and heading of the sun
- position of second planet (if using this model, = camera position)
- connect the density shader used for rain
- probably output a mask for the rain density shader to obscure the rain replaced by the rainbow... (hmmm that gives me an idea)
- altitude range for rain
- relative intensity of secondary rainbow
In theory, once it's set up it would be very easy to animate as it simply follows the camera, always placing the rainbow in the correct location whenever it intersects with "rain". I'm happy to consider any cloud colouring model people want to share ;)
Checking Simius Strabus' posts, the gradation looks good and is probably easier in many situations, although it needs the math to get the right diameter and thickness (40-42° radius if you please) ;).
Slowly discovering more useful cloud settings. Most of the extra smoothness in this image was a result of tweaking the cloud settings and then readjusting the colour intensity to compensate for the change in density. I think this is getting pretty close and I have an idea for the violet end of the spectrum to try. The very faint top end is very nice now and I can almost live with the break up of the yellow and red about 2/3 up.
Most threads of the various rainbow attempts seem to at least have in common the need to add some extra density on top of colouring some clouds. My initial model added it to the colour mask but I'm doing it now with an additional cloud. I'm currently doing this via an additional cloud layer but in the end this additional density will come from the cloud layer targeted by the rainbow via a density mask that cuts the rainbow out of the cloud.
Your sophisticated approach is bearing fruit, Ben. This is going to be very good!
Thanks. I think I've almost got the primary rainbow nailed and the other components should be pretty straightforward after that. I know of a few limitations, mostly relating to adjusting the distance from the camera but that's mostly just a matter of convenience. Make it work first, then worry about making it practical ;)
OK, this is pretty much the final model for the primary rainbow. The image shows the maximum possible density of the entire rainbow, with the density shader of the cloud replaced with a constant colour (white of course). Yes there isn't much orange, but usually the rainbow won't be at full intensity, in which case there.
I had to do a test render of this as previous test showed that the rainbow can go white if a ray has to pass through too much cloud. This model uses a fixed cloud depth of 5000m on the secondary planet to control the maximum thickness.
Planning the connections for tweaking/animating and hiding the rest of the complex node network.
Inputs:
- Colour adjust node to connect the density shader of the cloud(s) used for rain (used to tweak density/intensity) of the rainbow)
- (optional) Constant scalar used as a multiplier of the rainbow density
- Secondary planet will need to be visible in node network to match position of planet to camera and to set the distance from the camera of the rainbow (via the planet diameter)
- Colour adjust node for setting the range of brightening inside the rainbow (20° in this image, but will be changed to provide 100% and then tweaked by this shader)
- Constant scalar for relative intensity of secondary rainbow compared to the primary
Outputs:- Mask to modify density shader of rain (cut out/reduce density of rain where it will be replaced by/combined with the rainbow)
- Surface shader for use as a preview on the terrain surface to see the position of the rainbow in preview window with the atmosphere turned off. (I found this useful for composition)
Superb!
astonishing!
great work bigben!
:)
Running a test render now of a double rainbow. I digressed a bit by trying my original method of adding some base density to the colour masks. Better saturation of colours (perhaps even too good) but it suffered from banding at low densities. This method is the best compromise I've found so far between colour and smoothness at low mask density.
There is still one problem I have yet to deal with... distance from the camera. My original idea was to set the cloud thickness to a fixed thickness (5000m) and fixed altitude (2500m) and then adjust the radius of the secondary planet to change the distance from the camera (the camera is in the center of the planet). I started building with a planet with a radius of 1m and when I adjusted the planet radius and cloud altitude I got a hefty drop in density. I suspect there's some other atmosphere settings affecting the density of clouds according to their altitude. Will have to read up on that later.
Close but no banana yet... Secondary rainbow @ 50-53° radius, density = 0.3x primary rainbow
Something's wrong in the yellow (probably my error) and the low density violet end also looks too dark. I might try extending the outer back scatter lightening into the violet end of the rainbow to lighten it up, although this should really be tested in situ with surrounding rain.
Doing a bit more homework, read Matt's helpful post on ray tracing. This looks like a candidate for "ray trace everything". Seems to improve rendering speed and improve noise. Detail's only 0.35 for this test and rendering time seems to be more even across the different areas. With ray trace everything turned off the areas outside of the masked rainbow render very quickly but the rainbow renders VERY slowly.
Raytrace Atmosphere should give you any benefits of reduced noise that you're seeing, while not incuring the raytraced terrain slowdown issues you're seeing. At least I think that should be true...
- Oshyan
I actually had ray trace atmospheres checked previously but in this case I think I underestimated the impact of the changes I had made to the masks. Just for interest I loaded both into Photoshop, set the top layer to difference and then applied an extreme levels adjustment to see the difference. There are small differences in the atmosphere, although on visual inspection this seems to be more a case of differing noise patterns. The latter image looks a little smoother in the atmosphere but that's very subjective.
The terrain is another story but I was just doing a quick test without tweaking any of the other settings.
The terrain looks crappy because of the ray detail multiplier setting.
Go inside your rendernode and open the "render subdiv" node. Inside you'll see the ray detail multiplier set to 0.25.
This means that for ray traced elements like water transparency and terrain the detail setting will be multiplied by 0.25.
That's the reason the terrain looks worse than expected and is also the reason why, by default, underwater features look triangulated.
Increase it to 0.5 or 0.7 and see if it is more to your liking. You can set it to 1 max, of course, but be aware rendertimes increase.
edit: I'm wondering if this multiplier also affects RTA?
For RTA it's difficult to determine the settings and it requires good understanding of the pixel sampler.
It's good to know how many samples you require for a 'smooth' result without RTA.
If it's a huge amount (hundreds of samples) then you likely need to make good use of the adaptive AA pixel sampler and relatively higher AA.
Be aware that in case of RTE it also affects your terrain.
So like Oshyan said, if you feel exploring raytracing the atmosphere then go for RTA instead of RTE.
Thanks for the explanation. I was aware of the settings you mentioned but now I know where they are ;)
Almost there with the gradient on the secondary rainbow but the wider variation of width in the bands is proving challenging
Left a render running last night. To some extent the render settings are important in this model, since I've been tweaking mask gradients and densities to try and keep things as smooth as possible. Some of the problems I was trying to fix early on weren't actually problems at higher detail settings.
Increasing the AA to 8 (with Detail 0.35) made a very smooth rainbow in the atmosphere, but the low detail in the terrain increased where the terrain and rainbow overlap. This one is Detail 0.5, AA8