http://meatfighter.com/labyrinth/

It's not my code or idea or anything. But the ability to play with 
algorithms like this and then output SDL instead of pixels is I think much 
better than having to write the ray-tracer yourself just cause you have a 
good idea for a picture. :-)

I like the whole randomly-generated maze bit too. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling together,
   but to different destinations.

Post a reply to this message

Am 03.04.2010 20:39, schrieb Darren New:
>
> It's not my code or idea or anything. But the ability to play with
> algorithms like this and then output SDL instead of pixels is I think
> much better than having to write the ray-tracer yourself just cause you
> have a good idea for a picture. :-)

I wonder whether it would be possible to write a POV-Ray patch to 
implement a "repeating CSG" object type, repeating a set of objects /ad 
infinitum/ in one, two or three directions (while still retaining the 
possibility of placing individual non-repeating objects, which seems 
reasonably difficult to me with the "infinity box" approach). Ideally 
with some pattern parameter to pick one out of multiple object sets for 
each "cell"...

Post a reply to this message

Le 05/04/2010 12:46, clipka nous fit lire :
> Am 03.04.2010 20:39, schrieb Darren New:
>>
>> It's not my code or idea or anything. But the ability to play with
>> algorithms like this and then output SDL instead of pixels is I think
>> much better than having to write the ray-tracer yourself just cause you
>> have a good idea for a picture. :-)
> 
> I wonder whether it would be possible to write a POV-Ray patch to
> implement a "repeating CSG" object type, repeating a set of objects /ad
> infinitum/ in one, two or three directions (while still retaining the
> possibility of placing individual non-repeating objects, which seems
> reasonably difficult to me with the "infinity box" approach). Ideally
> with some pattern parameter to pick one out of multiple object sets for
> each "cell"...

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

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)

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

Hint: intersection with planes might be enough to restrict the
repetition amongst various dimension.
Nevertheless, a 1D & 2D repetitions addition might be welcome for
computation's time. Both infinity, or 0 to infinity is also some
options, I would prefere only both infinity.
(and default repetion in 1D to be along X, 2D: X,Y)

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

CubicClosePacking (face centered cubic: ABCABC hexagonal of 12 spheres)
HexagonalClosePacking (ABAB alternance, 12 spheres)
CubeTiling (classical x,y,z cubic repetition)

? (derivative for 1D/2D/3D ?)

Post a reply to this message

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

clipka wrote:
> Am 05.04.2010 16:19, schrieb Le_Forgeron:
>> How would you name them ?
>> clipka1D, clipka2D, clipka3D ?
> 
> Of course! :-P

Hey, Warp got his POV-Ray keyword, why not you?

Post a reply to this message

Le 05/04/2010 18:20, clipka nous fit lire :

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

Adding a keyword is not difficult, and would avoid confusion of the
final users. (if you use the same keyword all over, we will end up with:
"a rose is a rose is a rose is a rose..." which are nice but painful to
understand)

repeat is currently used in warp, so it might be best to avoid it.
And it should be a name, which "repeat" is not.

due to mathematical background about infinity, what about:
aleph1, aleph2 & aleph3 ?
(well, strictly, the first one would be aleph0, but the number might be
clearer as the dimension... or not, aleph0/1/2 might be fine too)

duplicate ?
replica ?

I'm not sure the transformation from 3D filling to cubic would be
obvious (and you might need holes on some places, and it might be better
to code it once for each filling rather than applying specific
transforms all the time)

Post a reply to this message

On 05/04/2010 8:03 PM, Le_Forgeron wrote:
> repeat is currently used in warp, so it might be best to avoid it.
> And it should be a name, which "repeat" is not.
>
> due to mathematical background about infinity, what about:
> aleph1, aleph2&  aleph3 ?
> (well, strictly, the first one would be aleph0, but the number might be
> clearer as the dimension... or not, aleph0/1/2 might be fine too)
>
> duplicate ?
> replica ?
>

How about, say_again, say_again_again, say_again_again_again? :-)

-- 

Best Regards,
	Stephen

Post a reply to this message

Am 05.04.2010 21:03, schrieb Le_Forgeron:

>> would have the benefit of not adding any new keywords ;-).
>
> Adding a keyword is not difficult, and would avoid confusion of the
> final users. (if you use the same keyword all over, we will end up with:
> "a rose is a rose is a rose is a rose..." which are nice but painful to
> understand)

The policy is to avoid introducing more keywords where sensible, to 
avoid unnecessarily breaking legacy scenes that happen to use the same 
word for a variable.

> repeat is currently used in warp, so it might be best to avoid it.

Repeat is currently used in warp for pretty much the same purpose as 
proposed (at least for the 1D repeat): Specifying a vector and distance 
for repetition (though it has some limitations with warp). So why call 
the same thing differently?

> And it should be a name, which "repeat" is not.

Is "translate" or "rotate" a name?

> I'm not sure the transformation from 3D filling to cubic would be
> obvious (and you might need holes on some places, and it might be better
> to code it once for each filling rather than applying specific
> transforms all the time)

I guess macros should be enough to fill that gap.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> http://meatfighter.com/labyrinth/
>
> It's not my code or idea or anything. But the ability to play with
> algorithms like this and then output SDL instead of pixels is I think much
> better than having to write the ray-tracer yourself just cause you have a
> good idea for a picture. :-)
>


Shameless plug, from 1999!

http://www.irtc.org/ftp/pub/stills/1999-06-30/paths.jpg

Post a reply to this message

gregjohn wrote:
> Shameless plug, from 1999!
> http://www.irtc.org/ftp/pub/stills/1999-06-30/paths.jpg

Very sweet. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Yes, we're traveling together,
   but to different destinations.

Post a reply to this message