Ray Depth?

[LaFrance]

well, I'm 90 hours into a 3k by 800 render, looks like a few more days to go 
(I'll post when done, promise)
no populations, but I've made the fatal mistake (probably amongst others) of turning on soft reflections.
There is a "samples" parameter under the reflection quality tab.. but no ray depth. Matt, Jo, Oshyan, I'm curious
what the ray tracer is doing with the number of bounces? continuing on until either fully
absorbed or returning the sky color? It would be really sweet to have limiters on the number
of bounces, options for optimizing secondary bounces (limiting how much of the surface shader
is calculated and decreasing sampling on post-primary bounces..) etc.

In general, is optimization of  GI on the planned to-do list?

This is by far the coolest program I use. I just really need some nitro under the hood

thanks,

Brian

[Henry Blewer]

Take a look at the reflection in the water shader. It does not take many samples. I have noticed this program uses a curious reflection algorithm. It works well. But as you say, there is not much control over it. For making wet looking things, with little need for reflection, I turn the setting way down.

[Matt]

Reflections are currently hardcoded to a maximum ray depth of 6 (with ray 1 being the surface visible to the camera), meaning 5 reflections, or 4 reflections after the first reflection. However, surfaces in the last reflection appear black or show only their luminosity, due to shadow rays being treated as a higher ray depth and returning fully opaque beyond the limit.

I realise that for many situations that's much more than you need and that renders could be optimised if this were adjustable. I guess rough water with big waves would really benefit from a lower limit. Unfortunately right now the GI solution is intertwined with the ray tracer in such a way that I can't easily make the reflection ray depth adjustable without breaking GI (it's not just a question of changing the max depth per surface). GI bounces are currently limited to 2. I need to do some recoding of that. It's not a major problem, but there's little time to work on it right now.

(Terragen really isn't the best renderer to be doing complex reflections with, anyway )

GI optimisations: there are many ways I'm planning to optimise GI in future, but there probably won't be any radical improvements until next year. In the short term it's just minor fixes and improvements as I find them. Adjusting the number of GI bounces is not a priority because it's already set pretty low at 2.

Matt

[Matt]

Adding to the above... using soft reflections is especially bad because I use the same number of samples for each bounce, causing an exponential increase in the number of rays. That was stupid of me, but I didn't spend much time working on the soft reflections because I thought it wouldn't be practical anyway   The sampling pattern is also extremely naive.

I will change it right now so that higher reflections always use only 1 reflection sample. That should make it slightly more usable. That sort of optimisation is used in many other shaders, I just forgot to do it for soft reflections.

Matt

[Henry Blewer]

There was and probably still is a lot of discussion by coders of how to do fast reflection and transparency in 3D. Everyone has their favorite way. I liked the algorithm used by Dr. Gandalf in the 1980's. It was simple, and fast. It had to be to run on machines which at top speed were 7.14 MHz.

[Matt]

Any info about that algorithm, njeneb?

[Henry Blewer]

It was published in 1986 or 1987 in a now defunct magazine. I can't remember the magazine's name now. Let me do a search, I'll post the link here.

[Henry Blewer]

It seems the links are too old, or the info was not saved. It was Dr. Dobb's Journal. It was for programmers and still is. I have not seen a copy in decades. Here are some links I found, but they don't reveal much. The third link was the more on topic, but it is really basic. I'm sure you have seen all this in programming 101, right next to the 'Hello' program.

http://tog.acm.org/resources/RTNews/html/rtnews7b.html
http://tog.acm.org/resources/RTNews/text/RTNews7.txt
http://cs.fit.edu/~wds/classes/adv-graphics/raytrace/raytrace.html
Dr.Dobb's Programming Journal. Unable to get old texts.

[Matt]

Thanks.

[Matt]

I thought maybe you might be interested in seeing some images from a path tracer I wrote a couple of years go.

I wanted to find out just how fast I could make a basic ray tracer when it didn't have to deal with complex geometry. This is a basic "path tracer", firing e.g. 1024 paths from each pixel and randomly distributing them about the scene, tracing multiple bounces, until they hit some luminous geometry. All illumination therefore comes from reflections of luminous geometry.

The first and second images were rendered with some routines that only took about 5 hours to code, although I was using the Terragen renderer as a host so I could concentrate on the path tracer and sampling routines. The third and fourth images were rendered the next day after I plugged in some depth of field and motion blur effect. I'd never done anything like this before and I was pretty happy with the kind of images I could get with such a quick experiment.

An interesting thing, and relevant to this topic(!), is that here there is no ray depth limit. Statistically speaking, every possible ray depth is accounted for and weighted correctly. The reason this is possible is that each path propagates only a single ray at each bounce, so there's no explosion of the number of rays, and ray termination is handled by the 'russian roulette' method. Some rays can bounce nearly forever, most terminate after only a few bounces. The probability of termination depends on an estimate of the contribution that further rays will make to the result, and sample weightings ensure that statistically all bounces have equal contribution to the result.

Modern ray tracers incorporate these ideas, so they're nothing new, but it was fun to implement as see the results. Working just with spheres and simple sphere hierarchies means it's very fast to calculate thousands of paths per pixel. I wish we could do that with Terragen scenes!

Render times and number of paths per pixel are in the filenames. 2GHz CPU.

[attachthumb=1]
sphereflake_64x16_17m15s_1core.png

[attachthumb=2]
sphereflake_4096paths_2h40m_2cores.jpg

[attachthumb=3]
sphereflake_dof_1024paths_30min_2cores.jpg

[attachthumb=4]
sphereflake_RotationBlur_1024paths_1h36m_2cores.jpg

EDIT: these would have been a lot faster if I had implemented some kind of adaptive sampling, requiring fewer paths per pixel.

Matt

[LaFrance]

Thanks for the responses guys. I'm going to kill this render now (attached). It's been running for 109 hours and is only half done.
It needs more work anyway, it's a bit boring, and the atmosphere needs more samples.
And I'll never touch the soft refl again  

B

ps> very cool renders, btw, Matt.

[Henry Blewer]

Matt, I sent a pdf which is a thesis written in 1997. I only scanned through it, but it's thorough. I would have just posted the link, but Firefox opened it and I could not find it.

[Henry Blewer]

LaFrance, I think you may have some really complex displacements in your landscape to calculate. Try using a simpler one. The sky and light are really great! It would be a fantastic render because of the sky alone.

[LaFrance]

Thanks njeneb.

But I want the land to be even *more* complex..
will do some work on the back hills, the fake stones, the textures and maybe add some vegetation.

edit: also of note, the displacement is actually very simple node-wise: just one layer, done in geoControl.

[Henry Blewer]

I have notice in my work that the vegetation, when used well can make a poor landscape look exceptional.