Updated Ray Tracing Demo

Looks cool. And works. How is the performance if you don't do the high resolution centre?
Single rays (no secondary reflection/refraction)? I'm always curious how you would do recursive ray tracing on a GPU.
And as a side project I'm trying to do some multi threaded CPU ray tracing but not really enthusiastic yet.
By the way, i've switched recently from CUDA to OpenCL and pretty satisfied about it. If you want I can share some code.

"DoZo1971" wrote:
Looks cool. And works. How is the performance if you don't do the high resolution centre?
Single rays (no secondary reflection/refraction)? I'm always curious how you would do recursive ray tracing on a GPU.
And as a side project I'm trying to do some multi threaded CPU ray tracing but not really enthusiastic yet.
By the way, i've switched recently from CUDA to OpenCL and pretty satisfied about it. If you want I can share some code.

The keys on the keypad (7,1 & 8,2) control the relative sizes of the circles. So you can test it at different sizes.

Single rays would have no lighting. The second bounce is for the lighting and shadows. Further rays are for reflection and refraction etc. I always find it amazing how Ray Tracing can do so much with just a single technique, rays. 8-)

This uses the Optix Framework for the RT.

How do you get this to show on the secondary rift display? I gave both cloned and extended mode a go but in both cases it just showed in the center of my primary monitor. :)

Great tech demo! It felt like a sneak peek at the challenges of future tech.

"TeraBit" wrote:
Further work: Would probably need to blur the lower resolution version a bit more to make it less 'artifacty' (yes I used that as a word) 8-)

The shimmery effect of the lower resolution region is is now my biggest concern with foveal/foveated (?) rendering -- it should be very interesting to see if it can be mitigated with a blur. I increased the fovea region to cover almost the entire screen, and the shimmery effect of the circular region at the edge of my FOV was still very obvious to me.

Thanks for sharing this.

@yellowCap, yeah I had to switch to extending my desktop and changing the Rift's monitor resolution back to 1280x800 before I could get it fullscreen there. And then Windows+P -> Up Arrow -> Enter (on Win8 anyway) to get it back to a duplicated desktop.

"yellowCap" wrote:
How do you get this to show on the secondary rift display? I gave both cloned and extended mode a go but in both cases it just showed in the center of my primary monitor. :)

I would guess you have your extended monitor for the Rift set up with the wrong resolution, as it searches for a 1280x800 display and sends it there.

The shimmery effect of the lower resolution region is is now my biggest concern with foveal/foveated (?) rendering -- it should be very interesting to see if it can be mitigated with a blur. I increased the fovea region to cover almost the entire screen, and the shimmery effect of the circular region at the edge of my FOV was still very obvious to me.

@yellowCap, yeah I had to switch to extending my desktop and changing the Rift's monitor resolution back to 1280x800 before I could get it fullscreen there. And then Windows+P -> Up Arrow -> Enter (on Win8 anyway) to get it back to a duplicated desktop.

it's possible to scale the resolution radially using a gradient, so that it would have a resolution falloff and then simply expand the pixels to fill adjacent 'blank' space, but was having problems with shimmery overlap, so went for the two resolution one in the demo. In fact you can still see some of the experimental stuff by pressing the plus and minus keys on the keypad.

You are correct about it being keyed to the resolution.

Single rays would have no lighting. The second bounce is for the lighting and shadows. Further rays are for reflection and refraction etc. I always find it amazing how Ray Tracing can do so much with just a single technique, rays.

I know, I have some history in ray tracing ;-) (ancient history, like 20 years ago).
What I don't understand is how you can efficiently map your rays (well, your algorithm) to the GPU. How to avoid excessive branching in your kernels. Due to the inherently recursive nature of ray tracing.

Although my MacBook Pro has lots of features, it lacks a numpad. F3F4 controls refractive index, F5F6 for IPD, F7F8 for distortion. But no button for the radius of the sample density radius. Or?

Thanks,
Daniel

"DoZo1971" wrote:

Single rays would have no lighting. The second bounce is for the lighting and shadows. Further rays are for reflection and refraction etc. I always find it amazing how Ray Tracing can do so much with just a single technique, rays.

I know, I have some history in ray tracing ;-) (ancient history, like 20 years ago).
What I don't understand is how you can efficiently map your rays (well, your algorithm) to the GPU. How to avoid excessive branching in your kernels. Due to the inherently recursive nature of ray tracing.

Although my MacBook Pro has lots of features, it lacks a numpad. F3F4 controls refractive index, F5F6 for IPD, F7F8 for distortion. But no button for the radius of the sample density radius. Or?

Thanks,
Daniel

Ah, never thought about the numpad being missing on some keyboards. Will try to fix for the next demo.
To answer your original question, taking out the middle adds about 10 FPS, so about 20%.

Happy to see you back on this - it was always a favourite. :)

It is a very interesting first foray into variable detail rendering, although it is hard to resist looking around. :)

(EDIT: Ah, I see you already addressed what follows below, while I typed it -- I'll leave it anyway, now that it is, after all, typed. :P)

Would it be very complicated to adapt your renderer to do a single-pass render with an inherent smoother transition between the high- and low detail areas? (I'm thinking something crude, along the lines of prerendering a one-bit-deep bitmap, depicting the viewplane as, e.g. a floyd-steinberg-dithered concentric gradient, which is used as a look-up table of sorts; simply render Ones and skip Zeroes; Then, in post, apply a blur-ish filter that also uses the LUT, to discern "real" pixels from ones that needs to be interpolated (EDIT2: I suppose it might as well include precalculated weighting of sources for those unrendered pixels - why redo that every frame, after all?).)

It occurs that there are other things, in addition to sample density, which it may be worth experimenting with regulating, based on viewer gaze; Recursion depth certainly springs to mind, as do light source complexity/count.

(It could also be interesting to try locating and blotting out one's blind spot.)

Good work! :)

Thanks drash and TeraBit, you were right my rift wasn't set to native res.

Interesting demo, thanks for sharing. It is surprising how noticeable the peripheral artifacts are even when looking straight ahead. Perhaps we are particularly sensitive to motion in our peripherals due to the evolutionary advantage it might give.