Re: [grt-talk] Some suggestions.

[Nikodemus Siivola]

On Thu, 8 May 2003, Anton N. Mescheryakov wrote:

> Currently, CSG seems to accept just two objects as its arguments while
> there isn't anything wrong in union/intersecton/difference of >2
> objects.

Update you CVS. The current csg-difference and csg-intersection functions
accept an arbitrary number of objects.

Of course, if you are referring to csg-*-intersect & co, they do accept
only two objects each for a very good reason: a CSG tree is a binary tree.

The user can specify something like:

 (csg-intersect a b c d)

which results in a tree like this:

 AND
   +-a
   +-AND
       +-b
       +-AND
           +-c
           +-d

Union, merge and inverse have not been implemented yet.

> intersects B, A intersects C but B and C doesn't intersect, testing of
> B-C intersection in futile. But it's up to octrees, IMO.

Not really: the construction of the CSG tree just has to be smart enough.

What will be interesting will be the co-operation between octrees and CSG
trees: the easy thing is to consider each CSG tree a single object for the
purposes of octree construction, but there are cases in which it's more
profitable to to allow the octree to split the CSG into multiple roots. (I
think, not sure.)

How this can be accomplished without human intervention is non-trivial to
me. But I do think that we should allow the user to dictate the spatial
subdivision at will: sometimes a human can easily know things the computer
would be hard pressed to infer. (Kind of like type-inference in lisp.)
The interface design for this is also a nice challenge.

> Speaking on octrees. When casting rays, vast majority of them simply
> miss and just take your time away. So why don't render the scene with
> some _very_ simple scanline algorythm (no shading at all) and don't cast
> initial rays for scene fragments there scanline didn't find anything?
> BTW, I hardly can find much of differences between the 1st generation of
> rays and Z-buffer methods...

Definitely.  We need a first-intersetion accelerator (or several).

The only problem Z-buffer version is that Z-buffer algorythms for implicit
surfaces tend to get comlicated pretty quickly. Not undoable, just more
difficult for arbitrary surfaces. If you feel like up to it, ... ;)

My current plan is to project the *bounding volumes* onto screen, and store
the depth of the closest bounding surface per pixel. This will allow the
tracing alogorith to step into correct point in octree without intermediate
tests.

Alternatively we could store sorted lists of objects per screen region (per
pixel or smallish group). Kind of like poor mans ray-sorting.

Plenty of things to do. Plenty of literature to read. Plenty of alternative
solutions. Life is good. ;)

Cheers,

  -- Nikodemus