In article <39738497.A75CD4CC@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> 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] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message