- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 24 Feb 2010 01:35:50 -0800
On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak <mjs at apple.com> wrote: > > On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote: > > On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote: > > On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak <mjs at apple.com> wrote: > > - Raytracing a complex scene at high resolution. > > - Drawing a highly zoomed in high resolution portion of the Mandelbrot set. > > To be fair though, you could compute the pixels for those with just math, > > there is no need to have a graphics context type abstraction. > > http://people.mozilla.com/~sicking/webgl/ray.html > > I did not think it was possible to write a proper raytracer for arbitrary > content all as a shader program, but I do not know enough about 3D graphics > to know if that demo is correct or if that is possible in general. Point > conceded though. The big thing that GLSL is lacking is a stack, making it impossible to recurse properly. This isn't a huge problem to work around, though can result in ugly code. Especially if you want to support transparent objects, in which case you'll essentially have to unroll recursion manually by copying code. This of course makes it impossible to recurse to arbitrary levels, though that is something you generally don't want to do anyway in a ray tracer since it costs a lot of CPU (or in this case GPU) cycles for very little visual gain. > http://people.mozilla.com/~sicking/webgl/juliaanim.html > http://people.mozilla.com/~sicking/webgl/mandjulia.html > > Neither of examples you posted seems to have the ability to zoom in, so I > don't think they show anything about doing this to extremely high accuracy. > But I see your point that much of this particular computation can be done on > the GPU, up to probably quite high limits. Replace this example with your > choice of non-data-parallel computation. > > Following the links, this demo does do zoom, but it will go all jaggy past a > certain zoom level, presumably due to limitations of GLSL. > http://learningwebgl.com/lessons/example01/? Indeed. Zooming is no problem at all and doesn't require any heavier math than what is done in my demo. I experimented with allowing the animations to be stopped at arbitrary points and then allowing zooming. However it required more UI work than I was interested in doing at the time. The reason the demo goes jaggy after a while is due to limitations in IEEE 754 floats. But I should clarify that my point wasn't that WebGL makes off-main-thread graphics processing unneeded. I just thought it was funny that the two examples you brought up were exactly the things that I had experimented with. Although I wouldn't be surprised if a lot of the image processing effects that people want to do can be written as shader programs. Would definitely be interesting to know if WebGL could be supported on workers. / Jonas
Received on Wednesday, 24 February 2010 01:35:50 UTC