Javascript Ray Tracer(fooo.fr)
fooo.fr
Javascript Ray Tracer
http://fooo.fr/~vjeux/epita/raytracer/raytracer.html
6 comments
Not to toot my own horn too loudly, but I built a realtime (unicode) raytracer in javascript:
https://github.com/trevlovett/AsciiTracer
That's very nice!
And here's yet another JS raytracer: http://www.syntensity.com/static/raytrace.html
And here's yet another JS raytracer: http://www.syntensity.com/static/raytrace.html
And it even has antialiasing! Very nice.
This water WebGL is another cool demo of raytracing on WebGL:
http://madebyevan.com/webgl-water/
HN comments: http://news.ycombinator.com/item?id=2884141
HN comments: http://news.ycombinator.com/item?id=2884141
I remember the days when ray tracing one frame would take several hours or even days. This just kinda blew my mind a bit.
They still do in the VFX industry - 48 hours+ is not uncommon when using Arnold. The difference is, these days, the output is literally physically photo-realistic, with fully-accurate GI lighting and accurate BSDF material interaction. There's normally over 200GB of geometry and over 100GB of textures too :)
Interesting. There will always be high-end stuff I guess. The stuff in this demo was probably about as good as my 1989 Amiga 500 was capable of doing in several hours, but done in 20 seconds.
The Amiga was 7mhz. I'm now running quad core i7 2.2ghz, so I'm - what? - 300 times faster on one chip? 1200 times faster potentially? 20 seconds now would have been (20*300) = 6000 seconds, close to 2 hours. I guess this shouldn't be all that shocking, but it is.
The Amiga was 7mhz. I'm now running quad core i7 2.2ghz, so I'm - what? - 300 times faster on one chip? 1200 times faster potentially? 20 seconds now would have been (20*300) = 6000 seconds, close to 2 hours. I guess this shouldn't be all that shocking, but it is.
It's very difficult to say, given that we've got much better branch prediction, caching, pipelining of instructions, SSE (4 float ops at once), etc.
On top of that, different rendering algorithms, optimisations, biased-vs-unbiased.
http://imgur.com/MIFWC
For example, took 12 seconds to render on a quad core i7, but that's 512 unbiased samples per pixel, and 5 bounce global illumination, so that's around 2,013,265,920 rays sent in 12 seconds, which isn't bad.
On top of that, different rendering algorithms, optimisations, biased-vs-unbiased.
http://imgur.com/MIFWC
For example, took 12 seconds to render on a quad core i7, but that's 512 unbiased samples per pixel, and 5 bounce global illumination, so that's around 2,013,265,920 rays sent in 12 seconds, which isn't bad.
Don't forget that the Amiga demo was probably (optimized) machine code while this demo is in JavaScript. That should add a factor 1000 to 10000 to your estimate. Which sounds correcter, as so much more has happened other than increase of processor frequency.
I'm not referring to any particular demo - many of the animations for Amiga were raytraced animations, but no one claimed it was realtime raytracing. I was referring just to the time it took to render a single frame of an animation.
re: the juggler amiga demo - from http://home.comcast.net/~erniew/juggler.html:
The images were generated with a standard Amiga with 512K memory. A ray tracing method was used, which simulates rays of light reflecting within a mathematically defined scene. Each image requires the calculation of 64,000 light rays and takes approximately 1 hour to generate. An image is compressed to about 10K bytes for storage. Images are expanded in less than 30 milliseconds. The Amiga hold and modify mode is employed so that up to 4096 colors can be displayed at one time.
==============
So... 1 hour for each frame... hrm...
re: the juggler amiga demo - from http://home.comcast.net/~erniew/juggler.html:
The images were generated with a standard Amiga with 512K memory. A ray tracing method was used, which simulates rays of light reflecting within a mathematically defined scene. Each image requires the calculation of 64,000 light rays and takes approximately 1 hour to generate. An image is compressed to about 10K bytes for storage. Images are expanded in less than 30 milliseconds. The Amiga hold and modify mode is employed so that up to 4096 colors can be displayed at one time.
==============
So... 1 hour for each frame... hrm...
the output is literally physically photo-realistic, with fully-accurate GI lighting and accurate BSDF material interaction
This isn't true at all.
At what point are the equations "accurate"? What margin of error is acceptable?
We still have a long way to go before we can claim accurate lighting equations.
This isn't true at all.
At what point are the equations "accurate"? What margin of error is acceptable?
We still have a long way to go before we can claim accurate lighting equations.
Erm, yes it is, with Metropolis light transport...
48+ hours per frame??
I worked on the Garfield movies - live action with CG cats - and frames with Garfield in it required between 600-900 render hours. This is due to the physically based animation support for internal body motions and similar physics for all the fur. I've still got the render stats, because I was the render farm wrangler for those jobs...
yep :)
Pre-render steps (building the BVH/KDTree, caching transformed geometry, caching textures and building mipmaps) can take 2 hours before the rendering even starts :)
And this is on a machine with 32 i7 cores and 96 GB of RAM.
There's a reason SPI and Weta (and the other CG/VFX companies, although those two have the biggest) have huge renderfarms...
Pre-render steps (building the BVH/KDTree, caching transformed geometry, caching textures and building mipmaps) can take 2 hours before the rendering even starts :)
And this is on a machine with 32 i7 cores and 96 GB of RAM.
There's a reason SPI and Weta (and the other CG/VFX companies, although those two have the biggest) have huge renderfarms...
I had to do a raytracer for a class in university this semester, too bad I didn't think of portals. It's almost a trivial example of recursive raytracing.
The interlacing is a nice touch too. I shuffled an array of pixels and filled it sequentially.
The low speed is unfortunate though. Any plans for using NaCl or Dart?
The interlacing is a nice touch too. I shuffled an array of pixels and filled it sequentially.
The low speed is unfortunate though. Any plans for using NaCl or Dart?
I've not looked much for optimization. First, what you can do is reduce the number of allocations. Instead of creating a new vector3 for each operation, you can do it in place.
Another way to optimize is to make all the ray calculation on the GPU with WebGL shaders. There are a lot of demos of real time small ray tracers. It works well because it's massively parallel and vector operations are hard-wired. The downside is it's harder to debug and you cannot make long operations or it will crash the graphic driver.
Another way to optimize is to make all the ray calculation on the GPU with WebGL shaders. There are a lot of demos of real time small ray tracers. It works well because it's massively parallel and vector operations are hard-wired. The downside is it's harder to debug and you cannot make long operations or it will crash the graphic driver.
Try doing a stochastic spread of the rays sent through each pixel, with attenuation based upon differences in the surfaces reached by the rays. I was able to create an adaptive raytracer with 4 test rays per pixel and up to 56 when adaptively needed. The speed gain is quite significant, with visual clarity equal to simpler renders requiring much more time.
You could use WorkerThreads to do it in tiles - that parallelises nicely and would give you almost linear speedup.
It's faster than what my Lisp raytracer used to be... I feel ashamed :/
Have you tried it on recent hardware?
In the same hardware (my 2008 Macbook). It was pretty much non-optimized at any level, and got out of hand when I added refraction and shadows the same day: the inner loops were a mess... I decided to refactor and grew tired before optimizing the loops 8-)
How does it work? Nothing happens here.
I'm on RHEL 6.2 with FF 3.6.24
It worked on Ubuntu 11.10 64 bit, Google Chrome browser, 6.5 year old machine with nVidia 6800. It took 29 seconds. It works on my newer 4 I5 core laptop running Ubuntu 11.10 and using Intel graphics, it took 17 seconds.
Click on one of the images on the top left and then click the button to start tracing. It took me a minute, also.