Interactive real-time raytracing in WebGL

http://www.jonathan-olson.com/tesserace/tests/3d.html

by sxp • 12 years ago

90 42 12 years ago

acomjean• 12 years ago

long long time to load (over a minute). But it worked well once loaded. You can move through the floor...

bowmessage• 12 years ago

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.

daeken• 12 years ago

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).

ilaksh4• 12 years ago

Why does the hn title say ray tracing. Its path tracing which is different. Is this another one of those moderators editing things?

dualogy3• 12 years ago

Raytracing is a very broad family of algorithms, path tracing is certainly "a raytracing algorithm".

ilaksh4• 12 years ago

Seems like they are similar but different.

arcameron• 12 years ago

Excellent work!

yuriks2• 12 years ago

For anyone who suffers from terribly long load times/freezing when compiling the shader, this is caused by the ANGLE wrapper Firefox and Chrome use to convert the WebGL calls to Direct3D 9. You can get better results by disabling it: http://www.geeks3d.com/20130611/webgl-how-to-enable-native-o...

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.

hollerith• 12 years ago

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.

flohofwoe2• 12 years ago

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.

malkia• 12 years ago

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.

muyyatin6• 12 years ago

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.

hiddentao• 12 years ago

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.

grimmfang• 12 years ago

Incredibly beautiful. Thank you for sharing.

hitlin372• 12 years ago

On my ubuntu 12.04 with on-board intel graphics+ chrome browser. Error: GLSL link error: for vertex shader: <fragment source>

hitlin372• 12 years ago

May be someone just put some screenshots.

luke-stanley• 12 years ago

I got "Error: GLSL link error: for vertex shader" also. With Xubuntu / Ubuntu 12.10 running an Asus VivoBook S200E.

spingsprong2• 12 years ago

It crashes my browser.

muyyatin6• 12 years ago

Sorry about that! Do you mind if I ask what browser and/or graphics card caused this?

spingsprong2• 12 years ago

Firefox 30.0, Radeon HD4870

bhouston• 12 years ago

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...

DiThi• 12 years ago

In kubuntu 14.04, Intel HD4400, Firefox:

    Error: WebGL: drawArrays: incomplete framebuffer

Chrome:

    GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (clear)
    GL ERROR :GL_INVALID_FRAMEBUFFER_OPERATION : glDrawArrays: framebuffer incomplete (check) (repeated many times)

muyyatin6• 12 years ago

Sorry about that! I had someone else report that it fails across all browsers with the HD4400.

flohofwoe2• 12 years ago

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?

IvanK_net• 12 years ago

I have made a Path-traced online game 2 years ago. http://pog.ivank.net/

3rd32• 12 years ago

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.

bsenftner• 12 years ago

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.

dualogy3• 12 years ago

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).

3rd32• 12 years ago

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

ilaksh4• 12 years ago

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.

shurcooL• 12 years ago

I'm looking forward to trying this on my iOS device once iOS 8 comes out.

Interactive real-time raytracing in WebGL

Related Stories