Thanks to all of you for the great advice!
I will consider all of it and try around a little to improve my poor POV-Ray
skills when it comes to things like arrays, macros and the like ...

The halton sequence is really a cool piece of code, I tried it and it renders
very quickly. I can imagine it's also useful for all kinds of things, like
abstract cityscapes, floating objects and things like that.
At first it seemed to me really miraculous how it worked, but I managed to put
the output values in a text object and now I slowly start to understand the
workings of macros a little, I hope.


Best wishes,

Simone

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> schreef in bericht 
news:web.4c688dc1d03a138b20e671e70@news.povray.org...
> Until I looked at his sketch I hadn't realised the property that each 
> subsequent
> value in the sequence is guaranteed to be almost maximally distance from 
> the
> previous one, and that you can use that to drive variations like object 
> colour
> or size (so the same types of tree are close to each other, but big trees 
> are
> always interspersed with small trees, etc). Really fascinating stuff.

These are interesting thoughts indeed. I certainly shall have to experiment 
with this. Thank you!

>
> I'd love to find the time to write up an article in the Wiki on them for 
> POVRay,
> but it's hard finding time with two young kids :-)

True. Put them to work on POV-Ray candy ;-)

Thomas

Post a reply to this message

On 16/08/2010 2:00 AM, Edouard wrote:
> I'd love to find the time to write up an article in the Wiki on them for POVRay,
> but it's hard finding time with two young kids:-)
>

As Thomas said, this will require experimenting with. :-D

And if you can find time to make two young kids then doing a Wiki 
article will be a breeze ;-)


-- 

Best Regards,
	Stephen

Post a reply to this message

Simone wrote:

> At first it seemed to me really miraculous how it worked, but I managed to put
> the output values in a text object

Note that there is also a #debug directive for text stream output.

Post a reply to this message

Edouard wrote:
> Can I suggest a different function than rand() for placing the cylinders - there
> is a mathematical set of functions call low discrepancy sequences, and the
> simplest one of those to implement in POV macros is a Halton Sequence. The
> output looks like the output from rand(), but the positions don't overlap (the
> positions it produces just fill in the spaces, so the points get more and more
> closely packed).

At first I was really excited by this, but then I started looking it up, 
and there appears to be a lot of repetition in Halton point sets... I'll 
have to try the code you provided to see how well it distributes the points.

I usually just test new elements against all other elements and place a 
point where there is enough space by evaluating the radii. It's a slow 
method, but must only be performed once per-application if the points 
are saved to an .inc file.

Sam

Post a reply to this message

Christian Froeschlin wrote:
> Simone wrote:
> 
>> At first it seemed to me really miraculous how it worked, but I 
>> managed to put
>> the output values in a text object
> 
> Note that there is also a #debug directive for text stream output.

This feature should not be underestimated... I might still be staring 
confusedly into my monitor if not for the ability to #debug my code O_x

Post a reply to this message

stbenge <myu### [at] hotmailcom> wrote:
> Christian Froeschlin wrote:
> > Simone wrote:
> >
> >> At first it seemed to me really miraculous how it worked, but I
> >> managed to put
> >> the output values in a text object
> >
> > Note that there is also a #debug directive for text stream output.
>
> This feature should not be underestimated... I might still be staring
> confusedly into my monitor if not for the ability to #debug my code O_x


Yes, thanks.
I have used this once, when I didn't know the size of some chess pieces and
where they are. But it took me some time before I understood that #debug is the
right thing for this because it sounded to me like the program should repair
some bugs ... :) , but obviously it's used for many other things.

"... but must only be performed once per-application if the points
are saved to an .inc file."

Do you use the #debug feature for this too? Or how do I tell pov-ray to put such
points into an include file?

Best wishes,

Simone

Post a reply to this message

On 16/08/2010 8:49 PM, Simone wrote:
> Do you use the #debug feature for this too? Or how do I tell pov-ray to put such
> points into an include file?
>

Have a read of the help section, "3.2.2.3  File I/O Directives".
And section "3.2.1.7.3  String Functions".

A lot to take in but ask if you need help.


-- 

Best Regards,
	Stephen

Post a reply to this message

"stbenge" <myu### [at] hotmailcom> schreef in bericht 
news:4c697734@news.povray.org...
> At first I was really excited by this, but then I started looking it up, 
> and there appears to be a lot of repetition in Halton point sets... I'll 
> have to try the code you provided to see how well it distributes the 
> points.

How can you tell that, Sam? My tests appear not to overlap but I have no way 
(yet) to really be sure. What I am pretty sure about is that an additional 
collision test is necessary if number and size of the objects become too 
large for a given space, though. Otherwise, the bare locations seem not to 
repeat themselves within a given sequence, but I may be totally wrong of 
course.

>
> I usually just test new elements against all other elements and place a 
> point where there is enough space by evaluating the radii. It's a slow 
> method, but must only be performed once per-application if the points are 
> saved to an .inc file.

Yes, that is slow, but it works :-)

Thomas

Post a reply to this message

Thomas de Groot wrote:
> "stbenge" <myu### [at] hotmailcom> schreef in bericht 
> news:4c697734@news.povray.org...
>> At first I was really excited by this, but then I started looking it up, 
>> and there appears to be a lot of repetition in Halton point sets... I'll 
>> have to try the code you provided to see how well it distributes the 
>> points.
> 
> How can you tell that, Sam? My tests appear not to overlap but I have no way 
> (yet) to really be sure. What I am pretty sure about is that an additional 
> collision test is necessary if number and size of the objects become too 
> large for a given space, though. Otherwise, the bare locations seem not to 
> repeat themselves within a given sequence, but I may be totally wrong of 
> course.

I haven't tried Edouard's code yet, though I did search for some 
examples with Google's image search. The repetition is often very 
noticeable, as seen in the following images:

http://www.puc-rio.br/marco.ind/imagens/halton_2d.gif
http://www.mathworks.com/matlabcentral/fx_files/17457/1/halton.jpg
http://www.blitzcode.net/images/projects/project_150_big.png

The first and second examples repeat completely in one diagonal 
direction, and partially in another. The third is a bit harder to tell, 
but there is definitely some partial repetition present, even with the 
low number of points.

I typically test for pattern repetition by crossing my eyes at an image 
and seeing if the two images "lock in." Anybody can beat those "how many 
differences can you spot?" picture games in seconds if they would just 
cross their eyes... but what would be the fun in that? :)

>> I usually just test new elements against all other elements and place a 
>> point where there is enough space by evaluating the radii. It's a slow 
>> method, but must only be performed once per-application if the points are 
>> saved to an .inc file.
> 
> Yes, that is slow, but it works :-)

And it works well. It can handle circles of varying radii with 
absolutely no overlaps. I have tried a similar method in raster space, 
which works pretty well and allows for different shapes (like rotated, 
scaled rectangles), but the accuracy goes down because of the granularity.

Sam

Post a reply to this message