updating of DE-Raytracer

[DarkBeam]

an earth golem?

[Crist-JRoger]

No ) Just an idea for soaring islands.

[Max Sinister]

@Crist-JRoger: The image from early June is very nice - looks almost natural.

[Crist-JRoger]

Max Sinister, Thank you! )

Decided to add some features for DE, like PK mod, but more "textured", working process goes very slowly without GLSL basics. Maybe soon I will have version for sharing... it will be slower monster for good GPUs  
This features works well:
- terrain with switch (cnoise, IQ, mixed);
- terrain multitexturing (2 modes);
- terrain heightmapping;
- IBL mode for terrain/floor;
- main object multitexturing (6 modes);
- background equirectangularMap picture;
- background sky;
- water surface;

Material gloss from PK still works not so good. Now testing renders, basically environment:

[knighty]

 

[Sabine]

Crist-JRoger   Fantastic work!  
PS. I have a very nice gpu   

[3dickulus]

that looks really good! bravo!

[Crist-JRoger]

Finally   http://sta.sh/013fhfwazcd4 renderer with presets and some textures
Not optimized and not tested on hard settings 

[Sabine]

 



Beautiful effects! Will need much more time to explore, but want you to know: runs great on my gpu! And Fast! Hardly any difference with other very simple .frags. Will see how it does with .frags that eat more resource

[Crist-JRoger]

On some renders i noticed that godrays doesn't reflects on surfaces (fractal or floor), and i thought it has been "conceived" ) or characteristic of DE renderer.
But now tested, see that rays are reflected! Sometimes   sometimes not, or when reflNumb=2 second reflection sotronger than first. Master Knighty, could you explain this?  

[lycium]

I'm not Master Knighty, but I do work on a commercial unbiased ray tracer, so I'll drop my 2c here

The root cause is the famous "problem of insufficient techniques" in path tracing, and it can be explained roughly as follows: say you're at some point in space, and you want to know how much light is coming in from all directions; for the direct (unreflected) light, you can make quite a good guess by picking directions that go directly towards the light sources. So that's nice, you can quite accurately match the distribution of incoming light, and you get a reasonably low variance Monte Carlo estimator. However, for once-, twice-, ... n-times bounced light, the problem is much more difficult: how can you know in which directions to send rays, so that they will reflect off some surface and happen to go through the little holes in the "ceiling" to reach the light source?

The answer is that you can't, in general, and although there are methods like Metropolis Light Transport which improve the efficiency using Markov Chain Monte Carlo to explore similar paths once one is found, it doesn't help you efficiently find them in the first place.

So, in order to have volumetric caustics, you'd need to solve this famous unsolved problem in computer graphics, and I read somewhere that it's very unlikely to be solved, because you can make optical computers, and knowing whether light paths go a certain way a priori is basically equivalent to solving the famous Halting Problem. Now, Knighty is clearly one hell of a wizard, but I doubt even he can solve this problem... so the practical alternatives are: have extreeeemely noisy renders with reflected caustics (sampling all directions uniformly, with very low efficiency / actual light-carrying paths), or simply exclude the effect. Knighty chose the latter, more workable, alternative, so that you don't have tons of noise in every render.

[Crist-JRoger]

Thank you, master Lyc 
I think I never understood this without appropriate education. I just began ratiocinate: here on this example we have lightsource and enabled vol.light with godrays that shines in all directions. Than we have obstacle - fractal with holes. The ray enters and reaches the next obstacle - surface. That's all, it works. So then we enable reflections (1 step) ans we see all objects reflected. Our lightray reflects too at the same angle as reached the surface. I'm not meaning that lightray will reflect from surface and goes again in space (it sounds fantastic for free soft). I mean just displaying ray on reflecting surface (1st and 3rd pictures on prev.post). But(!) sometimes lightrays not reflected (2nd pic). So, one reason that we see differents - camera was mooved or FOV was changed.
You wrote why this (really this? or it was about caustic effects?) is happening in a global sense, but as i know DE-Kn renderer is not Monte Carlo. I do not like to operate with concepts that unclear to me. And very interested to know something new.

Ironically... a man without special education or programming skills started this topic 

[lycium]

You wrote why this (really this? or it was about caustic effects?) is happening in a global sense, but as i know DE-Kn renderer is not Monte Carlo. I do not like to operate with concepts that unclear to me. And very interested to know something new.

There is definitely integration: the god rays are done by integrating the incoming light along a viewing ray times by the transmission. This is done by something like normal quadrature (like you learn in high school, with many "boxes" of small size approximating the area under the curve), and probably a little random offset to make sure it converges properly, then it becomes a little Monte Carlo like. But for the higher-order light scattering, like when you want to know how much light reaches the current point *including* paths that have been reflected off the ground, then you have to integrate over all directions, since as mentioned you can't easily know a priori which directions will definitely lead you to the light source.

The usual way to do this integral is Monte Carlo, since it'll take quite a lot of samples in total to get a clean result, and it doesn't suffer from the so-called "curse of dimensionality": if you use some # of samples to estimate the incoming light from all directions, let's say 4 (very low quality estimate), then for 1 bounce you need 4 samples... manageable... but then for 2 bounces you need 16, then 64 for 3 bounces, etc. It quickly gets out of control and you spend so much time in these higher bounces (which usually contribute much less than the lower bounces) that it becomes very inefficient. This by the way is why path tracing is called path tracing: it is non-recursive, tracing only a single path at a time without exploding exponentially. There's a classic diagram from the original 1986 paper by James Kajiya on the Rendering Equation illustrating it (attached to this post).

Ironically... a man without special education or programming skills started this topic  

Unfortunately I didn't even finish a normal university degree, and got an E for mathematics at the end of high school As Mark Twain said, and I am fond of repeating, "I have never let my schooling interfere with my education."

[Crist-JRoger]

You try to say that we don't know about existence of light rays on reflective surface? But they exists ))) here:

[lycium]

Hmmm, might be that we're thinking of a different problem. Attached is what I meant: at the point p, you have to choose a direction which will reflect off the ground and go through the small "window" to reach the light source.