Hi folks, I am new to the software and this community. I am a year 1 engineer
and am recently required to learn this software. So far, I could do some very
simple coding work only and my aim is to make a code to generate a scene
consisting of numerous sand grains like
http://news.povray.org/povray.binaries.images/attachment/%3C4d98c518%40news.povray.org%3E/27841-grains.jpg
Could anyone tell me how to stack some objects without them being overlapping
like the picture above? Besides, how could I approach to generate such code
(using array? rand? or any other?) Thank you!

Post a reply to this message

Welcome, Ari   :)

I'd suggest having a look at Jonathan Hunt's excellent pebbles.pov file:

http://news.povray.org/povray.text.scene-files/thread/%3C48d158e3$1@news.povray.org%3E/

If you're interested in experimenting with some simple self-written scenes first
/ along the way, I'd suggest learning some of the random functions:

http://www.f-lohmueller.de/pov_tut/random/random6e.htm

The easiest way to place your grains so that they don't intersect is to treat
them as perfect spheres, and make sure that the distance between the centers is
no less than the sum of the radii.

You can look into structuring your placement algorithm so that it's as fast as
possible.   There are "naive" ways, and then there are ways that make use of
subdividing the space to make the search for a valid place to place a new grain
a lot faster.

https://www.google.com/search?q=algorithm+o

http://news.povray.org/povray.newusers/message/%3C53260cc5%40news.povray.org%3E/#%3C53260cc5%40news.povray.org%3E


[As an aside, is there an easy mechanism by which I can access the thread for
the given image from the image's URL?]
http://news.povray.org/povray.binaries.images/attachment/%3C4d98c518%40news.povray.org%3E/27841-grains.jpg

Post a reply to this message

On 6/15/2017 4:04 PM, Ari wrote:
> Hi folks, I am new to the software and this community. I am a year 1 engineer
> and am recently required to learn this software.

Ah! ha! the evil professor strikes again. :)


> So far, I could do some very
> simple coding work only and my aim is to make a code to generate a scene
> consisting of numerous sand grains like
>
http://news.povray.org/povray.binaries.images/attachment/%3C4d98c518%40news.povray.org%3E/27841-grains.jpg

It would gave been better if you had posted the link to the thread. That 
way the answer might be in it. Or at least a good clue.

> Could anyone tell me how to stack some objects without them being overlapping
> like the picture above? Besides, how could I approach to generate such code
> (using array? rand? or any other?) Thank you!
>

What you will want to use is the trace command to find out the distance 
to the object below. You also might want to use min_extent & max_extent 
to return the minimum and maximum coordinates of a #declared object's 
bounding box. ( <-- straight from the help file :-) )

It is not trivial what you want to do, btw.
I am sure you will get help here in the form of general pointers to help 
you work it out. :-)
Remember your evil professor may be reading this thread. ;-)

-- 

Regards
     Stephen

Post a reply to this message

As Stephen said, placing lots of objects so that don't overlap or intersect is
not trivial-- but it CAN be done, of course. With the proper coding in POV-Ray's
"scene description language" (SDL), just about *anything* is possible. (By the
way, just placing lots of objects randomly *is* trivially simple, using
seed(...), rand(...), and a #while loop or #for loop. But there's a very good
chance that some/many of the objects WILL overlap.)

Personally, I haven't tried making a scene like yours, with lots of
NON-overlapping random objects. But it's an important coding concept, one that
can be used in so *many* ways. I need to learn it as well! ;-)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> As Stephen said, placing lots of objects so that [they] don't overlap or intersect
is
> not trivial-- but it CAN be done, of course.

Well, I'd have to say that writing the code to do it isn't complicated, and may
indeed be "trivial".
Writing GOOD code that minimizes the number of intersection tests, and
efficiently fills the interstices IS a task that requires a fair amount of
education, knowledge, forethought, experience, creativity, skill, talent, and
inspiration.
But I think there are likely enough extant examples on the web of things that
are close enough so that he can implement it in a reasonable amount of time.

> With the proper coding in POV-Ray's
> "scene description language" (SDL), just about *anything* is possible.

Indeed.  :)  I like to keep everything in my scenes wholly in POV-Ray, and
completely generated by the SDL, if at all possible.
Sometimes it's not exactly "practical" - but proof-of-concept projects rarely
are.


Another thought just occurred to me - a wicked fast way to do something very
close to this, with no need for any sort of coding whatsoever.
It all lies in what Form you choose to code this in.  I'll just let that hint of
an idea Crackle on the back burner for a while until the coding for it becomes
Solid.

;)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

>...a task that requires a fair amount of
> education, knowledge, forethought, experience, creativity, skill, talent, and
> inspiration.

Yeah; I'm working on those ;-)

I need a Star Trek 'brain boost'

Post a reply to this message

On 6/15/2017 8:46 PM, Kenneth wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
>
>> ...a task that requires a fair amount of
>> education, knowledge, forethought, experience, creativity, skill, talent, and
>> inspiration.
>
> Yeah; I'm working on those ;-)
>

I gave up on that years ago and signed a long contract in blood with Satan.


> I need a Star Trek 'brain boost'
>
>
As always. :)

https://www.youtube.com/watch?v=FCARADb9asE

-- 

Regards
     Stephen

Post a reply to this message

On 15-6-2017 20:43, Bald Eagle wrote:

> Another thought just occurred to me - a wicked fast way to do something very
> close to this, with no need for any sort of coding whatsoever.
> It all lies in what Form you choose to code this in.  I'll just let that hint of
> an idea Crackle on the back burner for a while until the coding for it becomes
> Solid.
>
> ;)
>
>

That is really wicked!! ;-)

-- 
Thomas

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Welcome, Ari   :)
>
> I'd suggest having a look at Jonathan Hunt's excellent pebbles.pov file:
>
>
http://news.povray.org/povray.text.scene-files/thread/%3C48d158e3$1@news.povray.org%3E/
>
> If you're interested in experimenting with some simple self-written scenes first
> / along the way, I'd suggest learning some of the random functions:
>
> http://www.f-lohmueller.de/pov_tut/random/random6e.htm
>
> The easiest way to place your grains so that they don't intersect is to treat
> them as perfect spheres, and make sure that the distance between the centers is
> no less than the sum of the radii.
>
> You can look into structuring your placement algorithm so that it's as fast as
> possible.   There are "naive" ways, and then there are ways that make use of
> subdividing the space to make the search for a valid place to place a new grain
> a lot faster.
>
> https://www.google.com/search?q=algorithm+o
>
>
http://news.povray.org/povray.newusers/message/%3C53260cc5%40news.povray.org%3E/#%3C53260cc5%40news.povray.org%3E
>
>
> [As an aside, is there an easy mechanism by which I can access the thread for
> the given image from the image's URL?]
>
http://news.povray.org/povray.binaries.images/attachment/%3C4d98c518%40news.povray.org%3E/27841-grains.jpg
Thank you for the useful information, Eagle!
I would try to read them and see if I could be equipped with such important
skills.
By the way, the thread URL is
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4d97bab0dc7be259e5cacc00%40news.povray.org%3E/?mtop=360023
 :D

Post a reply to this message

On 15-6-2017 18:27, Bald Eagle wrote:

> [As an aside, is there an easy mechanism by which I can access the thread for
> the given image from the image's URL?]
>
http://news.povray.org/povray.binaries.images/attachment/%3C4d98c518%40news.povray.org%3E/27841-grains.jpg
>

The name Samuel Benge imposes itself on me for some reason, but I am not 
really sure and I cannot find anything related to this in the code I 
have from him. The image is very familiar and I remember we have 
discussed this in the (recent?) past. So, yes indeed, we need a better 
link to the thread.

-- 
Thomas

Post a reply to this message

On 6/16/2017 7:57 AM, Ari wrote:
> By the way, the thread URL is
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4d97bab0dc7be259e5cacc00%40news.povray.org%3E/?mtop=360023


I read the thread and if I understood it*. Sam used an external program, 
he developed himself, to calculate the positions of the grains.
So, in my opinion, unless using a third party program like bullet 
physics or Blender is acceptable. Then it would be very difficult to get 
the quality of Sam's image. But since you are a first year engineering 
student. It might be acceptable to use tools in addition to PovRay.

*

I am no mathematician.

It raises an interesting philosophical question.

Were you given that image and told to reproduce it or did you pick it 
yourself?
Does the person who gave you the problem have a solution?
And in an engineering frame. What tolerances do you need to work to?


I said that I was no mathematician and that is two questions. ;-)



-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> On 6/16/2017 7:57 AM, Ari wrote:
> > By the way, the thread URL is
> >
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4d97bab0dc7be259e5cacc00%40news.povray.org%3E/?mtop=360
023
>
> I read the thread and if I understood it*. Sam used an external program,
> he developed himself, to calculate the positions of the grains.

A wizard for sure, as are many others. I missed so much all those years ago but
already had seen plenty being done by Samuel.

I guess if I were to attempt my own "stacking stones" it would probably be
something like I had used for object interactions with simplistic 'sphere of
influence' for mass and gravity when I was doing rudimentary space simulations
in Basic programming (circa 1980's).
Not ideal for this, even if I could get it right in POV-Ray.

Bob

Post a reply to this message

On 6/16/2017 10:18 AM, omniverse wrote:
> Stephen <mca### [at] aolcom> wrote:
>> On 6/16/2017 7:57 AM, Ari wrote:
>>> By the way, the thread URL is
>>>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4d97bab0dc7be259e5cacc00%40news.povray.org%3E/?mtop=360
> 023
>>
>> I read the thread and if I understood it*. Sam used an external program,
>> he developed himself, to calculate the positions of the grains.
>
> A wizard for sure, as are many others. I missed so much all those years ago but
> already had seen plenty being done by Samuel.
>

Yes a wizard. I wonder when he will reappear to drop off another gem.

> I guess if I were to attempt my own "stacking stones" it would probably be
> something like I had used for object interactions with simplistic 'sphere of
> influence' for mass and gravity when I was doing rudimentary space simulations
> in Basic programming (circa 1980's).

Ah! basic. Now you are talking. :)
I managed to get a lander program working on a Casio calculator, in basic.

> Not ideal for this, even if I could get it right in POV-Ray.
>


I can see it working on rectangular stones as in a dry stone dyke. You 
would not have to be too concerned about gaps between rounded stones, I 
think.


-- 

Regards
     Stephen

Post a reply to this message

"Ari" <win### [at] yahoocomhk> wrote:

> By the way, the thread URL is
>
http://news.povray.org/povray.binaries.images/thread/%3Cweb.4d97bab0dc7be259e5cacc00%40news.povray.org%3E/?mtop=36002
3


Aha.
That was a good read, and I'd say that some excellent info is contained therein
- especially the scene code and that last post.

Up to this point, I'd say that the focus has been on using a random placement as
the fundamental method by which to build the pile, however, a stepwise #while
loop that built the pile up in strata would be a different approach - with
different advantages and challenges.

I'd say that there's a whole world of interesting algorithmic material out there
that could be applied to this, and certainly the Graphics Gems series and some
of those Numerical Recipes type code examples might help.
You might want to take a look at things like Appolonian Gaskets, Steiner circles
and spheres, canal and channel surfaces, fractals, closest packing schemes and
crystallography, and Voronoi diagrams and Delaunay triangulations.

http://paulbourke.net/fractals/apollony/


The key at this point though, is to keep it simple and fast enough to get the
job done.  Don't "let the perfect be the enemy of the good." ;)

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:
> .... Sam used an external program,
> he developed himself, to calculate the positions of the grains.

I'd say that he probably used Voroi++
http://math.lbl.gov/voro++/examples/

which from the download page, says that the output can be used in POV-Ray
http://math.lbl.gov/voro++/download/

What would be nice would be a way to shell out to Voroi++ to generate the data
for a scene and then render it.

I just don't know how to do that ([like many things] yet).

Post a reply to this message

On 6/16/2017 6:10 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>> .... Sam used an external program,
>> he developed himself, to calculate the positions of the grains.
>
> I'd say that he probably used Voroi++
> http://math.lbl.gov/voro++/examples/
>
> which from the download page, says that the output can be used in POV-Ray
> http://math.lbl.gov/voro++/download/
>
> What would be nice would be a way to shell out to Voroi++ to generate the data
> for a scene and then render it.
>
> I just don't know how to do that ([like many things] yet).
>
>
It is not really that difficult. At least it wasn't in Ver 3.5. When I 
last used the function. You write a text file in PovRay with the 
variables you need and get the 3rd party software to export the results 
of the calculations to a text file that PovRay can read.
Yes this would be an animation even if it is only two frames or a frame 
per layer.

I ask myself if something this complex is appropriate for a first year 
engineering course.  But then my first year at university detailed 
thermionic valves and ne'er a mention of semiconductors. :) So things 
might have changed.

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> It is not really that difficult. At least it wasn't in Ver 3.5. When I
> last used the function. You write a text file in PovRay with the
> variables you need and get the 3rd party software to export the results
> of the calculations to a text file that PovRay can read.
> Yes this would be an animation even if it is only two frames or a frame
> per layer.

I guess my question was whether or not Voro++ is set up to accept comman-line
parameters and return a file for immediate processing by POV-Ray.
If so, then it would be of great interest to those who have a continuing
interest in having direct access to the set of coordinates used for the crackle
pattern - by supplanting crackle with a Voro++ data file, that would be a great
workaround.

> I ask myself if something this complex is appropriate for a first year
> engineering course.  But then my first year at university detailed
> thermionic valves and ne'er a mention of semiconductors. :) So things
> might have changed.

It ought to be perfectly fine.
I remember the engineers on my floor constantly being immersed in Statics:

http://ruina.tam.cornell.edu/Book/RuinaPratap8-21-10.pdf

Post a reply to this message

Am 2017-06-16 03:35, also sprach Stephen:

> I read the thread and if I understood it*. Sam used an external program, 
> he developed himself, to calculate the positions of the grains.

I, too, use a Java program to position grains. I found SDL to be 
hideously slow when doing a 1600 x 1600 loop. ;)
http://www.buckosoft.com/tteoac/video/frames/ttfo0177.png

I love Sam's idea; pick a position and then alter the blob's shape and 
size to fit the position.


-- 
dik

Post a reply to this message

Omg, Guys!
I just cannot believe how generous and warm this community is.
I am sorry that I just completely immersed myself in this software (I only got 2
months to learn this technique :( And it is making me anxious now) therefore I
cannot check this thread frequently. Thanks again for the big help! Even though
I cannot reply the messages one by one, I swear I would read all the useful
information I have received. Again, I just cannot how generous this community
could be at the first glance. A big shoutout to all of you :D.

Post a reply to this message

On 6/17/2017 9:02 AM, Ari wrote:
> Omg, Guys!
> I just cannot believe how generous and warm this community is.

Oh! you have not received the invoice, yet. :)

-- 

Regards
     Stephen

Post a reply to this message

On 17-6-2017 10:13, Stephen wrote:
> On 6/17/2017 9:02 AM, Ari wrote:
>> Omg, Guys!
>> I just cannot believe how generous and warm this community is.
>
> Oh! you have not received the invoice, yet. :)
>

I believe I sent it yesterday night... but as I forgot to drink my dried 
toadstool tea, I may have been remiss. :-0

-- 
Thomas

Post a reply to this message

On 6/16/2017 9:25 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> It is not really that difficult. At least it wasn't in Ver 3.5. When I
>> last used the function. You write a text file in PovRay with the
>> variables you need and get the 3rd party software to export the results
>> of the calculations to a text file that PovRay can read.
>> Yes this would be an animation even if it is only two frames or a frame
>> per layer.
>
> I guess my question was whether or not Voro++ is set up to accept comman-line
> parameters and return a file for immediate processing by POV-Ray.
> If so, then it would be of great interest to those who have a continuing
> interest in having direct access to the set of coordinates used for the crackle
> pattern - by supplanting crackle with a Voro++ data file, that would be a great
> workaround.
>

I misunderstood.

>> I ask myself if something this complex is appropriate for a first year
>> engineering course.  But then my first year at university detailed
>> thermionic valves and ne'er a mention of semiconductors. :) So things
>> might have changed.
>
> It ought to be perfectly fine.
> I remember the engineers on my floor constantly being immersed in Statics:
>
> http://ruina.tam.cornell.edu/Book/RuinaPratap8-21-10.pdf
>
>

It goes on forever -- and -- oh my God! -- it’s full of squiggles!

;)


-- 

Regards
     Stephen

Post a reply to this message

On 6/17/2017 7:12 AM, dick balaska wrote:
> Am 2017-06-16 03:35, also sprach Stephen:
>
>> I read the thread and if I understood it*. Sam used an external
>> program, he developed himself, to calculate the positions of the grains.
>
> I, too, use a Java program to position grains. I found SDL to be
> hideously slow when doing a 1600 x 1600 loop. ;)
> http://www.buckosoft.com/tteoac/video/frames/ttfo0177.png
>

I liked that part. :)

> I love Sam's idea; pick a position and then alter the blob's shape and
> size to fit the position.
>
>

I suspect that could be classified as cheating. ;)

-- 

Regards
     Stephen

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:


> I, too, use a Java program to position grains. I found SDL to be
> hideously slow when doing a 1600 x 1600 loop. ;)
> http://www.buckosoft.com/tteoac/video/frames/ttfo0177.png

It's always helpful when expediency is the goal -  to recognize the practical
solutions and take the path of least resistance.

> I love Sam's idea; pick a position and then alter the blob's shape and
> size to fit the position.

Yes, that's an interesting idea - well worth looking into to see how difficult
that would be to do well.

I was thinking something along the lines of this:

https://www.researchgate.net/figure/273284325_fig7_Figure-7-An-example-of-a-Voronoi-diagram-in-Laguerre-geometry-for-a-
set-of-multi-sized

Where the spaces and centers are well defined, and then the sphere radii could
be easily computed.  That would get one far along the path.  Although I think
that the appropriate crackle metric and offset settings would get it all done
lickety-split.

Post a reply to this message

There's also the related isosurface method:

http://www.econym.demon.co.uk/isotut/printable.htm#CH_pigment

http://www.econym.demon.co.uk/isotut/pigment.jpg

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> dick balaska <dic### [at] buckosoftcom> wrote:
>
>
> > I, too, use a Java program to position grains. I found SDL to be
> > hideously slow when doing a 1600 x 1600 loop. ;)
> > http://www.buckosoft.com/tteoac/video/frames/ttfo0177.png
>
> It's always helpful when expediency is the goal -  to recognize the practical
> solutions and take the path of least resistance.
>
> > I love Sam's idea; pick a position and then alter the blob's shape and
> > size to fit the position.
>
> Yes, that's an interesting idea - well worth looking into to see how difficult
> that would be to do well.
>
> I was thinking something along the lines of this:
>
>
https://www.researchgate.net/figure/273284325_fig7_Figure-7-An-example-of-a-Voronoi-diagram-in-Laguerre-geometry-for-
a-
> set-of-multi-sized
>
> Where the spaces and centers are well defined, and then the sphere radii could
> be easily computed.  That would get one far along the path.  Although I think
> that the appropriate crackle metric and offset settings would get it all done
> lickety-split.

Hi, everyone.
I have been spending time searching on the internet and reading your guys'
information. However, I realized almost all of them required "some mathematical
background", especially Voronoi Diagram being shown the most frequently. I try
my best to understand them but I can't due to the lack of Maths background(I
only know some integration/sequence and differentiation from classes :( ). I
then try to work with an external program but I don't how to make use of it
well. (I installed the pyvoro in Python) So, I just went back to the basic now.
( Damn, I am stupid! Just want to cry in a corner) So far I just wrote this one:

#declare Grain = array[10000]   ;
#declare Nr = 0    ;
#declare Position = seed(100)  ;
#declare Size = seed(123)   ;
#while (Nr < 10000)
    sphere{<rand(Position), rand(Position), rand(Position)>, rand(Size)*.1
            pigment {color rgb<rand(Size), rand(Size), rand(Size)>} }
    #declare Grain[Nr] = sphere{<rand(Position), rand(Position),
rand(Position)>, rand(Size)*.1
            pigment {color rgb<rand(Size), rand(Size), rand(Size)>} }
    #declare Nr = Nr + 1;
#end

I think I will then try to develop it a little bit further according to the
'distance test formula' from the 'Pebbles' example. My idea now is to test every
Grain[Nr] vs Grain[Nr-1] Grain[Nr-2]......Grain[0] if their distance between two
centers is smaller than their sum of radii. It's 3 a.m. now here guys. I think I
might just sleep and work it out tomorrow. Thank you guys for helping me at
first but I think I have to say I am too stupid to understand them :'(.

Post a reply to this message

Hi, everyone.
I have been spending time searching on the internet and reading your guys'
information. However, I realized almost all of them required "some mathematical
background", especially Voronoi Diagram being shown the most frequently. I try
my best to understand them but I can't due to the lack of Maths background(I
only know some integration/sequence and differentiation from classes :( ). I
then try to work with an external program but I don't how to make use of it
well. (I installed the pyvoro in Python) So, I just went back to the basic now.
( Damn, I am stupid! Just want to cry in a corner) So far I just wrote this one:

#declare Grain = array[10000]   ;
#declare Nr = 0    ;
#declare Position = seed(100)  ;
#declare Size = seed(123)   ;
#while (Nr < 10000)
    sphere{<rand(Position), rand(Position), rand(Position)>, rand(Size)*.1
            pigment {color rgb<rand(Size), rand(Size), rand(Size)>} }
    #declare Grain[Nr] = sphere{<rand(Position), rand(Position),
rand(Position)>, rand(Size)*.1
            pigment {color rgb<rand(Size), rand(Size), rand(Size)>} }
    #declare Nr = Nr + 1;
#end

I think I will then try to develop it a little bit further according to the
'distance test formula' from the 'Pebbles' example. My idea now is to test every
Grain[Nr] vs Grain[Nr-1] Grain[Nr-2]......Grain[0] if their distance between two
centers is smaller than their sum of radii. It's 3 a.m. now here guys. I think I
might just sleep and work it out tomorrow. Thank you guys for helping me at
first but I think I have to say I am too stupid to understand them :'(.

Post a reply to this message

On 6/20/2017 8:08 PM, Ari wrote:
>   I try
> my best to understand them but I can't due to the lack of Maths background(I
> only know some integration/sequence and differentiation from classes:(  ).

You and me both. :)

-- 

Regards
     Stephen

Post a reply to this message

"Ari" <win### [at] yahoocomhk> wrote:
> Hi, everyone.
> I have been spending time searching on the internet and reading your guys'
> information. However, I realized almost all of them required "some mathematical
> background", especially Voronoi Diagram being shown the most frequently. I try
> my best to understand them but I can't due to the lack of Maths background(I
> only know some integration/sequence and differentiation from classes :( ). I
> then try to work with an external program but I don't how to make use of it
> well. (I installed the pyvoro in Python) So, I just went back to the basic now.
> ( Damn, I am stupid! Just want to cry in a corner)

I think you'll be fine.
A lot of stuff was thrown at you all at once.
Voronoi / Delaunay is NOT an easy thing to do from scratch - which is why Sam
Benge used an external program to generate his data set.
Pov-ray's crackle pattern is essentially a Voronoi diagram, and you can use it
to make a pattern, or pass it to an isosurface as a function, to get "real 3d"
shapes.
I'd start with the spheres like you're doing, and then you can get a working
scene, and practice with POV-Ray's SDL syntax, and programming logic.


No worries - it'll be ok   ;)

Post a reply to this message

On 6/20/2017 8:57 PM, Stephen wrote:
> On 6/20/2017 8:08 PM, Ari wrote:
>>   I try
>> my best to understand them but I can't due to the lack of Maths
>> background(I
>> only know some integration/sequence and differentiation from
>> classes:(  ).
>
> You and me both. :)
>

So what I would do, knowing that most of the guys here have been using 
PovRay for years and they are wizards at maths and programming. Is to 
start simple then refine it as you go along.
The image you linked to was by someone who stuns everyone with his work. 
So it is not a fair goal to try and do in a couple of months.

If you look at the trace function it will tell you how far away an 
object is from a reference point. If you move that reference point in a 
regular scan. You can build up a pattern of spheres. When you are happy 
with that you can then add some randomness to what you are building. 
Irregular scaling of the spheres to be laid down to give the impression 
of stones. offset the trace reference point so the spheres don't stack 
up in columns etc.
Then you will get ideas of your own to enhance it.

Remember us enjuneers have to make thinks work. And if it doesn't fit 
use a bigger hammer. ;-)

-- 

Regards
     Stephen

Post a reply to this message

On 6/20/2017 9:54 PM, Bald Eagle wrote:
> "Ari" <win### [at] yahoocomhk> wrote:
>> Hi, everyone.
>> I have been spending time searching on the internet and reading your guys'
>> information. However, I realized almost all of them required "some mathematical
>> background", especially Voronoi Diagram being shown the most frequently. I try
>> my best to understand them but I can't due to the lack of Maths background(I
>> only know some integration/sequence and differentiation from classes :( ). I
>> then try to work with an external program but I don't how to make use of it
>> well. (I installed the pyvoro in Python) So, I just went back to the basic now.
>> ( Damn, I am stupid! Just want to cry in a corner)
>
> I think you'll be fine.
> A lot of stuff was thrown at you all at once.
> Voronoi / Delaunay is NOT an easy thing to do from scratch - which is why Sam
> Benge used an external program to generate his data set.
> Pov-ray's crackle pattern is essentially a Voronoi diagram, and you can use it
> to make a pattern, or pass it to an isosurface as a function, to get "real 3d"
> shapes.
> I'd start with the spheres like you're doing, and then you can get a working
> scene, and practice with POV-Ray's SDL syntax, and programming logic.
>
>

You know the differences in our outlooks on this problem are quite 
philosophical. But this is not the time to go into it. There is no good 
reason to. It would only be confusing.

> No worries - it'll be ok   ;)
>

Yes it will be. :)



-- 

Regards
     Stephen

Post a reply to this message

On 20-6-2017 23:04, Stephen wrote:
> On 6/20/2017 8:57 PM, Stephen wrote:
>> On 6/20/2017 8:08 PM, Ari wrote:
>>>   I try
>>> my best to understand them but I can't due to the lack of Maths
>>> background(I
>>> only know some integration/sequence and differentiation from
>>> classes:(  ).
>>
>> You and me both. :)
>>
> 
> So what I would do, knowing that most of the guys here have been using 
> PovRay for years and they are wizards at maths and programming. Is to 
> start simple then refine it as you go along.
> The image you linked to was by someone who stuns everyone with his work. 
> So it is not a fair goal to try and do in a couple of months.
> 
> If you look at the trace function it will tell you how far away an 
> object is from a reference point. If you move that reference point in a 
> regular scan. You can build up a pattern of spheres. When you are happy 
> with that you can then add some randomness to what you are building. 
> Irregular scaling of the spheres to be laid down to give the impression 
> of stones. offset the trace reference point so the spheres don't stack 
> up in columns etc.
> Then you will get ideas of your own to enhance it.

That is a good way to start. I shall have to try that scenario myself 
too I guess: been years since I wanted to explore that path. :-)

> 
> Remember us enjuneers have to make thinks work. And if it doesn't fit 
> use a bigger hammer. ;-)
> 

Not only enjuneers. Small apes like me too (using stones)... ;-)

-- 
Thomas

Post a reply to this message

On 6/21/2017 7:45 AM, Thomas de Groot wrote:
> On 20-6-2017 23:04, Stephen wrote:

>> So what I would do, knowing that most of the guys here have been using
>> PovRay for years and they are wizards at maths and programming. Is to
>> start simple then refine it as you go along.
>> The image you linked to was by someone who stuns everyone with his
>> work. So it is not a fair goal to try and do in a couple of months.
>>
>> If you look at the trace function it will tell you how far away an
>> object is from a reference point. If you move that reference point in
>> a regular scan. You can build up a pattern of spheres. When you are
>> happy with that you can then add some randomness to what you are
>> building. Irregular scaling of the spheres to be laid down to give the
>> impression of stones. offset the trace reference point so the spheres
>> don't stack up in columns etc.
>> Then you will get ideas of your own to enhance it.
>
> That is a good way to start. I shall have to try that scenario myself
> too I guess: been years since I wanted to explore that path. :-)
>

If I can find the time I will try it in Blender. But the learning. :)
>>
>> Remember us enjuneers have to make thinks work. And if it doesn't fit
>> use a bigger hammer. ;-)
>>
>
> Not only enjuneers. Small apes like me too (using stones)... ;-)
>

[Top tip] Tie a stick to your stone. :)
-- 

Regards
     Stephen

Post a reply to this message

On 21-6-2017 11:40, Stephen wrote:
> On 6/21/2017 7:45 AM, Thomas de Groot wrote:
>> On 20-6-2017 23:04, Stephen wrote:
> 
>>> So what I would do, knowing that most of the guys here have been using
>>> PovRay for years and they are wizards at maths and programming. Is to
>>> start simple then refine it as you go along.
>>> The image you linked to was by someone who stuns everyone with his
>>> work. So it is not a fair goal to try and do in a couple of months.
>>>
>>> If you look at the trace function it will tell you how far away an
>>> object is from a reference point. If you move that reference point in
>>> a regular scan. You can build up a pattern of spheres. When you are
>>> happy with that you can then add some randomness to what you are
>>> building. Irregular scaling of the spheres to be laid down to give the
>>> impression of stones. offset the trace reference point so the spheres
>>> don't stack up in columns etc.
>>> Then you will get ideas of your own to enhance it.
>>
>> That is a good way to start. I shall have to try that scenario myself
>> too I guess: been years since I wanted to explore that path. :-)
>>
> 
> If I can find the time I will try it in Blender. But the learning. :)
>>>
>>> Remember us enjuneers have to make thinks work. And if it doesn't fit
>>> use a bigger hammer. ;-)
>>>
>>
>> Not only enjuneers. Small apes like me too (using stones)... ;-)
>>
> 
> [Top tip] Tie a stick to your stone. :)

Tried that. Stick broke. :={

-- 
Thomas

Post a reply to this message

Without really knowing exactly what I was doing, and just plugging some stuff
into the editor and changing some values, I got this in 5 min:
(many thanks to Mike Williams   http://www.econym.demon.co.uk/isotut/
and David Wagner   http://wiki.waggy.org/dokuwiki/povray/stainedglass)

#version 3.71;

global_settings {
  assumed_gamma 1.0
}

#include "colors.inc"

camera {
 location  <0.0, 0, -5.0>
 right    x*image_width/image_height
 look_at   <0, 0, 0>}

light_source {<10, 10, -30> White}

#declare Packing = 1.3; //(increase to make more tightly packed)

#declare F =
function {
 pigment {
  crackle
  form < -1, Packing, 0>
  metric 3
  offset 0
  turbulence 0.1
  color_map { [0 rgb 1] [0.99 rgb 0] [1 rgb 0] }
  scale 0.25
 }
}

isosurface {
        function { F(x,y,z).red - 0.5 }
        max_gradient 5.5
        contained_by{box{-1,1}}
        pigment {rgb 0.9}
}

Just needs some tweaking, colors and textures.
NO idea how to get the parts sliced smooth by the container removed, but I
supposed doing a difference or intersection with a highly textured box or
something might be a good way to fake it.

Sorry officer, there was no posted speed limit.

Post a reply to this message

On 6/21/2017 12:58 PM, Bald Eagle wrote:
> Just needs some tweaking, colors and textures.

Not nitpicking, it is looking good. Is it possible to texture individual 
components?

> NO idea how to get the parts sliced smooth by the container removed, but I
> supposed doing a difference or intersection with a highly textured box or
> something might be a good way to fake it.
>
> Sorry officer, there was no posted speed limit.

Sorry BE that excuse would not hold in the UK. Each type of road here 
has its own maximum speed limit.


Built-up areas mph (km/h)	30 (48)
Single carriageways mph (km/h)	60 (96)
Dual carriageways mph (km/h)	70 (112)
Motorways mph(km/h) 		70 (112
		
That is for Cars, motorcycles, car-derived vans and dual-purpose 
vehicles. Other types of vehicles have different (lower) limits.

https://www.gov.uk/speed-limits


Of course stretches of road can have lower limits.

-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> Not nitpicking, it is looking good. Is it possible to texture individual
> components?
>
> > NO idea how to get the parts sliced smooth by the container removed, but I
> > supposed doing a difference or intersection with a highly textured box or
> > something might be a good way to fake it.

I think it _might_ be possible to do individual coloration, given that crackle
is based upon unit cells --- and I would imagine that if I give it some
additional thought, then the crackle function could be used to evaluate an rgb
color in the same way it's used to generate the F=0 for the isosurface...

I'm sure that Christoph L. or Mike H. might be able to chime in here, since they
seem to have a lot of practice in coloring isosurfaces with rgb functions.

I think the real point was that - there's _no math[s]_ in that there SDL.

> Sorry BE that excuse would not hold in the UK. Each type of road here
> has its own maximum speed limit.

That is The Road to Serfdom.
This is the Information Superhighway.  ;)

Post a reply to this message

On 6/21/2017 5:17 PM, Bald Eagle wrote:
> I think the real point was that - there's _no math[s]_ in that there SDL.
>

True but it is not layers of rocks and there are a lot of open spaces.
I don't think that it really fits the question. Although the true 
problem is not properly defined.

>> >Sorry BE that excuse would not hold in the UK. Each type of road here
>> >has its own maximum speed limit.
> That is The Road to Serfdom.

No. The road *from* serfdom. We sent our serfs to the colonies. :P

> This is the Information Superhighway.;)
>

At least our cops don't shoot you for traffic violations. ;)


-- 

Regards
     Stephen

Post a reply to this message

Stephen <mca### [at] aolcom> wrote:

> True but it is not layers of rocks and there are a lot of open spaces.

OK, NOW you're nitpicking.   ;)

> I don't think that it really fits the question. Although the true
> problem is not properly defined.

Well, I was thinking just that.
Here's a rock-wall building app that spits out a rock wall with the click of a
button...
(no, wait, that's so 2000's)
with the tap of a screen...
(no, wait, that's so 2010's)
with as request to Alexa...
(although 'they' probably have your whole psycho-social profile stored in the
cloud and know what your professor wants already ...

.... and so what have you really learned / accomplished.

In any event, the parameters of the project need to be communicated more clearly
and accurately.
Otherwise some wise-guy will post how to do it in 12 characters with a program
written in 'Jelly'.
Or Haskell :D

> No. The road *from* serfdom. We sent our serfs to the colonies. :P

Yep, and we partied like it was 1775.  :)

> At least our cops don't shoot you for traffic violations. ;)

Seriously.
(though I could really read into that on so many levels)

Post a reply to this message

On 6/21/2017 8:07 PM, Bald Eagle wrote:
> Stephen <mca### [at] aolcom> wrote:
>
>> True but it is not layers of rocks and there are a lot of open spaces.
>
> OK, NOW you're nitpicking.   ;)
>
>> I don't think that it really fits the question. Although the true
>> problem is not properly defined.
>
> Well, I was thinking just that.
> Here's a rock-wall building app that spits out a rock wall with the click of a
> button...
> (no, wait, that's so 2000's)
> with the tap of a screen...
> (no, wait, that's so 2010's)
> with as request to Alexa...
> (although 'they' probably have your whole psycho-social profile stored in the
> cloud and know what your professor wants already ...
>
> ..... and so what have you really learned / accomplished.
>

Exactly! But here we would only give hints or techniques or maybe 
pointers where some code was wrong.
ATM I've spent half a day trying to replicate it in Blender. I have 
learned that its particle system won't do it. It will need to be a 
ridged body system. But first I have to learn how to break a big stone 
into little stones.

In this heat it is like:
https://www.youtube.com/watch?v=f5lYNgCVwFo


 > In any event, the parameters of the project need to be communicated 
more clearly
> and accurately.
> Otherwise some wise-guy will post how to do it in 12 characters with a program
> written in 'Jelly'.
> Or Haskell :D
>
>> No. The road *from* serfdom. We sent our serfs to the colonies. :P
>
> Yep, and we partied like it was 1775.  :)
>

I'll give you that one even though it took you long enough to start it. ;)

To make sure I was thinking about the right date. I googled 1775 and the 
whole front page was about a computer game. Sad the state the world has 
come to.

>> At least our cops don't shoot you for traffic violations. ;)
>
> Seriously.
> (though I could really read into that on so many levels)
>

Indeed you could. But if you are the right complexion it seems you can 
get away with murder.


-- 

Regards
     Stephen

Post a reply to this message

On 21-6-2017 13:58, Bald Eagle wrote:
> 
> Without really knowing exactly what I was doing, and just plugging some stuff
> into the editor and changing some values, I got this in 5 min:
> (many thanks to Mike Williams   http://www.econym.demon.co.uk/isotut/
> and David Wagner   http://wiki.waggy.org/dokuwiki/povray/stainedglass)
> 
> #version 3.71;
> 
> global_settings {
>    assumed_gamma 1.0
> }
> 
> #include "colors.inc"
> 
> camera {
>   location  <0.0, 0, -5.0>
>   right    x*image_width/image_height
>   look_at   <0, 0, 0>}
> 
> light_source {<10, 10, -30> White}
> 
> #declare Packing = 1.3; //(increase to make more tightly packed)
> 
> #declare F =
> function {
>   pigment {
>    crackle
>    form < -1, Packing, 0>
>    metric 3
>    offset 0
>    turbulence 0.1
>    color_map { [0 rgb 1] [0.99 rgb 0] [1 rgb 0] }
>    scale 0.25
>   }
> }
> 
> isosurface {
>          function { F(x,y,z).red - 0.5 }
>          max_gradient 5.5
>          contained_by{box{-1,1}}
>          pigment {rgb 0.9}
> }
> 
> Just needs some tweaking, colors and textures.
> NO idea how to get the parts sliced smooth by the container removed, but I
> supposed doing a difference or intersection with a highly textured box or
> something might be a good way to fake it.
> 

This is a nice try but... it is not a /stacking/ of stones. It is a 
crackled volume. If you drop stones, they will behave differently from 
what you see here.

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

> This is a nice try but... it is not a /stacking/ of stones. It is a
> crackled volume. If you drop stones, they will behave differently from
> what you see here.

Indeed - it wasn't really even supposed to be a "try" - it was just a blatant
cut&paste with a minor tweak or two to get it to run and close up the gaps a bit
- to show that with a wee bit of POV-Ray magic, a 3-dimensional Voronoi diagram
that gives the appearance of a pile of "stones" is THAT quick and easy - no
math, no (user-written) algorithms, no staying up late, pulling out one's
(remaining) hair, no crying in the corner because you're stoopid.

And to pick nits, if you drop stones, they will of course [sic] behave
differently than if you stack them.

AND the end result is going to be a product of however the user codes the scene
anyway, will will be a further layer of deviation from reality.

I'd say we're at a juncture where the parameters of the project need to be
defined.  But there still all sorts of fun variations on the theme that we can
play with - unconstrained by the prof.   :)
(which is what the _really_ good students ought to be doing along the way / in
addition to the stated project)

"So, I made that rock pile that you wanted - but I also did a few old Scottish
castles, the Great Wall of China, a cross-section of an archaeological
excavation site with some fossil meshes thrown in, an animated exploding Rice
Krispy treat, the rubble in the aftermath of a Kalifornia earthquake, and I've
begun a study on the kinetics of settling in a mixture of sand, aggregate, and
cement in pre-mixed concrete....... by the way is there any more coffee?"
;)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Without really knowing exactly what I was doing, and just plugging some stuff
> into the editor and changing some values, I got this in 5 min:
> [code example]

Cool. I've been playing with it and animating some of the values, to see what
happens. Fun!

Post a reply to this message

Le 17-06-21 à 07:58, Bald Eagle a écrit :
> 
> Without really knowing exactly what I was doing, and just plugging some stuff
> into the editor and changing some values, I got this in 5 min:
> (many thanks to Mike Williams   http://www.econym.demon.co.uk/isotut/
> and David Wagner   http://wiki.waggy.org/dokuwiki/povray/stainedglass)
> 
> #version 3.71;
> 
> global_settings {
>    assumed_gamma 1.0
> }
> 
> #include "colors.inc"
> 
> camera {
>   location  <0.0, 0, -5.0>
>   right    x*image_width/image_height
>   look_at   <0, 0, 0>}
> 
> light_source {<10, 10, -30> White}
> 
> #declare Packing = 1.3; //(increase to make more tightly packed)
> 
> #declare F =
> function {
>   pigment {
>    crackle
>    form < -1, Packing, 0>
>    metric 3
>    offset 0
>    turbulence 0.1
>    color_map { [0 rgb 1] [0.99 rgb 0] [1 rgb 0] }
>    scale 0.25
>   }
> }
> 
> isosurface {
>          function { F(x,y,z).red - 0.5 }
>          max_gradient 5.5
>          contained_by{box{-1,1}}
>          pigment {rgb 0.9}
> }
> 
> Just needs some tweaking, colors and textures.
> NO idea how to get the parts sliced smooth by the container removed, but I
> supposed doing a difference or intersection with a highly textured box or
> something might be a good way to fake it.
> 
> Sorry officer, there was no posted speed limit.
> 
> 
> 

You can use multiple patterns. In this case, a boxed pattern may be 
usefull with a colour_map that stays to 1 untill close to the edges, 
then drops to zero over a relatively short distance. Something like this:

#declare F_Boxed = function{colour_map{[0 rgb 0][0.1 rgb 1]}}

Next, you multiply the two.
isosurface {
         function { F(x,y,z).red - 0.5 } * function{F_Boxed(x,y,z).red}
         max_gradient 5.5
         contained_by{box{-1,1}}
         pigment {rgb 0.9}
}

Post a reply to this message

On 22-6-2017 13:50, Bald Eagle wrote:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> This is a nice try but... it is not a /stacking/ of stones. It is a
>> crackled volume. If you drop stones, they will behave differently from
>> what you see here.
> 
> Indeed - it wasn't really even supposed to be a "try" - it was just a blatant
> cut&paste with a minor tweak or two to get it to run and close up the gaps a bit
> - to show that with a wee bit of POV-Ray magic, a 3-dimensional Voronoi diagram
> that gives the appearance of a pile of "stones" is THAT quick and easy - no
> math, no (user-written) algorithms, no staying up late, pulling out one's
> (remaining) hair, no crying in the corner because you're stoopid.
> 
> And to pick nits, if you drop stones, they will of course [sic] behave
> differently than if you stack them.
> 
> AND the end result is going to be a product of however the user codes the scene
> anyway, will will be a further layer of deviation from reality.
> 
> I'd say we're at a juncture where the parameters of the project need to be
> defined.  But there still all sorts of fun variations on the theme that we can
> play with - unconstrained by the prof.   :)
> (which is what the _really_ good students ought to be doing along the way / in
> addition to the stated project)
> 
> "So, I made that rock pile that you wanted - but I also did a few old Scottish
> castles, the Great Wall of China, a cross-section of an archaeological
> excavation site with some fossil meshes thrown in, an animated exploding Rice
> Krispy treat, the rubble in the aftermath of a Kalifornia earthquake, and I've
> begun a study on the kinetics of settling in a mixture of sand, aggregate, and
> cement in pre-mixed concrete....... by the way is there any more coffee?"
> ;)
> 
> 

I can only agree with you :-)

To tell the truth, I was not criticising your crackle which is fine by 
itself and useful in other contexts (a mortared wall?) I wanted to draw 
attention (mine included) to the very different geometry presented by 
stacking stones. Obvious, and yet something to ponder deeply for 
modelling purposes. :-)

-- 
Thomas

Post a reply to this message

On 6/23/2017 7:37 AM, Thomas de Groot wrote:
> To tell the truth, I was not criticising your crackle which is fine by
> itself and useful in other contexts (a mortared wall?) I wanted to draw
> attention (mine included) to the very different geometry presented by
> stacking stones. Obvious, and yet something to ponder deeply for
> modelling purposes. :-)

I've spent two days making rocks and trying to lay them in a single 
layer. I'm really struggling with it.

-- 

Regards
     Stephen

Post a reply to this message

On 23-6-2017 12:09, Stephen wrote:
> On 6/23/2017 7:37 AM, Thomas de Groot wrote:
>> To tell the truth, I was not criticising your crackle which is fine by
>> itself and useful in other contexts (a mortared wall?) I wanted to draw
>> attention (mine included) to the very different geometry presented by
>> stacking stones. Obvious, and yet something to ponder deeply for
>> modelling purposes. :-)
> 
> I've spent two days making rocks and trying to lay them in a single 
> layer. I'm really struggling with it.
> 

Yes it is a very difficult task, especially considering how easily 
Mother Nature does it herself. ;-)

Steering clear from specialised modelling packages which can do this, 
and trying to restrict myself to only POV-Ray, trace() is an obvious 
tool but it needs to be completed with some kind of gravity (vertical; 
trace -y) and/or stream energy (horizontal; trace +/-x or +/-z) control 
to settle individual grains before, during, and after impacts over a 
number of incrementing iterations. Not easy!

-- 
Thomas

Post a reply to this message

On 23-6-2017 13:21, Thomas de Groot wrote:
> Steering clear from specialised modelling packages which can do this, 
> and trying to restrict myself to only POV-Ray, trace() is an obvious 
> tool but it needs to be completed with some kind of gravity (vertical; 
> trace -y) and/or stream energy (horizontal; trace +/-x or +/-z) control 
> to settle individual grains before, during, and after impacts over a 
> number of incrementing iterations. Not easy!
> 

Something like this would be nice :-o

https://www.deltares.nl/academy/delft3d-4-modelling-sediment-transport-and-bed-dynamics/

-- 
Thomas

Post a reply to this message

I will just say that there apparently has been much work done on exactly this.

Makes for some very interesting reading.

Post a reply to this message

On 23-6-2017 21:19, Bald Eagle wrote:
> 
> I will just say that there apparently has been much work done on exactly this.
> 
> Makes for some very interesting reading.
> 
> 

Coastal engineering in the Netherlands has a worldwide reputation. 
However, I do not think that they model/stack the sand grains 
individually like we would like to do, and in fact that is far less 
interesting for their purpose. What they model are the different scale 
sediment transport mechanisms under variable space/time/sediment 
availability/composition conditions.

-- 
Thomas

Post a reply to this message