On 08/06/2016 06:06 PM, Orchid Win7 v1 wrote:
> After about an hour of squinting at the sparse ShaderToy documentation
> and making some educated guesses, I did eventually manage to build a
> trivial ray-tracer that runs in real-time. I have no idea how to do
> random number generation yet, but we'll see...

Yesterday I had another go at this, and hit a show-stopping snag: No 
flow control.

It seems that implementing reflection is essentially impossible. You 
can't do recursive functions. You can't do arrays. [Well, you can... but 
the array indices must be known at compile-time, thus negating all 
possible advantages of arrays.] You can't do while-loops with 
complicated break or continue conditions. You can't do function 
pointers... In short, it seems that all code jumps and data accesses 
must be statically known at compile-time.

Obviously, the rendering equation is inherently recursive. You fire a 
ray, which spawns further rays with are recursively traced like the 
first one. But without the ability to dynamically trace different 
primitives differently, or apply different surface characteristics 
dynamically, or basically do *anything* dynamically... You end up 
basically needing to write some kind of engine to *generate* the WebGL 
code, hard-coded to the particular geometry of your scene.

I see now why no computer game will ever use this technology. It's fast 
because it's *completely inflexible*.

I am now baffled as to how all the *other* people managed to do so much 
cool stuff in a language that abhors conditional branching... Clearly 
I'm going to have to cheat and look at the source code. But I fear I 
won't be able to comprehend any of it.

In summary, it appears that implementing reflection is mathematically 
impossible. I may perhaps still be able to realise my dream of rendering 
depth of field effects realistically. (Although without a nice detailed 
scene to look at, it might be rather disappointing...)

Post a reply to this message