While i posted this in another thread as an MLT comparison, there is a problem i stumbled upon back then that puzzles me since then, and i cant ignore it anymore due to some shots i need.
It seems that while Cycles is a Unidirectional unbiased MC renderer, it has a huge bug that i believe can be easily fixed.
The problem is that even with noise, and highest settings, you CAN NOT get a clean ray transmission without diffusion!
I tried MANY things regarding this issue (yes i have also filter glossy on 0) but i cant get the underwater clean.
And it should be, even with a lot of noise, but no, after converging, the rays diffuse on the bottom.
In comparison look at the octane render. Absolute clear.
What is happening ?
Both use a simple sun with the same size and a blue HDR sky (same map).
The sun is in both cases a mathematical sun with 10 cm. The diffusion does not come from the size of the sun, it cannot. Also even if the sun would be bigger (area light) at least some folding and converging caustics should be really sharp on the bottom!
The rays diffuse really fast, way too fast. There is something in the code or the transmission BSDFs i think.
Also it doesn’t matter if i use the glass shader or the refraction shader.
If you set roughness to zero, the refraction is exact, nothing diffuses there.
Setting sun size in centimeters isn’t exactly well defined, try setting it as an angle instead.
Also, make sure to enable MIS on the lamp.
Roughness is always 0, tried ggx, beckmann, sharp, it doesn’t matter.
If you go with the sun size, or (doesnt matter) even an area light down, you get somehow sharper, but only SOMEHOW, it is still blurry, there are no sharp caustic edges, even after a LOOONG converge time, i just let it render a 4096 samples pool with a tiny 2cm sun. What do you mean by angle ? Its a simple sun 80 degrees inclination sun with 2 cm in size, there are no other settings. MIS is on. Full Global Illumination 128 on all. CMJ on. No clamp, no filter glossy.
PS: BTW has anyone ever successfully managed to do a non-blurry pool on cycles ? cause i searched the forum… do i miss something ? Any other caustics are emerging fine, like metal, rings, diamonds, etc… but even there i saw that the caustics do not converge sharp at their edges.
Look MIS 4096 samples, sharp refraction again but this time with only 2cm sun:
So this means that you need to have an infinitely small sun to address a correct caustic folding… hmmm… it seems so. Of course the sun wont be found then by any ray.
Somehow octane is able to understand how to do the sharp refraction and finds the sun after only 512 samples, but its still unidirectional, so how, or is there a transversal ray error from a certain distance with cycles ?
Good caustics will always take a long time to render because the nature of Cycles as a pathtracer.
The only thing that could possibly speed it up (without sacrificing the flexibility Cycles gives in shading) is Metropolis sampling (Lukas Stockner did have a patch for it going at one point, but later scrapped it due to various issues in the implementation).
Your sun is too big/ your glass/refr. material is too rough. The default Cycles sun size + zero refraction is, indeed, too blurred. Set it lower (.001) and render. Or keep reading, that’s faster…
Shrinking the sun anymore will make it so that you barely get any of the brighter rays that hit it, as Cycles lacks any of the more advanced path tracing additions, like MLT.
Hehehe… I decided to test, too… I think we can all learn nothing from the following images, because what they show you are things you should already have knowledge of.
[spoiler]
That’s 65536 samples with Full GI(128 max bounces, 32 min). That’s right, 1024*32 samples and it’s still that noisy.
Hey, I wonder if someone can bump the samples up to like 10^9 and see if it clears up there.
This is the scene. I forgot to mention: The sun has a 0.002 size and the water glass material has 0.001 roughness and 1.33 IOR. MIS on both, obviously, that happens automatically, or at least for me.
[/spoiler]
The calculation isn’t wrong. Your materials(sun) are set up wrong(too large). Fixing what’s wrong however will result in fruitless renders, as shown above.
This pool scenario is pretty much worst-case for any unidirectional path tracer.
There are possibilities to render it - Metropolis sampling helps a bit, and more recent and advanced papers like manifold exploration and machine-learning-based fitting of directional distributions can help a bit, but it’s extremely unlikely that Octane implements any of those.
So, my guess is: Octane is cheating somehow. There are many ways to do so, for example, using a dedicated photon map for caustics.
Side note: If you move the camera out of the water, looking down, even bidirectional path tracing won’t help you (SDS paths being the problem here). As far as I know, no unbiased rendering algorithm exists to date that can easily render this scene.
Also, sorry for the sun size confusion, I thought there was a way to set the sunlamp size in degrees.
After looking at your patch, there are (of course) problems with the tiles due to the different sampling approximations at the tile edges, so i think that the octane guys encountered the same problem and what i believe is that instead of just shooting MLT sampling with unidir tracing, that was the moment PMC was born (i mean they adopted it, its older), cause what pmc is actually doing, is MC lookup the rays themselves OVER the MC pathtracing.
Cause the non-pmc kernels in octane suffer the SAME problem. I just tried!
So basically the PMC is finding the lights trough a progressive MC lookup (which also converges the edges of any render tile), then the actual MC rayshooting samples takes place, now of course “finding”/sampling the sun very, very easily. This is why at the beginning the PMC render looks so awful (you basically see the MC lookup), but after 128-256 samples lets say… it gets absolutely beautiful.
What do you say ? Would this be worth trying ?
What i found:
this is showing how MCMC is practically beaten by the PMC implementation:
and this:
PMC is NOT requiring an MCMC approach, but gives the same results, and should be compatible with unidir PT, thus keeping the flexibility of Cycles intact!
@Viktor
Oh dude, this is crazy, ahahahahahah, 65536 samples! 30min for a tiny tile! LOL
BTW, what i still don’t understand about the sunlight. Why degrees, or size at all ?
I mean, shouldn’t a “sunlight” lamp be a “infinitely” far parallel rays “emitter” (no surface), all over the place ? Wouldn’t this even be more easy for Cycles ? Then the cam would always find the lightrays easily.
Cause its the sky scattering (HDR maps, skymodel) that should do the soft/hard shadows.
AFAIK it is treated now like an area light, at some far distance… isn’t this wrong ?
Cause if we are speaking of the Sun itself for size, etc, then we have HDR maps, or the Skymodel, right ?
The sun is not a point source, it has an apparent size in the sky. The sun is far enough that rays don’t noticeably diverge, but it is so large that it can still be partially obscured in a noticeable way.
EDIT:
Yeah, Lukas, can we have a way to set sun size as an angle instead of radius? Cycles is the only renderer I’ve ever seen that does distant light size like a regular area light instead of using a radius.
What would be the radius to obtain correct visual angle of 0.53°, and in case I want to go to other planets or systems, how do I calculate it? For me, even a tooltip would be sufficient.
Sounds like something an addon could easily handle (all it would have to do is place a sunlamp and tweak settings to match various calculations, settings like size, angle, power, and color).
Calculations such as…
Distance (in astronomical units)
Size (in solar masses)
Temperature (with a value of 1 being the temperature of the sun)
Time of day
Date
and finally the Latitude of the intended scene
This could be coupled by an automatic world node tree builder (yes, nodes generated by Python) that places a solar disk of the correct size and color in the sky and proper bloom/haze effects based on atmospheric conditions (thickness, turbidity, and composition).
I tried to be clever, but without any maths, so I tried the following:
Add mirror rectangle, sunlamp and camera.
Point camera and sunlamp directly into the mirror.
Set render aspect to a 1:1 ratio (i.e. 1080 x 1080, basically so you can’t choose wrong).
Set camera to field of view mode and set 0.53°.
With interactive rendering, adjust sun radius until the disk fills the rendering square. I’m getting around 0.0046.
Does this approach give anywhere close to what maths would give? Or is my mind not working?
That size, however, is about the lower limit this works, because floating point errors starts to appear.
