Ooo. Cool- are you still sticking with red paint instead of blood?
Considering that Halloween's coming up, blood might not be a bad idea :-)

--

//Mahalis
camera{location<0,0.25,-2> look_at 0.5*y} #declare T=texture{pigment{crackle
scale 0.5 rotate 90 turbulence 0.75 color_map{[0 rgb 1][0.05 rgb 1][0.1
rgb<1,0.25,1>][0.25 rgbf 1][1 rgbf 1]}} finish{ambient 1}} #declare
c=difference{torus{0.5,0.1 rotate -90*x}box{<0.7,0,0.2>,<-0.7,-0.7,-0.2>}}
merge{object{c translate<0.5,0.5,0>} object{c translate<-0.5,0.5,0>}
cylinder{<1,0.5,0>,<1,0,0>,0.1} cylinder{<-1,0.5,0>,<-1,0,0>,0.1}
cylinder{0.5*y,0,0.1} texture{T}}
--


"JRG" <jrg### [at] hotmailcom> wrote in message
news:3bcc6b2a@news.povray.org...
> See same thread in p.b-i.
> I know I can get better compression with divx, but the quality was
*really*
> poor. Is there anyone who can drive me through all those encoding options?
> TIA.
>
> --
> Jonathan.
>
>
>
>

Post a reply to this message

After staring at this animation for literally seconds, I finally realized
what was missing: surface tension. there must be some way for a partile to
know if it is connected to another one and if so, is attracted to it. This
would prevent the tiny droplets from escaping like they do now.

"JRG" <jrg### [at] hotmailcom> wrote in message
news:3bcc6b2a@news.povray.org...
> See same thread in p.b-i.
> I know I can get better compression with divx, but the quality was
*really*
> poor. Is there anyone who can drive me through all those encoding options?
> TIA.
>
> --
> Jonathan.
>
>
>
>

Post a reply to this message

Do you know a *fast* way to do that in POV SDL? As I said elsewhere, it
would be really a simple implementation, but it would be *extremely* slow to
compute with so many particles. I could consider to implement non persistent
(sp?) particles to reduce the number of particles per frame though... any
help?

--
Jonathan.
"Chris Jeppesen" <chr### [at] digiquillcom> ha scritto nel messaggio
news:3bcdb821$1@news.povray.org...
> After staring at this animation for literally seconds, I finally realized
> what was missing: surface tension. there must be some way for a partile to
> know if it is connected to another one and if so, is attracted to it. This
> would prevent the tiny droplets from escaping like they do now.
>
> "JRG" <jrg### [at] hotmailcom> wrote in message
> news:3bcc6b2a@news.povray.org...
> > See same thread in p.b-i.
> > I know I can get better compression with divx, but the quality was
> *really*
> > poor. Is there anyone who can drive me through all those encoding
options?
> > TIA.
> >
> > --
> > Jonathan.
> >
> >
> >
> >
>
>

Post a reply to this message

If you look carefully at the few droplets that flow towards the camera,
you'll see that a few droplets actually divides in two.

Once they blob together, you should try to get them to stay together.  Well,
except if they are falling off of something.

Otherwise, looks cool.  :)

Post a reply to this message

Hmm, I'm not familiar with Halloween.
And yes, this is still paint. (the title is just meant to be an interesting
one ;)

--
Jonathan.
"Mahalis" <don### [at] fakeycom> ha scritto nel messaggio
news:3bccbbe9$1@news.povray.org...
> Ooo. Cool- are you still sticking with red paint instead of blood?
> Considering that Halloween's coming up, blood might not be a bad idea :-)
>
> --
>
> //Mahalis
> camera{location<0,0.25,-2> look_at 0.5*y} #declare
T=texture{pigment{crackle
> scale 0.5 rotate 90 turbulence 0.75 color_map{[0 rgb 1][0.05 rgb 1][0.1
> rgb<1,0.25,1>][0.25 rgbf 1][1 rgbf 1]}} finish{ambient 1}} #declare
> c=difference{torus{0.5,0.1 rotate -90*x}box{<0.7,0,0.2>,<-0.7,-0.7,-0.2>}}
> merge{object{c translate<0.5,0.5,0>} object{c translate<-0.5,0.5,0>}
> cylinder{<1,0.5,0>,<1,0,0>,0.1} cylinder{<-1,0.5,0>,<-1,0,0>,0.1}
> cylinder{0.5*y,0,0.1} texture{T}}
> --
>
>
> "JRG" <jrg### [at] hotmailcom> wrote in message
> news:3bcc6b2a@news.povray.org...
> > See same thread in p.b-i.
> > I know I can get better compression with divx, but the quality was
> *really*
> > poor. Is there anyone who can drive me through all those encoding
options?
> > TIA.
> >
> > --
> > Jonathan.
> >
> >
> >
> >
>
>

Post a reply to this message

Well, the basic alogrithm is to find the closest neighboring particle, and
if it is within a certain distance, generate a force towards this nearest
neighbor. The slow O(N^2) part is finding the nearest particle.

What if you chopped up the space into cubes, and only looked for a nearest
neighbor in the same cube? I assume that somewhere deep down in your
simulation is a 1-dimensional array representing the particles.

Suppose you divided the space into 10x10x10 cubes, and had a 4-dimensional
array Neighbors[10][10][10][N_PARTICLES]. When the physics loop starts, the
array is cleared. When each particle position is updated, calculate which
cube it belongs in, say <4,5,6> and write that into Neighbors[4][5][6]. Now
when it comes time to calculate, for each particle only check for its
nearest neighbor in the same neighbor cube. This could reduce time to
O(1000*(N/1000)^2).


"JRG" <jrg### [at] hotmailcom> wrote in message
news:3bcdbc8c@news.povray.org...
> Do you know a *fast* way to do that in POV SDL? As I said elsewhere, it
> would be really a simple implementation, but it would be *extremely* slow
to
> compute with so many particles. I could consider to implement non
persistent
> (sp?) particles to reduce the number of particles per frame though... any
> help?
>
> --
> Jonathan.
> "Chris Jeppesen" <chr### [at] digiquillcom> ha scritto nel messaggio
> news:3bcdb821$1@news.povray.org...
> > After staring at this animation for literally seconds, I finally
realized
> > what was missing: surface tension. there must be some way for a partile
to
> > know if it is connected to another one and if so, is attracted to it.
This
> > would prevent the tiny droplets from escaping like they do now.
> >
> > "JRG" <jrg### [at] hotmailcom> wrote in message
> > news:3bcc6b2a@news.povray.org...
> > > See same thread in p.b-i.
> > > I know I can get better compression with divx, but the quality was
> > *really*
> > > poor. Is there anyone who can drive me through all those encoding
> options?
> > > TIA.
> > >
> > > --
> > > Jonathan.
> > >
> > >
> > >
> > >
> >
> >
>
>

Post a reply to this message

Hmmm, it sounds clever. This algorithm might be use for reciprocal repulsion
as well.
I'll give it a try and post the results.
Thank you,

--
Jonathan.
"Chris Jeppesen" <chr### [at] digiquillcom> ha scritto nel messaggio
news:3bcdc15c$1@news.povray.org...
> Well, the basic alogrithm is to find the closest neighboring particle, and
> if it is within a certain distance, generate a force towards this nearest
> neighbor. The slow O(N^2) part is finding the nearest particle.
>
> What if you chopped up the space into cubes, and only looked for a nearest
> neighbor in the same cube? I assume that somewhere deep down in your
> simulation is a 1-dimensional array representing the particles.
>
> Suppose you divided the space into 10x10x10 cubes, and had a 4-dimensional
> array Neighbors[10][10][10][N_PARTICLES]. When the physics loop starts,
the
> array is cleared. When each particle position is updated, calculate which
> cube it belongs in, say <4,5,6> and write that into Neighbors[4][5][6].
Now
> when it comes time to calculate, for each particle only check for its
> nearest neighbor in the same neighbor cube. This could reduce time to
> O(1000*(N/1000)^2).
>
>
> "JRG" <jrg### [at] hotmailcom> wrote in message
> news:3bcdbc8c@news.povray.org...
> > Do you know a *fast* way to do that in POV SDL? As I said elsewhere, it
> > would be really a simple implementation, but it would be *extremely*
slow
> to
> > compute with so many particles. I could consider to implement non
> persistent
> > (sp?) particles to reduce the number of particles per frame though...
any
> > help?
> >
> > --
> > Jonathan.
> > "Chris Jeppesen" <chr### [at] digiquillcom> ha scritto nel messaggio
> > news:3bcdb821$1@news.povray.org...
> > > After staring at this animation for literally seconds, I finally
> realized
> > > what was missing: surface tension. there must be some way for a
partile
> to
> > > know if it is connected to another one and if so, is attracted to it.
> This
> > > would prevent the tiny droplets from escaping like they do now.
> > >
> > > "JRG" <jrg### [at] hotmailcom> wrote in message
> > > news:3bcc6b2a@news.povray.org...
> > > > See same thread in p.b-i.
> > > > I know I can get better compression with divx, but the quality was
> > > *really*
> > > > poor. Is there anyone who can drive me through all those encoding
> > options?
> > > > TIA.
> > > >
> > > > --
> > > > Jonathan.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Post a reply to this message

Actually you should check the 26 cubes immediately surrounding the cube in
question as well, otherwise particles at the very edge of one cube wouldn't
be influenced by particles at the very edge of the next cube

-tgq


"Chris Jeppesen" <chr### [at] digiquillcom> wrote in message
news:3bcdc15c$1@news.povray.org...
> Well, the basic alogrithm is to find the closest neighboring particle, and
> if it is within a certain distance, generate a force towards this nearest
> neighbor. The slow O(N^2) part is finding the nearest particle.
>
> What if you chopped up the space into cubes, and only looked for a nearest
> neighbor in the same cube? I assume that somewhere deep down in your
> simulation is a 1-dimensional array representing the particles.
>
> Suppose you divided the space into 10x10x10 cubes, and had a 4-dimensional
> array Neighbors[10][10][10][N_PARTICLES]. When the physics loop starts,
the
> array is cleared. When each particle position is updated, calculate which
> cube it belongs in, say <4,5,6> and write that into Neighbors[4][5][6].
Now
> when it comes time to calculate, for each particle only check for its
> nearest neighbor in the same neighbor cube. This could reduce time to
> O(1000*(N/1000)^2).
>

Post a reply to this message

26?

--
Jonathan.
"Trevor Quayle" <Tin### [at] hotmailcom> ha scritto nel messaggio
news:3bcdc957$1@news.povray.org...
> Actually you should check the 26 cubes immediately surrounding the cube in
> question as well, otherwise particles at the very edge of one cube
wouldn't
> be influenced by particles at the very edge of the next cube
>
> -tgq
>
>
> "Chris Jeppesen" <chr### [at] digiquillcom> wrote in message
> news:3bcdc15c$1@news.povray.org...
> > Well, the basic alogrithm is to find the closest neighboring particle,
and
> > if it is within a certain distance, generate a force towards this
nearest
> > neighbor. The slow O(N^2) part is finding the nearest particle.
> >
> > What if you chopped up the space into cubes, and only looked for a
nearest
> > neighbor in the same cube? I assume that somewhere deep down in your
> > simulation is a 1-dimensional array representing the particles.
> >
> > Suppose you divided the space into 10x10x10 cubes, and had a
4-dimensional
> > array Neighbors[10][10][10][N_PARTICLES]. When the physics loop starts,
> the
> > array is cleared. When each particle position is updated, calculate
which
> > cube it belongs in, say <4,5,6> and write that into Neighbors[4][5][6].
> Now
> > when it comes time to calculate, for each particle only check for its
> > nearest neighbor in the same neighbor cube. This could reduce time to
> > O(1000*(N/1000)^2).
> >
>
>
>

Post a reply to this message

3^3 -1 (cubes that share faces, edges and corners)

-tgq


"JRG" <jrg### [at] hotmailcom> wrote in message
news:3bcdcbde@news.povray.org...
> 26?
>
> --
> Jonathan.
> "Trevor Quayle" <Tin### [at] hotmailcom> ha scritto nel messaggio
> news:3bcdc957$1@news.povray.org...
> > Actually you should check the 26 cubes immediately surrounding the cube
in
> > question as well, otherwise particles at the very edge of one cube
> wouldn't
> > be influenced by particles at the very edge of the next cube
> >
> > -tgq
> >
> >
> > "Chris Jeppesen" <chr### [at] digiquillcom> wrote in message
> > news:3bcdc15c$1@news.povray.org...
> > > Well, the basic alogrithm is to find the closest neighboring particle,
> and
> > > if it is within a certain distance, generate a force towards this
> nearest
> > > neighbor. The slow O(N^2) part is finding the nearest particle.
> > >
> > > What if you chopped up the space into cubes, and only looked for a
> nearest
> > > neighbor in the same cube? I assume that somewhere deep down in your
> > > simulation is a 1-dimensional array representing the particles.
> > >
> > > Suppose you divided the space into 10x10x10 cubes, and had a
> 4-dimensional
> > > array Neighbors[10][10][10][N_PARTICLES]. When the physics loop
starts,
> > the
> > > array is cleared. When each particle position is updated, calculate
> which
> > > cube it belongs in, say <4,5,6> and write that into
Neighbors[4][5][6].
> > Now
> > > when it comes time to calculate, for each particle only check for its
> > > nearest neighbor in the same neighbor cube. This could reduce time to
> > > O(1000*(N/1000)^2).
> > >
> >
> >
> >
>
>

Post a reply to this message