>> Notice the isect function. In Java, we have /three/ functions for
>> efficiency;
>>
>> Haskell's lazy evaluation makes this quite unnecessary. All we need is
>> /one/ function which returns all intersections in a lazy list.
>
> You're wrong there.
>
> When querying the "first" intersection, you're not querying for "the
> first intersection that our algorithm cranks out", but "the intersection
> that is closest to the camera, of all the intersections cranked out by
> our algorithm".

In my implementation, it is an (unchecked) requirement that the result 
list is always returned sorted in depth order. For planes and spheres, 
this is trivial to arrange. For some more general shape where you can't 
easily determine ahead of time which intersection is nearest, that 
particular shape would have to perform explicit sorting. (This, 
naturally, destroys most of the laziness properties.)

>> You can certainly do things this way. There is a snag, however. If you
>> stick to Haskell 2010 (the currently published official language
>> specification), you cannot easily make a list of shapes.
>
> Heh. So standard Haskell obviously sucks as much as Java without generics.

...unless you scroll down to the bit where I show you exactly how to 
easily do this in standard Haskell. :-P

>> Notice, again, that we can fill out /all/ fields, and then lazy
>> evaluation will skip any calculations we don't need. In particular,
>> Surface types that don't depend on the surface normal can skip the
>> surface normal calculation.
>
> While that may sound nice, intersection computations might already have
> involved computation of interim results that would come in handy for
> normal computation as well; how do you address that?

Hmm, that's an interesting idea. I hadn't thought of that. None of the 
ray tracers I've ever implemented has had any shapes that complicated, 
so none of them would handle this duplication of work. It ought to be 
fairly straightforward (in Haskell or Java) to rectify that, however...

Post a reply to this message