 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] san rrcom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka a écrit :
> 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.
Nah, wrong solution to a wrong issue.
Current editors made it easy to refactor a variable.
Moreover, if the #version is correct in the scene, the new keyword
should not trigger any issue at all (but I'm a bigger fan of: no
backward, break everything if it can be more simple to explain &
understand; even if I somehow appreciate backward compatibility).
We might need some java-coding-policy (about Capitalising/small char) to
avoid such sillyness in the futur... How do you want to extend the SDL
if you are limited to existing keywords... twisting the syntax is a very
bad idea, IMHO.
In fact, the lack of keywords is one big reason for failure of poly in
popularity: counting the coefficients is painfull when you have 34 of
them used by position. entering basic equation is a challenge, a write
only challenge as trying to read it back is even more complex, do not
even think about tunning it.
4x^4+3xy²-z = 0 looks simple... but the resulting array of numbers is a
hell to edit!
>
>> 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?
they are not objects, but update of objects.
Don't push it too far on bad faith, please.
>
>> 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.
I believe it would be quicker and more effective to cover the patterns
in the C++ code rather than with a transform.
I'm still wondering about the number of actual space filling pattern (3
so far in 3D: 1 with cube, 2 with spheres, and 2 in 2D: square, hexagon)
Any others you or others know of ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.04.2010 12:00, schrieb Le_Forgeron:
>> 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.
>
> Nah, wrong solution to a wrong issue.
Not my idea, by the way.
> Current editors made it easy to refactor a variable.
Not as easy as it /could/ be (as Microsoft has shown with its C#
development environment).
> We might need some java-coding-policy (about Capitalising/small char) to
> avoid such sillyness in the futur... How do you want to extend the SDL
> if you are limited to existing keywords... twisting the syntax is a very
> bad idea, IMHO.
Note that the policy is not "avoid new keywords at all costs", but
"avoid new keywords where sensible"; Official recommendation is that
user variables should begin with uppercase letters, while new keywords
are guaranteed to always be all lowercase, which theoretically should be
enough to avoid breaking any legacy scenes. But why risk breaking
noncompliant scenes when there's no real need to?
>>> 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?
>
> they are not objects, but update of objects.
> Don't push it too far on bad faith, please.
Did you actually /read/ my proposed syntax? In that proposal, "repeat"
would be nothing more than a /modification/ of the existing "union".
>>> 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.
>
> I believe it would be quicker and more effective to cover the patterns
> in the C++ code rather than with a transform.
As there are literally infinitely many regular space tilings, you can't
cover them all natively, and a generic variant will be needed anyway. So
to keep both code complexity and number of keywords low, I'd be more in
for making it the only variant supported natively. (Note that low code
complexity helps keep things speedy, too, by allowing to keep as much of
the code in CPU cache as possible.)
> I'm still wondering about the number of actual space filling pattern (3
> so far in 3D: 1 with cube, 2 with spheres, and 2 in 2D: square, hexagon)
> Any others you or others know of ?
You can't fill 3D space with spheres - it would leave gaps (unless you
allow for fractal filling).
2D space can be filled with either squares, regular hexagons, regular
triangles, or any sheared variation thereof. With tilings derived from
squares or regular triangles, you also have the option to arrange the
tiles in rows which are displaced against one another (think classic
brick tiling).
But you can also tile 2D space with a combination of octagons and
squares, or a combination of hexagons, squares and triangles. Or even
trapezoids.
All these tilings have one thing in common: By defining your tiles
differently, you can map all of them to sheared square tiling.
In 3D space tiling, you have quite a number of options, too; octagons
and tetrahedrons go together like a charm, for instance.
Again, by suitable re-definition of your tiles, you can map all of them
to sheared cubic tiling.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka a écrit :
> You can't fill 3D space with spheres - it would leave gaps (unless you
> allow for fractal filling).
I understood the initial idea as infinite repetition of a "unit" block
(box, sphere or whatever). Gap was irrevelant, but the pattern would be
regular.
There is 2 regular filling of infinite 3D with spheres, and 1 regular
filling with cube. The sphere's ones are more compact that the cubic
one. Is there others ? (which might be compact & regular with the right
volume)
BTW, about fractal, would a menger make sense ?
2D patterns for filling the plane, I made a few in 3.1g, for regular
tiled floor. tiling of 2D infinite plane can also be irregular (c.f.
Penrose) but I do not want to explore that.
(Penrose aperiodic tiling use 2 tiles, so you might provide 2 "objects"
and let the filling use them as needed... now, I do not know an easy
function to determine for a point on the plane which tile it would be
and what would be its orientation until you actually pave the plane till
the points... that can be a bit expensive in cpu, and unaffordable in
memory if caching that)
P.S: I hate overloaded modifiers on existing object, I tought your
repeat was a new CSG object, but if it must be inside a union, I do not
like it (what about using it inside an intersection... and other CSG ?
painfull)
intersection {
object { A }
union {
repeat {
object { B }
}
}
}
intersection {
object { A }
aleph3 {
object { B }
}
}
Or even
#declare clipka = aleph3 { ... };
and not
#declare clipka = union { repeat { ... } };
--
A: Because it messes up the order in which people normally read text.<br/>
Q: Why is it such a bad thing?<br/>
A: Top-posting.<br/>
Q: What is the most annoying thing on usenet and in e-mail?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 07.04.2010 15:36, schrieb Le_Forgeron:
> 2D patterns for filling the plane, I made a few in 3.1g, for regular
> tiled floor. tiling of 2D infinite plane can also be irregular (c.f.
> Penrose) but I do not want to explore that.
Neither do I. Aperiodic tiling is pretty unsuitable for procedural
object generation.
It is possible, but as demonstrated by the crackle pattern (which is
aperiodic as well) it can eat memory like mad under certain circumstances.
> P.S: I hate overloaded modifiers on existing object, I tought your
> repeat was a new CSG object, but if it must be inside a union, I do not
> like it (what about using it inside an intersection... and other CSG ?
> painfull)
>
> intersection {
> object { A }
> union {
> repeat {
> object { B }
> }
> }
> }
>
> intersection {
> object { A }
> aleph3 {
> object { B }
> }
> }
Um... no, you still misunderstood:
intersection {
object { A }
union {
repeat { x, y*2, z }
object { B }
}
}
Same construct should go for merge{} of course.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> 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"...
My goodness, did someone just voice support for aperiodic tiling?? Because that
would be neat if you could do it for objects as well as textures (using, say, an
array of tiles, the number of which matches or exceeds the amount of tiles
required). I like the idea of having, say, an array of Wang tiles of images (or
objects) that you can use... however you want, I guess.
A while back I played with writing a function that would generate a Wang tileset
and map the tiles to a 2d rectangular area, but I got bogged down because I was
using a very naive brute force matching algorithm. Anyway, yeah...
Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
