Am 28.06.2012 12:07, schrieb Invisible:

> Notice the isect function. In Java, we have /three/ functions for
> efficiency; one function only bothers to compute /whether/ there are any
> intersections, another that only bothers to compute the /first/
> intersection, and another which computes /all/ intersections.
>
> Haskell's lazy evaluation makes this quite unnecessary. All we need is
> /one/ function which returns all intersections in a lazy list.
> Inspecting whether the list is empty evaluates just enough of isect to
> answer this question, and no more. And obviously, accessing only the
> first solution does not cause any further solutions to be computed. Note
> we're actually doing /better/ than Java: If our CSG happens, at
> run-time, to need the first /three/ intersections but no further, then
> only these are computed.

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 many cases, to get this answer you'll need to compute /all/ 
intersections and sort them by spatial distance, which will necessarily 
trigger evaluation.


> 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. Because all the
> elements of a list have to be of identical types. And (for example)
> Sphere is not the same type as Plane, even if they do both implement the
> Shape class (and possibly other classes like Eq or Show). There is no
> way to say "a list of everything that has these methods".

Heh. So standard Haskell obviously sucks as much as Java without generics.

> 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?

Post a reply to this message