![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <39738497.A75CD4CC@peak.edu.ee>, Margus Ramst
<mar### [at] peak edu ee> wrote:
> Thanks.
> One more thing: the probem also seems to occur on the first (non-ipf)
> run after the ipf run. Consecutive runs (unmodified) are OK.
So you run the simulation with inter-particle forces, then run it
without, and *then* it aborts parsing? Sounds like some variable isn't
being initialized...
> Out of curiosity, if you feel like explaining, how is the
> inter-particle collision implemented?
It isn't...the particles are points, with no size. "IPF" stands for
Inter-Particle Forces. Basically, each particle is pushed toward or away
from it's neighboring particles within the ipf distance, with a force
that depends on the distance. Positive values attract, negative values
repel(or is it the other way around...?). The default function produces
a symmetrical curve going from +1 to -1, with a relatively flat area in
the middle, which pulls toward more distant particles and pushes away
from nearer particles. The spline ("custom" profile) option allows you
to specify the curve with a spline {} instead of using the built-in
function. Particles outside the ipf distance are ignored.
I am thinking of adding a type of "solid" particles which *would* have
collision, but I need to learn more about simulating rigid object
collisions first. This is something I can't seem to figure out on my
own...the only ways I can think of would be very computationally
expensive.
> It takes lot of time, which is understandable, but it strikes me as
> slow even with a very small ipf_distance (if I understand its purpose
> correctly). Are you already using some sorting algorithm, like
> kd-tree or oct-tree, to optimize things?
I haven't implemented any kind of sorting yet, though I plan to.
Currently, every particle has to be checked for distance, so every
particle has to be compared against every particle in existence for
distance, once for every iteration. This is why it is so slow.
I will probably use some kind of tree of nested, overlapping
boxes(octree?), though it is still in the planning stages. One of the
problems is that it will have to cope with particles moving from one
area of space to the next.
Oh, and what is a kd-tree? I have heard of it, and I know it is some
sort of data structure, but that is the limit of my knowledge.
Any suggestions for optimization techniques for this would be welcome.
Also, something similar may be used to bound the generated blob shape
more efficiently, and could also be used to optimize the blob pattern...
--
Christopher James Huff - Personal e-mail: chr### [at] mac com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Chris Huff wrote:
>
> So you run the simulation with inter-particle forces, then run it
> without, and *then* it aborts parsing? Sounds like some variable isn't
> being initialized...
Strange, it sometimes happens without running ipf previously (although that
seems to be a sure-fire way). Haven't found the connection yet.
>
> It isn't...the particles are points, with no size. "IPF" stands for
> Inter-Particle Forces. Basically, each particle is pushed toward or away
> from it's neighboring particles within the ipf distance, with a force
> that depends on the distance.
I see. Actually, I think this is sufficient in most cases, especially with
liquids. As for the "solid" particles - I don't think inter-particle collision
and deflection would be at all expensive for spherical particles, and
prohibitively expensive for most other shapes. What physical properties would be
needed? Collision is easy, deflection and impact energy absorption too, friction
I'm not so sure about... What else?
BTW, I found an interesting page discussing sorting algorithms for particle
systems (specifically kd-trees and Barnes-Hut trees). I saw no actual code, but
pretty informative nevertheless. The URL is:
http://physics.gmu.edu/~large/lr_forces/lr_general.html
--
Margus Ramst
Personal e-mail: mar### [at] peak edu ee
TAG (Team Assistance Group) e-mail: mar### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Margus Ramst wrote:
> > It isn't...the particles are points, with no size. "IPF" stands for
> > Inter-Particle Forces. Basically, each particle is pushed toward or away
> > from it's neighboring particles within the ipf distance, with a force
> > that depends on the distance.
>
> I see. Actually, I think this is sufficient in most cases, especially with
> liquids. As for the "solid" particles - I don't think inter-particle collision
> and deflection would be at all expensive for spherical particles, and
> prohibitively expensive for most other shapes. What physical properties would be
> needed? Collision is easy, deflection and impact energy absorption too, friction
> I'm not so sure about... What else?
What about rotation effects - where as 2 spheres are moving through space they
rotate around an axis and when they collide their subsequent movements, velocities &
rotations depend on both the velocities and rotation axes of the two particles.
--
Bye
Pabs
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Pabs wrote:
>
>
> What about rotation effects - where as 2 spheres are moving through space they
> rotate around an axis and when they collide their subsequent movements, velocities &
> rotations depend on both the velocities and rotation axes of the two particles.
Yes, but is this really worth the computational expense? I suspect the spin of
individual particles has little perceptible effect on the overall behaviour a
large particle system.
--
Margus Ramst
Personal e-mail: mar### [at] peak edu ee
TAG (Team Assistance Group) e-mail: mar### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Some more potentially interesting resources.
The first has a PS paper and source code of a density-based particle sorting
mechanism (uses kd-trees):
http://www.sns.ias.edu/~eisenste/hop/hop.html
And a brief description of kd-trees:
http://web.mit.edu/napoli/www/6.838/kd.html
--
Margus Ramst
Personal e-mail: mar### [at] peak edu ee
TAG (Team Assistance Group) e-mail: mar### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Margus Ramst wrote:
> Yes, but is this really worth the computational expense? I suspect the spin of
> individual particles has little perceptible effect on the overall behaviour a
> large particle system.
I think when considering *Solid Particles* or balls/spheres we are getting out of the
_particle_ domain (aren't particles 1D not 3D) & into the physics of solid objects a
bit
more, which is a lot more complex than that of particles.
--
Bye
Pabs
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Pabs wrote:
>
> I think when considering *Solid Particles* or balls/spheres we are getting out of
the
> _particle_ domain (aren't particles 1D not 3D) & into the physics of solid objects a
bit
> more, which is a lot more complex than that of particles.
They are still particles in the sense of being elements in a very large set,
where the contribution of the individual is relatively small. It's a case of
diminishing returns. I think the physics model of individual particles needn't
be, and cannot be, as accurate as, say, when simulating the collision of just
two big spheres.
--
Margus Ramst
Personal e-mail: mar### [at] peak edu ee
TAG (Team Assistance Group) e-mail: mar### [at] tag povray org
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3973D2BD.A92017E7@peak.edu.ee>, Margus Ramst
<mar### [at] peak edu ee> wrote:
> Yes, but is this really worth the computational expense? I suspect
> the spin of individual particles has little perceptible effect on the
> overall behaviour a large particle system.
It may, especially when you have a large number of particles with the
same spin bouncing off of an object. And what if the particles are
*supposed* to represent a large number of large objects?
As for the computational expense...it should, of course, be able to be
turned off. Maybe a simple "angular_forces on/off" flag.
--
Christopher James Huff - Personal e-mail: chr### [at] mac com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <397### [at] hotmail com>, Pabs <pab### [at] hotmail com>
wrote:
> I think when considering *Solid Particles* or balls/spheres we are
> getting out of the _particle_ domain (aren't particles 1D not 3D) &
> into the physics of solid objects a bit more, which is a lot more
> complex than that of particles.
A 1D particle would be a point on a line, with no mass, no velocity,
etc. Not very useful.
And there is no reason to restrict particles to points...it is just that
inter-particle collisions aren't necessary or wanted in liquid
simulations.
--
Christopher James Huff - Personal e-mail: chr### [at] mac com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <397### [at] peak edu ee>, Margus Ramst
<mar### [at] peak edu ee> wrote:
> Strange, it sometimes happens without running ipf previously
> (although that seems to be a sure-fire way). Haven't found the
> connection yet.
It still sounds like an uninitialized variable or a dangling pointer.
> I see. Actually, I think this is sufficient in most cases, especially
> with liquids.
Inter-particle collisions would probably just interfere with liquid-like
behavior.
> As for the "solid" particles - I don't think inter-particle collision
> and deflection would be at all expensive for spherical particles, and
> prohibitively expensive for most other shapes.
Actually, the only way I can think of doing it would also work for
arbitrary shaped objects(like meshes), but would be computationally
expensive for all of them. I suppose the cheapest one would be a
triangle, followed by triangle pairs, other simple, non-solid shapes,
and boxes. Spheres would definitely not be the cheapest.
I definitely need to learn more about rigid body dynamics before I try
this.
> What physical properties would be needed? Collision is easy,
> deflection and impact energy absorption too, friction I'm not so sure
> about... What else?
Impact energy absorption already exists, as elasticity. Friction
coefficient, shatter speed, geometry, etc. Internally, center of
gravity, angular velocity, a bounding box...
> BTW, I found an interesting page discussing sorting algorithms for
> particle systems (specifically kd-trees and Barnes-Hut trees). I saw
> no actual code, but pretty informative nevertheless. The URL is:
> http://physics.gmu.edu/~large/lr_forces/lr_general.html
Thanks, I will take a look...
--
Christopher James Huff - Personal e-mail: chr### [at] mac com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |