Hi,

> 
> > Since the temperature feature does not apply to all uses of the
> > system, can it be turned off?
> 
> It only applies to atmospheric particles.

Sorry, but i think this is not quite right. Also in liquids convection
occures. If you put some color small particles into an liquid you can
see it, i.e. Put some cold milk into hot coffee, but be very carefully:
You will see that the white milk will be at first at the bottom of the
cup, than the white milk particles will rise in the center of the cup.
If yo wait long enough and keep the coffee at the same temperature the
milk will completely mix with the coffee (same as the smoke). 

However one problem is there with water as liquid, as water has highest
density at 4 degrees Celsius (sorry I don't know the degrees of
Farenheit): That is also colder water will rise! (The cause why you find
in winter unfrozen water at the bottom of lakes, and the water will
freese from the top of the lakes. Additional to the fact that ice is
lighter water, the freezing process really begins the water surface)

Yours 

Axel

Post a reply to this message

In article <3A9B8F8A.368EA80C@nirvana.net>, "A.B." 
<any### [at] nirvananet> wrote:

> Sorry, but i think this is not quite right. Also in liquids convection
> occures. If you put some color small particles into an liquid you can
> see it, i.e. Put some cold milk into hot coffee, but be very carefully:

They are only called atmospheric particles, there is nothing stopping 
you from using them in liquids. However, I will probably add a liquid 
particle type as well, which will also do convection, as well as other 
liquid behaviors...or eliminate different particle types altogether.


> However one problem is there with water as liquid, as water has highest
> density at 4 degrees Celsius (sorry I don't know the degrees of
> Farenheit): That is also colder water will rise! (The cause why you find
> in winter unfrozen water at the bottom of lakes, and the water will
> freese from the top of the lakes. Additional to the fact that ice is
> lighter water, the freezing process really begins the water surface)

I am aware of this, but I do not plan to simulate this effect, since it 
happens to few liquids besides water and will be irrelevant 99.9999% of 
the times the particle_system patch is used.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Hi again,

> > Sorry, but i think this is not quite right. Also in liquids convection
> > occures. If you put some color small particles into an liquid you can
> > see it, i.e. Put some cold milk into hot coffee, but be very carefully:
> 
> They are only called atmospheric particles, there is nothing stopping
> you from using them in liquids. However, I will probably add a liquid
> particle type as well, which will also do convection, as well as other
> liquid behaviors...or eliminate different particle types altogether.

I did't meant my posting that you can't use the  particles for liquids,
but I got the impression that Rune had the limiting view that the
convection stuff is only relevant for atmospheric effects (i.e. density
of air). I meant my posting as a clarification for him that convection
phenomens also exist for liquids and therfore are more global, so that
it is worth of taking them into account and the work to impement them.
No criticism to your (and any other) person meant. Sorry if it sounded
like it but I'm not native english and soforth not so firm in writing
english. 

> > However one problem is there with water as liquid, as water has highest
> > density at 4 degrees Celsius (sorry I don't know the degrees of
> > Farenheit): That is also colder water will rise! (The cause why you find
> > in winter unfrozen water at the bottom of lakes, and the water will
> > freese from the top of the lakes. Additional to the fact that ice is
> > lighter water, the freezing process really begins the water surface)
> 
> I am aware of this, but I do not plan to simulate this effect, since it
> happens to few liquids besides water and will be irrelevant 99.9999% of
> the times the particle_system patch is used.

Like above, I tried to clarify that taking water as an example is not an
so ideal choice: Like you said it is a very specific property of a few
liquids. It would be nice if it could be simulated, but I don't think it
is worth the work to implement this very specific effect.

Besides this: thanks to you and all the other people which implement all
these great stuff in general

Yours 

Axel

Post a reply to this message

"A.B." wrote:
> I did't meant my posting that you can't use the particles
> for liquids, but I got the impression that Rune had the
> limiting view that the convection stuff is only relevant
> for atmospheric effects (i.e. density of air). I meant my
> posting as a clarification for him that convection
> phenomens also exist for liquids and therfore are more
> global, so that it is worth of taking them into account
> and the work to impement them.

I didn't mean that convection is only relevant for atmospheric effects. My
point was that since the particle_system patch takes into account
temperature, but not density, the convection only works correctly when the
density of the particles and the density of the surroundings are equal, such
as smoke in air. If I am mistaken here, please correct me.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message

"Chris Huff" wrote:
> I will probably add a liquid particle type as well, which
> will also do convection, as well as other liquid behaviors...
> or eliminate different particle types altogether.

Generally I am against the whole concept of types in POV-Ray features. They
are unavoidable sometimes, but I think that they should be avoided for the
most part.

When a feature has different types it is the programmer who decides which
types are available. Instead the programmer should make the feature so
flexible that all types can be achieved by using different settings, as well
as everything in between, and also for things the programmer didn't even
think of.

Think about it - wouldn't it be annoying if there was an "indoor radiosity
type" and an "outdoor radiosity type" and just a few others? I know I would
feel like some decisions had been made for me.

I think the particle_system should be general enough to simulate all kinds
of particles using the same set of settings, and without having specific
preset types.

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a9c1ace@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> I didn't mean that convection is only relevant for atmospheric 
> effects. My point was that since the particle_system patch takes into 
> account temperature, but not density, the convection only works 
> correctly when the density of the particles and the density of the 
> surroundings are equal, such as smoke in air. If I am mistaken here, 
> please correct me.

You are not mistaken. Actually, the whole heat convection thing was just 
hacked up...the new version will use a heat_source keyword to define 
heat sources throughout the world, and if a global patterned 
"temperature map" is available, it will be a pattern and spline, not a 
pattern and color_map, as it currently is. Particle temperature should 
also be affected by the temperature of nearby particles. And I may add 
density...it probably wouldn't be as flexible as separate user-defined 
fluid types (which would mainly be "presets" for particle parameters, 
but could also possibly interact with each other in odd ways), but would 
allow some simulation of different density fluids, such as fresh and 
salt water, and air/smoke.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a9c1ad0@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> Generally I am against the whole concept of types in POV-Ray 
> features. They are unavoidable sometimes, but I think that they 
> should be avoided for the most part.

In this case, they could be a very useful memory enhancement, since not 
all particles will use the same amount of memory. (in the current patch, 
they do, but I plan to change this some day)


> When a feature has different types it is the programmer who decides 
> which types are available. Instead the programmer should make the 
> feature so flexible that all types can be achieved by using different 
> settings, as well as everything in between, and also for things the 
> programmer didn't even think of.
...
> I think the particle_system should be general enough to simulate all 
> kinds of particles using the same set of settings, and without having 
> specific preset types.

My initial goal was to make it easier to use...I didn't want people to 
wonder "do I need this parameter for sand?", for example. Also, 
particles used for different purposes use a different set of features, 
and so a type of particle that only uses a subset of those won't waste 
memory on the unused parameters.
I plan on having 4 types:
Atmospheric, for doing smoke, etc.
Liquid, for water, paint, etc.
Solid, for sand, snow, and other stuff composed of solid "grains" that 
can pile up.
Generic, that can do any combination of the above, but uses more memory.
When you have thousands of particles, it can really make a difference.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" wrote:
> "Rune" wrote:
>
> > Generally I am against the whole concept of types in POV-Ray
> > features. They are unavoidable sometimes, but I think that they
> > should be avoided for the most part.
>
> In this case, they could be a very useful memory enhancement,
> since not all particles will use the same amount of memory.

And why would types be the best solution to this problem?

> My initial goal was to make it easier to use...
> I didn't want people to wonder "do I need this parameter for sand?"

And showing the user different useful combinations of settings would not
work? It has to be specific types with different preset behaviours?

> particles used for different purposes use a different set of
> features, and so a type of particle that only uses a subset
> of those won't waste memory on the unused parameters.

Make it possible to enable/disable the individual features. That's more
flexible than using types.

> I plan on having 4 types: Atmospheric, for doing smoke, etc.
> Liquid, for water, paint, etc. Solid, for sand, snow, and other
> stuff composed of solid "grains" that can pile up.
> Generic, that can do any combination of the above, but uses more
> memory. When you have thousands of particles, it can really make
> a difference.

Oh, so 3 of the types are just specific optimisations. That's sounds better.
But still, why can't the user just disable all features that he doesn't need
and save memory that way?

Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org

Post a reply to this message

In article <3a9d4d12@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> > In this case, they could be a very useful memory enhancement,
> > since not all particles will use the same amount of memory.
> And why would types be the best solution to this problem?

If you are aware of a better way, say so!
It should be possible to store only position, velocity, other basic 
information common to all particles, a bit field to define which 
features are used, and an array that has a different length depending on 
these features, handling all the memory myself...but that would be very 
difficult, bug-prone, and difficult to maintain, as well as possibly 
platform-dependant and difficult and time-consuming to code in the first 
place, with little benefit. Having specialized types of particles is the 
easiest and most flexible optimization.


> > particles used for different purposes use a different set of
> > features, and so a type of particle that only uses a subset
> > of those won't waste memory on the unused parameters.
> 
> Make it possible to enable/disable the individual features. That's more
> flexible than using types.

You *can* enable/disable individual features. There are just specialized 
types of particles available with specific feature sets.


> Oh, so 3 of the types are just specific optimisations. That's sounds 
> better. But still, why can't the user just disable all features that 
> he doesn't need and save memory that way?

Because some memory still has to be allocated for storage of data for 
those features.
Anyway, I may never add the additional types, things will just be set up 
so they can be added if necessary later. I will be developing the 
features in the "generic" type first, and specialize when memory usage 
becomes a problem or a radically different behavior is added.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Rune,

Great!
(I know I'm a little late in replying.)

Excellent job with the colors, as well.

Peter

Post a reply to this message