>> Interesting. On my browser, that just crashes.
>
> Odd. But then you did say half the examples on shadertoy didn't work on
> whatever browser you had. Tried Chrome/IE?

Yeah, it seems the smaller examples run just fine, but bigger ones freak 
it out. In particular, browsing the shaders seems to try to run too many 
shaders at once and break Opera. (And once it's broken, only restarting 
the browser will fix it. It just doesn't *try* any more.)

>> The difficulty is figuring out what surface was hit just from the
>> intersection coordinates.
>
> You could have an intersection struct with surface normal and material
> ID in it as well.

Material ID is something I hadn't thought of. (I'm trying to do a 
checkerboard for the ground, which makes calculating the colour... 
interesting.)

> You need to keep track of a "cumulative coefficient of reflection" value
> as you go (make it a vec3 if you want coloured reflections):
>
> vec3 CCOR = vec3(1,1,1);
> vec3 colour = vec3(0,0,0);
> for(int i=0;i<MAX_TRACE_DEPTH;i++)
> {
> isect = Raytrace();
> colour += CCOR * isect.diffuse_colour;
> CCOR *= isect.reflection_colour;
> }

I'm thinking about the associative/distributive property of the reals, 
though... If one object adds 4% blue and then reflects 95%, and the next 
object adds %6 yellow and reflects 50%, and the final object is green, 
you need

   ((green * 50%) + 6% yellow) * 95% + 4% blue

but the algorithm above gives

   ((4% blue * 95%) + 6% yellow) * 50% + green

which I don't think simplifies to the same result. You'd have to neither 
trace all the rays backwards (i.e., from scene to camera), which is 
laughably inefficient, or somehow store a history (array?) of all the 
intermediate steps so you can reverse them...

...then again, I think I'll just give up on reflection, and see if I can 
make the lens work with a checkerboard. :-P

Post a reply to this message