Skip to main content
TeraBit
Up and Coming
May 10, 2013

Rift Ray-tracing

[EDIT] This now has a demo, but I'll keep the link here up to date.

Download demo
(Updated to 12 Meg. Ver 0.50 on the Twentieth of June in the Year Twenty-Thirteen)).

Hi All,

I haven't got my Rift yet (UK near the end of the Kickstarter), but have been following the goings on with interest.

I've started to have a go at doing some CUDA based ray-tracing for VR and have managed to get some basic stuff going.

Rather than warping a resulting image I've made a start at modeling the lenses in the ray projection code.
(no texturing or shadows yet, just trying to get the distortion and stereo going.)

This is what I've got so far. It's probably waaaay out, but until I get my one, I'm flying blind. :D

Note: It's a bit wide to see in the post, you may need to open the image in another tab to see the entire screen.

    152 replies

    Show previous replies
    TeraBitAuthor
    Up and Coming
    June 14, 2013
    "jwilkins" wrote:
    Did you actually try just launching the context?

    That was the first thing I tried. Well...I thought I did, but it turns out you are correct.
    There was a bug in the function that let it drop through and re-cast all the rays from the scene again!
    When corrected, the frame rate drops only 5 FPS, which is acceptable.

    "jwilkins" wrote:
    One idea that just occurred to me is that if you have enough fast memory you could track high contrast areas in the first pass and immediately cast extra rays.

    The problem is that all the pixels are being traced independently, so you do not know that the surrounding pixels are finished until the context ends. But 5 FPS drop I can live with. :D
    Regards, Lee Page TeraBit Software
    jwilkins
    Up and Coming
    June 14, 2013
    "TeraBit" wrote:

    "jwilkins" wrote:
    One idea that just occurred to me is that if you have enough fast memory you could track high contrast areas in the first pass and immediately cast extra rays.

    The problem is that all the pixels are being traced independently, so you do not know that the surrounding pixels are finished until the context ends. But 5 FPS drop I can live with. :D


    You would use shared memory to communicate between the threads.
    (╯°□°)╯︵┻━┻
    TeraBitAuthor
    Up and Coming
    June 14, 2013
    Ok, Contrast Based Adaptive AA
    vs

    Speed drop ~10-12 FPS.
    Regards, Lee Page TeraBit Software
    jwilkins
    Up and Coming
    June 14, 2013
    IMO jitter makes the Lego go away entirely while your AA doesn't have enough samples to even touch the Lego much at all
    (╯°□°)╯︵┻━┻
    geekmaster
    Up and Coming
    June 14, 2013
    "jwilkins" wrote:
    IMO jitter makes the Lego go away entirely while your AA doesn't have enough samples to even touch the Lego much at all

    Ditto. ;)
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
    TeraBitAuthor
    Up and Coming
    June 14, 2013
    Now on a slightly higher setting...
    vs
    Regards, Lee Page TeraBit Software
    geekmaster
    Up and Coming
    June 14, 2013
    Still blocky, but fuzzy blocks. I liked the random sampling rough edges better, and they would average over time inside the eye. Perhaps you could blend the two methods like I did (in unreleased code).
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
    jwilkins
    Up and Coming
    June 14, 2013
    aanoise.png


    • Top Left: No AA, No Noise

    • Top Right: No AA, Noise

    • Bottom Left: AA (box filter), No Noise (random pixel swap)

    • Bottom Right: AA (box filter), Noise (random pixel swap)



    Notice that a box filter really sucks compared to a properly rasterized AA circle (not shown).
    (╯°□°)╯︵┻━┻
    geekmaster
    Up and Coming
    June 14, 2013
    "jwilkins" wrote:
    ... Notice that a box filter really sucks compared to a properly rasterized AA circle (not shown).

    The important thing that you did not show is a "random pixel swap" averaged over time, as it would appear to the human eye (although somewhat "sparkly"). Perhaps an animated GIF image would be appropriate for an accurate rendition of such spatio-temporal random sampling.
    This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
    jwilkins
    Up and Coming
    June 14, 2013
    "geekmaster" wrote:
    "jwilkins" wrote:
    ... Notice that a box filter really sucks compared to a properly rasterized AA circle (not shown).

    The important thing that you did not show is a "random pixel swap" averaged over time, as it would appear to the human eye (although somewhat "sparkly"). Perhaps an animated GIF image would be appropriate for an accurate rendition of such spatio-temporal random sampling.


    I considered that, but the amount of work is high. I do have my own raytracing code, so if I really wanted to, I could directly generate an example instead of demonstrating the ideas using GIMP.
    (╯°□°)╯︵┻━┻
    Show more replies
    Terms & ConditionsAccessibility statement