Am 05.04.2010 16:19, schrieb Le_Forgeron:

> First question: what would be the space filling pattern ?
> The cubic system comes first to mind, but there is a few other (where
> are cristallographers when you need them ?)

Any and all periodic space tiling in 2D or 3D cartesian space can be 
projected to an equivalent square/cubic tiling simply by applying affine 
transformations and choosing suitable tiles.

Thus, all you'll really need for parameterization - besides the set of 
objects to repeat - is a set of up to 3 vectors (depending on whether 
you want to repeat along a line, a plane, or in 3D space) to specify the 
- possibly skewed - axes (and periods) of a suitable periodic tiling 
scheme. (Note that your set of objects might in itself have to duplicate 
certain substructures already.)

> Short of the system to fill the space, it might just be an issue of
> having a "csg" object to hold your repeated construction (inside a unit
> sphere ? rather than a unit cube ?) to translate on the fly the ray
> intersection's computation (whenever the ray would hit a sphere, a
> transformation (translation) is done to the ray to perform the children
> intersection, children assumed to be at origin)

Whatever the repeated object's bounding box, I'd suggest.

> Caveat: all_intersection method should be limited to a depth, or we are
> going to have issue.

That depends on implementation: If the actual handling would be done by 
object code, you're perfectly right; if it would be handled by tracing 
code, all_intersections could be left untouched (but care would still 
need to be taken to prevent endless iterations where.

> How would you name them ?
> clipka1D, clipka2D, clipka3D ?

Of course! :-P

Then again, a syntax like

   union {
     repeat {
       [ VECTOR [, VECTOR [, VECTOR ] ] ]
       [ max_recursion FLOAT ]
     ...
   }

would have the benefit of not adding any new keywords ;-).

Post a reply to this message