Interactive real-time raytracing in WebGL(jonathan-olson.com)
jonathan-olson.com
Interactive real-time raytracing in WebGL
http://www.jonathan-olson.com/tesserace/tests/3d.html
42 comments
I just checked http://www.browserleaks.com/webgl on Win 7, and Firefox 30's ANGLE uses Direct3D 9, whereas Chrome's Canary (v38, best performance) uses Angle with Direct3D 11.
Firefox might upgrade this sometime, but Aurora (Firefox 32) still uses Direct3D 9.
Firefox might upgrade this sometime, but Aurora (Firefox 32) still uses Direct3D 9.
My understanding was that ANGLE was done so that DX9, 10, 11 could be used underneath for rendering while doing OpenGL -> DX translation, main reason being unstable GL drivers.
Nowadays, NVIDIA provides GLES2/3 apis, but not sure about AMD/Intel.
Nowadays, NVIDIA provides GLES2/3 apis, but not sure about AMD/Intel.
Since I am generally skeptical about "web technologies", when I read that WebGL had landed in Firefox, I disabled it[1].
>Practically any page with a non-trivial shader freezes Firefox for up to a minute or sometimes even more on my machine.
That makes me glad I disabled it.
[1]: In about:config, I set webgl.disabled to true.
>Practically any page with a non-trivial shader freezes Firefox for up to a minute or sometimes even more on my machine.
That makes me glad I disabled it.
[1]: In about:config, I set webgl.disabled to true.
You should check whether your drivers and browsers are uptodate. Most WebGL pages work just fine these days, although some (e.g. many shadertoy shaders) tend to use too expensive shaders which might be slow on older integrated GPUs from Intel or generally mobile GPUs.
Great work. I love seeing how the renderer quickly draws the basic details and then ever more slowly over time fills in the finer points. I know that's pretty much how ray tracing is working but still cool to see.
I’m learning about rasterization based computer graphics at the moment and it somehow bothers me that all of it might be obsolete in a couple of years when we can do path tracing in real-time. It’s such a fast moving field.
Don't think raytracing will kill off rasterization for the crucial "first bounce" step anytime soon if we're talking about increasingly-detailed ever-content-richer realtime 60FPS game renderers. Usually as soon as RT gets semi-real-time for simplistic scenes at a rather-too-low resolution (without AA), consumers move on to double the previous standard resolution (four times per-pixel workload) such as the move from FHD to retina/hiDPI, we're back to square one. Especially if say you find you need 4 split-screens stereoscopic at 4k with full shading fidelity.
Rasterization is just too cool of a hack to avoid the tracing of primary rays. In fact, it's rather all the hardware and software hacks that evolved around rasterization for 2 decades combined that make it so, not rasterization by itself per se. Various GPU & CPU based culling methods, early & hierarchical Z-buffer, today's realtime rendering pipeline is an amazing combination of cool techniques that keeps getting better. Raytracers say "pff, with real raytracing we wouldn't need all those dirty hacks", but for one most of them come with the GPU or are well-known and intuitive to implement, plus to get anywhere near-realtime they need to implement another set of even more (and less comprehensible/intuitive/hardware-accelerated) hacks of their own.
All shading stages are also designed around rasterization and matured over the last decade. It's good fun to write some pixel-shader-based raytracer but that alone doesn't make it the better fit for current/next-gen gamedev at all.
The oft-antipicated "hybrid" approach however is finally arriving. Once you have some "depth-aware screen-space" (whether voxelized or N-layers), you can shoot specialized and rather simple rays to create diverse outstanding effects in post-process, from much smoother water surfaces to of course "screen-space raytraced reflections" (SSRR).
Rasterization is just too cool of a hack to avoid the tracing of primary rays. In fact, it's rather all the hardware and software hacks that evolved around rasterization for 2 decades combined that make it so, not rasterization by itself per se. Various GPU & CPU based culling methods, early & hierarchical Z-buffer, today's realtime rendering pipeline is an amazing combination of cool techniques that keeps getting better. Raytracers say "pff, with real raytracing we wouldn't need all those dirty hacks", but for one most of them come with the GPU or are well-known and intuitive to implement, plus to get anywhere near-realtime they need to implement another set of even more (and less comprehensible/intuitive/hardware-accelerated) hacks of their own.
All shading stages are also designed around rasterization and matured over the last decade. It's good fun to write some pixel-shader-based raytracer but that alone doesn't make it the better fit for current/next-gen gamedev at all.
The oft-antipicated "hybrid" approach however is finally arriving. Once you have some "depth-aware screen-space" (whether voxelized or N-layers), you can shoot specialized and rather simple rays to create diverse outstanding effects in post-process, from much smoother water surfaces to of course "screen-space raytraced reflections" (SSRR).
When we are able to trace multiple rays with multiple bounces per pixel in real-time, would the first bounce really carry that much weight compared to the subsequent bounces that it would justify a separate rendering technique?
Besides that, what would you say to ilaksh’s comment? https://news.ycombinator.com/item?id=8060197
Besides that, what would you say to ilaksh’s comment? https://news.ycombinator.com/item?id=8060197
He's referring to demos that have been around for years and I've been following the space, too. His argument doesn't really refute any of my points. Knowing how the rasterizers work is never going to hurt you, quite the opposite. If you're serious about computer graphics you'll really want to have internalized both raytracing basics and rasterization basics. If I didn't know how triangle meshes are fed into the GPU and processed until the "final fully lit&shaded output pixel" for any one of my 94 favourite games, I'd feel pretty uneasy. Rasterization will always be orders of magnitude faster by necessity: that means when raytracing can finally render ca. 2004 scene complexity (think GTA:SA -- hint, it still can't even at quarter-res), rasterization can render ca. 2016 (or 2018 or whenever) scene complexity at full-res. Guess what the folks at Rockstar, Ubisoft, Crytek wanna do? Throw more details, more content variation, more procedurally-generated or -perturbed geometry at the screen at 60+ FPS. Sure Brigade can reach almost/barely 30FPS at some low resolution in a small limited preprocessed scene and then there's no more room for any physics, any AI, any animated crowds etc etc at all. They're doing important work and one day the big payoff will come, but for the next 10 years knowing how our rasterizers works will not be wasted at all.
After seeing the Brigade Engine and LuxRender path-tracing demos, I think that you are 100% correct to be worried, and beyond that, you should avoid wasting your time as much as possible. Actually, when you say "learning" that leads me to believe that you are enrolled in some course under some curriculum in some school.
I don't believe that any individual school, professor or course can really be up-to-date with the most leading edge practices or even theory, especially in high technology.
I think that the only really interesting area now in computer graphics is in doing path-tracing in hardware.
There is a massive culture that still is interested in other things but I think they are behind the times.
Sooner or later nVidia or ATI/AMD will put some native capabilities for path tracing a scene (not like OptiX where you program the existing architecture for it, but circuits/architecture that is truly optimized for path tracing) given a set of geometry, materials and lights into their graphics cards.
At that point all of the rasterization and lighting calculation tricks will be obsolete.
Probably this will be buried because there is an enormous amount of effort going into those old-fashioned approaches, but oh well. I have to say it.
I don't believe that any individual school, professor or course can really be up-to-date with the most leading edge practices or even theory, especially in high technology.
I think that the only really interesting area now in computer graphics is in doing path-tracing in hardware.
There is a massive culture that still is interested in other things but I think they are behind the times.
Sooner or later nVidia or ATI/AMD will put some native capabilities for path tracing a scene (not like OptiX where you program the existing architecture for it, but circuits/architecture that is truly optimized for path tracing) given a set of geometry, materials and lights into their graphics cards.
At that point all of the rasterization and lighting calculation tricks will be obsolete.
Probably this will be buried because there is an enormous amount of effort going into those old-fashioned approaches, but oh well. I have to say it.
continue learning that stuff: the algorithms will be useful, and you may find yourself working on an embedded device without the CPU to do path/ray tracing.
Amazing work. The most complex path-tracing shaders I've seen in WebGL so far.
My project, https://Clara.io, also features interactive ray-tracing but we do it server side using V-Ray. Example here:
https://clara.io/view/a82f8a80-8a5e-4e61-8faf-3de9eb4313c2/r...
My project, https://Clara.io, also features interactive ray-tracing but we do it server side using V-Ray. Example here:
https://clara.io/view/a82f8a80-8a5e-4e61-8faf-3de9eb4313c2/r...
In kubuntu 14.04, Intel HD4400, Firefox:
Error: WebGL: drawArrays: incomplete framebuffer
GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (clear)
GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (check) (repeated many times)Sorry about that! I had someone else report that it fails across all browsers with the HD4400.
It works well on OSX 10.10 with an HD4000 in Firefox, Chrome and even in Safari. The "framebuffer not complete" warning looks like you're using an extension which isn't supported everywhere, probably OES_texture_float or WEBGL_depth_texture?
I have made a Path-traced online game 2 years ago. http://pog.ivank.net/
Why does the hn title say ray tracing. Its path tracing which is different. Is this another one of those moderators editing things?
Raytracing is a very broad family of algorithms, path tracing is certainly "a raytracing algorithm".
On my ubuntu 12.04 with on-board intel graphics+ chrome browser.
Error: GLSL link error: for vertex shader: <fragment source>
I got "Error: GLSL link error: for vertex shader" also.
With Xubuntu / Ubuntu 12.10 running an Asus VivoBook S200E.
May be someone just put some screenshots.
I'm looking forward to trying this on my iOS device once iOS 8 comes out.
It crashes my browser.
Sorry about that! Do you mind if I ask what browser and/or graphics card caused this?
Firefox 30.0, Radeon HD4870
Incredibly beautiful. Thank you for sharing.
long long time to load (over a minute). But it worked well once loaded. You can move through the floor...
I don't think the author took effort to focus on control logic like motion clipping through objects. It's more of a showcase of how quickly his raytracing algorithm is able to render images. That was the real takeaway from me, having written a raytracer in c++ it is amazing to see this running so quickly, and in the browser too.
This is a damn impressive demo, but it's not really "in the browser". The browser is the shell, but absolutely all of the heavy lifting is being done on the GPU. No matter what you're using to push shaders over to the GPU, you're really looking at the same performance (so long as that's all that's happening -- it's obviously easy to do horrible things and slow down WebGL or D3D or whatever you happen to be using for a graphics API).
Author here! It's very true that the GPU does the heavy lifting, although I'm not sure exactly where an "in the browser" line could be drawn (conceptually any page uses the browser as an execution engine and library).
It's a bit trickier due to restrictions in WebGL (OpenGL ES based) compared to the desktop (e.g. no bitwise operators makes it a pain to get randomness that doesn't bias the result), but it's basically the same.
It's a bit trickier due to restrictions in WebGL (OpenGL ES based) compared to the desktop (e.g. no bitwise operators makes it a pain to get randomness that doesn't bias the result), but it's basically the same.
Could you please list literature/papers that you found especially useful while making that renderer? I plan to do the same thing for education purposes.
I've done some similar implementations years ago (but with C/OCaml, nothing on the GPU), so I didn't refer to many things for this.
Fresnel reflectance is based off of http://mathinfo.univ-reims.fr/IMG/pdf/Combined_rendering_of_..., although I'm not doing any spectral or polarization-dependent code right now (I wanted to leave that open, and it allows accurate metal simulation).
I tinkered with a blend of some pseudorandomness functions until getting something that worked.
https://www.siggraph.org/education/materials/HyperGraph/rayt... was used for ray-box intersection.
The distance function experiment for the drinking glass is based off of the concept of http://www.iquilezles.org/www/articles/distfunctions/distfun... (like raymarching, includes normal computation).
I consulted http://madebyevan.com/webgl-path-tracing/ to see the best way to do accumulation (and made some realism fixes in https://github.com/jonathanolson/webgl-path-tracing, see https://github.com/evanw/webgl-path-tracing/pull/1 for details).
Many other things can be pulled from online or from books like http://www.amazon.com/Game-Engine-Design-Interactive-Technol....
Please let me know if you have any questions, (see my email at http://jonathan-olson.com/about), and please feel free to use my code however you like (things I wrote are MIT, but I use CC-by and CC-by-non-commercial HDR images).
Fresnel reflectance is based off of http://mathinfo.univ-reims.fr/IMG/pdf/Combined_rendering_of_..., although I'm not doing any spectral or polarization-dependent code right now (I wanted to leave that open, and it allows accurate metal simulation).
I tinkered with a blend of some pseudorandomness functions until getting something that worked.
https://www.siggraph.org/education/materials/HyperGraph/rayt... was used for ray-box intersection.
The distance function experiment for the drinking glass is based off of the concept of http://www.iquilezles.org/www/articles/distfunctions/distfun... (like raymarching, includes normal computation).
I consulted http://madebyevan.com/webgl-path-tracing/ to see the best way to do accumulation (and made some realism fixes in https://github.com/jonathanolson/webgl-path-tracing, see https://github.com/evanw/webgl-path-tracing/pull/1 for details).
Many other things can be pulled from online or from books like http://www.amazon.com/Game-Engine-Design-Interactive-Technol....
Please let me know if you have any questions, (see my email at http://jonathan-olson.com/about), and please feel free to use my code however you like (things I wrote are MIT, but I use CC-by and CC-by-non-commercial HDR images).
Thanks!
If you're interested in ray/path tracing or photorealistic rendering at all I would seriously recommend Physically Based Rendering[1]. It's probably one of the most satisfying book purchases I've made. The authors go through every aspect of implementing a quality path tracer: image sampling, surface shading models, statistics and integration methods, intersection testing and acceleration and more. It's an absolute treasure trove of information. (Be prepared to do a lot of math.)
[1] http://www.amazon.com/Physically-Based-Rendering-Second-Impl...
[1] http://www.amazon.com/Physically-Based-Rendering-Second-Impl...
Excellent work!
I think the rationale for using ANGLE is to avoid driver bugs, but in my experience, it causes much more damage than the problems it solves. Practically any page with a non-trivial shader freezes Firefox for up to a minute or sometimes even more on my machine.