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

Stephen <mca### [at] aolDOTcom> wrote:
> 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

File I/O Directives ... that's it. Thanks!

Best wishes

Simone

Post a reply to this message

"stbenge" <myu### [at] hotmailcom> schreef in bericht 
news:4c6acef8@news.povray.org...
> 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.
>

What do you think of the image rendered with Edouard's code, I uploaded to 
p.b.i.?

Thomas

Post a reply to this message

How should I write a gaussian distribution using halton (in 2D and 3D)? I 
tried a couple of things but it is not right.

Thomas

Post a reply to this message

"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> How should I write a gaussian distribution using halton (in 2D and 3D)? I
> tried a couple of things but it is not right.

I'd try rejection sampling - create a function that gives the gaussian
probability distribution, then rand() to compare against the function and reject
the halton value if that test fails.

Cheers,
Edouard.

Post a reply to this message