Chris Huff wrote:

> In article <3962B4A1.A300F52D@nospamthanks.hotmail.com>, Pabs
> <pab### [at] nospamthankshotmailcom> wrote:
>
> > How about an object emitter where particles are emitted in the
> > direction of the surface normal and a speed specified by a
> > pattern/function.  The emmission points on the surface could be
> > sampled by tracing rays from a point & or direction toward that
> > object- kind of like how photons are done.
>
> I have been wondering about this...I just haven't thought of a good way
> of implementing it. It should be quite possible by specifying a point to
> sample surface positions from, as you suggest...but that would only
> cover part of the object. I could shoot at the center of the object's
> bounding box from random points on the surface of a sphere around
> it...but that would only give an even emission distribution for
> spherical objects, and parts of the object could be "hidden" from the
> particles by other parts. Would anyone notice?

It probably wouldn't be noticed unless someone used a noise3d isosurface as
the emitter.
BUT...
You could get _all_ intersections with each sampling ray - so that if you
hit a surface you keep tracing the _same_ ray until no more surfaces are hit
and therefore no parts of the object could be "hidden" from the particles by
other parts of the object.

Also what about a pattern that is the average particle density (or particle
collision density with the object whose pattern is being determined) in the
vicinity of the intersection point.  The particle(collision) density would
be the # of particles/collision points per unit space in the vicinity of the
intersection point or the addition of blob fields around all the
particles/collision points.
This could be used to visualize the drag on an airplane or fluid density or
other stuff.

Bye
Pabs

Post a reply to this message

In article <396414C4.B17FD9F4@nospamthanks.hotmail.com>, Pabs 
<pab### [at] nospamthankshotmailcom> wrote:

> It probably wouldn't be noticed unless someone used a noise3d 
> isosurface as the emitter. BUT... You could get _all_ intersections 
> with each sampling ray - so that if you hit a surface you keep 
> tracing the _same_ ray until no more surfaces are hit and therefore 
> no parts of the object could be "hidden" from the particles by other 
> parts of the object.

Hmm, that could work, though I would have to save the points for later 
use, kind of like a large number of point emitters...how should I take 
the samples, though? If I take them from the surface of a sphere toward 
the center of the bounding box, there will be a serious tendency for the 
center of the object unless it is hollow and fairly spherical. Maybe if 
I took them from the three sides of a box...along each coordinate axis, 
in other words.


> Also what about a pattern that is the average particle density (or 
> particle collision density with the object whose pattern is being 
> determined) in the vicinity of the intersection point.  The 
> particle(collision) density would be the # of particles/collision 
> points per unit space in the vicinity of the intersection point or 
> the addition of blob fields around all the particles/collision 
> points. This could be used to visualize the drag on an airplane or 
> fluid density or other stuff.

This actually existed in the first versions of my patch, in fact, it was 
*the* first version of my patch, but I have removed it because it was 
too difficult to maintain while the rest of the patch was changing so 
rapidly...I do plan on replacing it, however.
Hmm, particle density...I hadn't thought of that. I will need to write a 
function to compute this for particle fission/fusion anyway, so might as 
well include it...
BTW, one other problem with the particle_system pattern was that it was 
slow, since all the particles had to be calculated. I plan on adding a 
bounding structure based on recursively subdividing boxes(I think it is 
called an octree...) or planes(I have no idea what this is called) to 
speed up inter-particle force calculations, so that should really speed 
up the patterns...

-- 
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

Chris Huff wrote:

> Hmm, that could work, though I would have to save the points for later
> use, kind of like a large number of point emitters...how should I take
> the samples, though? If I take them from the surface of a sphere toward
> the center of the bounding box, there will be a serious tendency for the
> center of the object unless it is hollow and fairly spherical. Maybe if
> I took them from the three sides of a box...along each coordinate axis,
> in other words.

Could work but maybe you could specify some different types of sampling -
like the box method, point & bbox method, sphere & bbox method, random
points in random directions et al.

> This actually existed in the first versions of my patch, in fact, it was
> *the* first version of my patch, but I have removed it because it was
> too difficult to maintain while the rest of the patch was changing so
> rapidly...I do plan on replacing it, however.
> Hmm, particle density...I hadn't thought of that. I will need to write a
> function to compute this for particle fission/fusion anyway, so might as
> well include it...

Are U going to add propogation reactions like when a particle interacts with
a surface/other particle it creates new particles & changes in some way.

> BTW, one other problem with the particle_system pattern was that it was
> slow,since all the particles had to be calculated. I plan on adding a
> bounding structure based on recursively subdividing boxes(I think it is
> called an octree...) or planes(I have no idea what this is called) to
> speed up inter-particle force calculations, so that should really speed
> up the patterns...

What like ignoring particles so far away that the contribution is
negligible.

Another pattern could be based on the velocity & or direction of the
particles.

--
Bye
Pabs

Post a reply to this message

In article <396572FB.AC4D4BD3@nospamthanks.hotmail.com>, Pabs 
<pab### [at] nospamthankshotmailcom> wrote:

> Could work but maybe you could specify some different types of sampling -
> like the box method, point & bbox method, sphere & bbox method, random
> points in random directions et al.

That would be possible, but I don't know how useful it would be. I think 
the best coverage would result from taking a random point in the 
bounding box and firing the ray in a random direction...that seemed to 
produce the best coverage for the proximity pattern.


> Are U going to add propogation reactions like when a particle 
> interacts with a surface/other particle it creates new particles & 
> changes in some way.

I plan to implement things this way:
If a particle impacts a surface while traveling at a speed higher than a 
specified threshold, it will break into multiple particles smaller than 
the original(conserving mass and volume). Particle fission will also 
occur if the particle density in an area drops below a certain threshold.

Low-velocity impacts on a surface will take a different set of rules...I 
might add calculations based on proximity to the surface. The particles 
will cling to the surface, making it "get wet".

Particles will join together(fuse) if their velocities are close to 
being identical. This will be more likely if the particle density in the 
area is higher, and will not happen if it is below a certain threshold. 
This will help keep the simulation fairly efficient, so it doesn't get 
bogged down with a bunch of tiny particles.


> > BTW, one other problem with the particle_system pattern was that it was
> > slow,since all the particles had to be calculated. I plan on adding a
> > bounding structure based on recursively subdividing boxes(I think it is
> > called an octree...) or planes(I have no idea what this is called) to
> > speed up inter-particle force calculations, so that should really speed
> > up the patterns...
> 
> What like ignoring particles so far away that the contribution is
> negligible.

That is already done, but the distance calculation itself takes 
time...which is why I am going to attempt to make a bounding structure.


> Another pattern could be based on the velocity & or direction of the
> particles.

Or even better, a single pattern that can do all of those...particle 
density, average speed, average temperature, average age...

-- 
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

Chris Huff wrote:

> In article <396572FB.AC4D4BD3@nospamthanks.hotmail.com>, Pabs
> <pab### [at] nospamthankshotmailcom> wrote:
>
> > Could work but maybe you could specify some different types of sampling -
> > like the box method, point & bbox method, sphere & bbox method, random
> > points in random directions et al.
>
> That would be possible, but I don't know how useful it would be. I think
> the best coverage would result from taking a random point in the
> bounding box and firing the ray in a random direction...that seemed to
> produce the best coverage for the proximity pattern.
>
> > Are U going to add propogation reactions like when a particle
> > interacts with a surface/other particle it creates new particles &
> > changes in some way.
>
> I plan to implement things this way:
> If a particle impacts a surface while traveling at a speed higher than a
> specified threshold, it will break into multiple particles smaller than
> the original(conserving mass and volume). Particle fission will also
> occur if the particle density in an area drops below a certain threshold.
>
> Low-velocity impacts on a surface will take a different set of rules...I
> might add calculations based on proximity to the surface. The particles
> will cling to the surface, making it "get wet".
>
> Particles will join together(fuse) if their velocities are close to
> being identical. This will be more likely if the particle density in the
> area is higher, and will not happen if it is below a certain threshold.
> This will help keep the simulation fairly efficient, so it doesn't get
> bogged down with a bunch of tiny particles.
>
> > > BTW, one other problem with the particle_system pattern was that it was
> > > slow,since all the particles had to be calculated. I plan on adding a
> > > bounding structure based on recursively subdividing boxes(I think it is
> > > called an octree...) or planes(I have no idea what this is called) to
> > > speed up inter-particle force calculations, so that should really speed
> > > up the patterns...
> >
> > What like ignoring particles so far away that the contribution is
> > negligible.
>
> That is already done, but the distance calculation itself takes
> time...which is why I am going to attempt to make a bounding structure.
>
> > Another pattern could be based on the velocity & or direction of the
> > particles.
>
> Or even better, a single pattern that can do all of those...particle
> density, average speed, average temperature, average age...

That all sounds great :)
Runnning ... out ...of ideas...NOOOOOOOOOOOOOOOOOOOO!!

--
Bye
Pabs

Post a reply to this message