Quick Question back

(L) [2017/09/05] [ost by johnshadow23] [Quick Question] Wayback!

Has anyone found progressive depth for a path tracer? Also would path tracing with out square roots be a good thing for real-time?
I have been working on a progressive depth algorithm and have actually done it. The algorithm doubles my render time in my real time path tracer but, at some cost of it being more based on how much time you want to give the render.
For the square rootless idea I have been working on an opengl based path tracer kind of a hybrid. Other wise that is not fully done.
Would any of these be useful? Have people already done this? That's all of my questions.

(L) [2017/09/27] [ost by hobold] [Quick Question] Wayback!

The relative speed of floating point square root computations has improved a lot since FPU hardware was first integrated into processor cores. Nowadays, if you can tolerate the occasional imprecision in the least one or two mantissa bits, single precision floating point square roots are fully pipelined, with a throughput of one per three or four cycles.

(The general idea is to have one special purpose FP instruction that quickly returns an approximate square root with maybe 6 or 7 bits of precision. Then you do two iterations of Newton-Raphson refinement, each with one fused multiply-add instruction.)

(L) [2017/09/28] [ost by graphicsMan] [Quick Question] Wayback!

Your ray tracer will need to be extremely fast before optimizing sqrt at this level will make much sense.  Of course there are many cases where you can avoid sqrt altogether, and that makes sense, but I wouldn't go out of my way to avoid it.  And with SSE on modern processors, the latency is about 10 cycles.  Moreover, you can do 4 sqrts at the same time using SSE.  Approximation with reciprocal sqrt and newton iteration is an option, but it won't buy you much (latency is 5 cycles, plus you need to apply several more operations, and if you really need sqrt and not reciprocal, you'll need a division too).  Unless your ray tracer is already amazing, I'd consider putting my efforts elsewhere.

(L) [2017/09/30] [ost by johnshadow23] [Quick Question] Wayback!

Awesome to know! Currently my ray tracer is far from amazing, I still can avoid a lot of stuff it seams though to achieve real-time.
Anyway, I was wondering if there is already stuff on progressive bounce depth, Or something of the sort? Because I have an algorithm that does just that. I would like to know just in cases someone has done it before.
Lastly what about sin and cosine, would that still be the same answer as square roots?

(L) [2017/10/02] [ost by papaboo] [Quick Question] Wayback!

What exactly do you mean by progressive depth? Render one bounce at a time and defer the next bounces (if any) to the next render call / frame?
If so then I haven't seen anything directly related to that, but there are papers that sort the rays pr bounce, so visualizing them as well is fairly trivial.
Or are you talking about something like russian roulette?

(L) [2017/10/03] [ost by johnshadow23] [Quick Question] Wayback!

It can be done several ways, Russian Roulette is one of them but, it would probably take for ever to render, even though possible.
Well the one I did is a real-time algorithm. It's doubled my frame rate and made my bounce count sky rocket into the thousands.
Although it takes a while to render.
it works by several buffers and a quadratic equation, you also have to rework the integration a bit, although simple it can make a difference.
I just haven't read anything with it.

(L) [2017/10/03] [ost by papaboo] [Quick Question] Wayback!

Yea, that really doesn't explain it. Now it sounds a bit more like (path) filtering, but a bounce count in the range of thousands (at least per individual path) is generally a bit silly.
If it's filtering, then there' been a ton of work done in that field.

(L) [2017/10/03] [ost by johnshadow23] [Quick Question] Wayback!

It does sound silly, it uses a ray buffering process and depth buffering process. Then I do a type of weighting and sum.
Then I get the average that I need. every frame = 1 extra bounce so at 60+ fps I can easily get to 100 bounces with out issues in under 2 seconds.
the main problem comes in when hitting a light source as you have to reset the ray with out resetting the color or depth,
other wise the sum will be come and issue.
Image: *I got my old path tracer to work [SMILEY :P]* a scene with 2 reflective spheres in finite plains.
[IMG #1 Image]
[IMG #2 Image]
this one is just for cool effect. it's depth is way high, and runs at 23fps which would be around 3 times that in cuda.

If there are any algorithms like this please tell me.
I would like to make my own path tracer more efficient and effective than it already is.

---

[IMG #1]:Not scraped: https://web.archive.org/web/20210508221205im_/https://s1.postimg.org/1357cj16vz/image.png
[IMG #2]:Not scraped: https://web.archive.org/web/20210508221205im_/https://s1.postimg.org/8aaq1umjjz/image.png

(L) [2017/10/04] [ost by graphicsMan] [Quick Question] Wayback!

trig functions will be much more expensive than sqrt.

(L) [2017/10/06] [ost by papaboo] [Quick Question] Wayback!

Alright. That's basically what I want to do at some point for my own path tracer as well in interactive scenarios.

I don't think I've ever read anything about it, since it should be fairly trivial, but [LINK http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.155.326&rep=rep1&type=pdf] and [LINK https://graphics.cs.illinois.edu/papers/shadersorting] might give you some inspiration.