 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Here the particle system is used to simulate a trail of smoke behind a
missile-like thing.
Each particle is colored dependent on its time of birth, and its density is
controlled by its age. Also, the particles are automatically shot backwards
relative to the movement direction of the emitter.
Chris Huff, although I've read the particle_system patch documentation, you
still know it much better than me. Could you tell me which of the features
mentioned above are also possible with the particle_system patch?
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
Attachments:
Download 'smoketrail.mpg' (60 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a97b94c@news.povray.org>, "Rune" <run### [at] iname com>
wrote:
> Chris Huff, although I've read the particle_system patch
> documentation, you still know it much better than me. Could you tell
> me which of the features mentioned above are also possible with the
> particle_system patch?
All of them (sort of). In the current patch, you would have to do some
of it yourself, running the particle system for short intervals of time
and updating the position of the particle emitter between them, but this
will probably lead to artifacts from the emitter jerkily moving from
place (aliasing, like those "puffs" of smoke from your rocket), and will
be slowed down by the processing overhead of POV Script.
I'll be working on a dynamic_transform or transform_spline that will
interpolate between transformations, allowing things like emitters and
objects to move while the particle system runs. Hopefully, it will also
be useful for ordinary animations...
The age of each particle is available, so you could do your own
particles using that information. (the time of birth, of course, is just
current_time-particle_age)
--
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:
> In the current patch, you would have to do some of it yourself,
> running the particle system for short intervals of time and
> updating the position of the particle emitter between them,
Why? Does it not support moving emitter-points directly?
> but this will probably lead to artifacts from the emitter
> jerkily moving from place (aliasing, like those "puffs" of
> smoke from your rocket),
Those puffs are not caused by aliasing. Each puff is only one particle, not
a group of particles. They're caused by a low particle_frequency. If the
particle_frequency were high enough, there would be no visible puffs, even
if the particle_frequency were higher than the calculation frame-rate.
> I'll be working on a dynamic_transform or transform_spline that
> will interpolate between transformations, allowing things like
> emitters and objects to move while the particle system runs.
Moving particle-emitters are already supported in my system, but not moving
environment-objects.
> Hopefully, it will also be useful for ordinary animations...
I think it would be very useful to be able to interpolate transformations. I
have often done similar things myself (in POV-script).
> The age of each particle is available
Not in the current version, according to the documentation, but it does say
that it will be available in future versions...
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 <3a97d688@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> Why? Does it not support moving emitter-points directly?
No. There isn't any way to specify that type of information yet, that's
why I'm working on the dynamic_transform patch. I wanted to use a method
that was at least as flexible as ordinary clock-based animation, so I
didn't want to use splines.
> Moving particle-emitters are already supported in my system, but not
> moving environment-objects.
One problem I have yet to figure out how to get around is the "trapping"
of particles inside the environment object...maybe transforming
particles within a certain distance of the object (close enough to be
considered "on" it) along with the object, and modifying their velocity
will work.
> > The age of each particle is available
> Not in the current version, according to the documentation, but it
> does say that it will be available in future versions...
Oops! Well, my version in progress supports radius, mass, and
temperature as well as age, velocity, and position.
--
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:
>
> > Why? Does it not support moving emitter-points directly?
>
> No. There isn't any way to specify that type of information yet,
> that's why I'm working on the dynamic_transform patch. I wanted
> to use a method that was at least as flexible as ordinary
> clock-based animation, so I didn't want to use splines.
I completely agree. That's why the particle_emitter point and direction can
be animated exactly as flexible as regular clock animation in my system. I
have not used splines in any of my posted particle system animations.
> > Moving particle-emitters are already supported in my system,
> > but not moving environment-objects.
>
> One problem I have yet to figure out how to get around is the
> "trapping" of particles inside the environment object...
Yes, that problem we have in common...
> maybe transforming particles within a certain distance of the
> object (close enough to be considered "on" it) along with the
> object, and modifying their velocity will work.
But what if the object moves a greater distance between two calculation
frames than that certain distance you mentioned? And what if the surface
movement is not caused by a transformation but by - say an isosurface with a
varying function?
> Oops! Well, my version in progress supports radius, mass, and
> temperature as well as age, velocity, and position.
I have never understood what use the temperature feature is. What can it be
used to simulate?
From the documentation:
> As the simulation goes on, particles will tend toward the
> temperature of their environment. Particles hotter than
> their environment will tend to go against gravity and float,
> colder particles will sink.
I don't see the logic in this. It has noting to do with reality. Hot water
doesn't float just because it's hotter than the air around it. The
temperature at which it begins to float is much higher than the temperature
of the environment. In fact, the temperature of the environment seems to be
completely irrelevant. And wouldn't your system end up in a state where the
particles neither sink nor float?
Please explain the concept.
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 <3a98066b@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> But what if the object moves a greater distance between two
> calculation frames than that certain distance you mentioned? And what
> if the surface movement is not caused by a transformation but by -
> say an isosurface with a varying function?
That would still be a problem. I'll probably add a feature to kill
particles that end up inside an environment object, so at least time
won't be wasted processing them.
> I have never understood what use the temperature feature is. What can
> it be used to simulate?
Mainly convection and the effects of smoke rising and cooling.
> From the documentation:
> > As the simulation goes on, particles will tend toward the
> > temperature of their environment. Particles hotter than
> > their environment will tend to go against gravity and float,
> > colder particles will sink.
>
> I don't see the logic in this. It has noting to do with reality. Hot
> water doesn't float just because it's hotter than the air around it.
Huh? Water normally doesn't float in air...
> The temperature at which it begins to float is much higher than the
> temperature of the environment. In fact, the temperature of the
> environment seems to be completely irrelevant.
The reason convection happens is the density difference between one mass
of air, and the surrounding air. The density is affected by the
temperature, which will cause a warmer mass of air to rise. And there is
no threshold of temperature difference below which it won't happen. It
can be on the order of a couple degrees, which is why we have weather.
> And wouldn't your system end up in a state where the particles
> neither sink nor float?
It will, eventually, if you have no heat sources or emitters of
unusually hot or code particles. In the same way that smoke will
eventually disperse throughout a room.
--
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" <run### [at] inamecom> wrote in message
news:3a97b94c@news.povray.org...
> Here the particle system is used to simulate a trail of smoke behind a
> missile-like thing.
That is a very realistic (for POV) animation. I mean discounting the
missile and the colored smoke that fades a little jerkily and all the other
things one should discount...
What kind of render time did you get for that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Huff" wrote:
> "Rune" wrote:
> > I have never understood what use the temperature feature is.
> > What can it be used to simulate?
>
> Mainly convection and the effects of smoke rising and cooling.
Aha.
> > From the documentation:
> > > As the simulation goes on, particles will tend toward the
> > > temperature of their environment. Particles hotter than
> > > their environment will tend to go against gravity and float,
> > > colder particles will sink.
> >
> > I don't see the logic in this. It has noting to do with reality. Hot
> > water doesn't float just because it's hotter than the air around it.
>
> Huh? Water normally doesn't float in air...
When water is below 100 degrees Celsius / 212 degrees Fahrenheit it falls.
When it is above, it rises. The "threshold" is at 100 degrees Celsius, not
at the temperature of the environment. So the "rule" does not apply to
water, not always anyway.
> The reason convection happens is the density difference between
> one mass of air, and the surrounding air. The density is affected
> by the temperature, which will cause a warmer mass of air to rise.
But the particles themselves are not air, right? They just drift around with
the air surrounding them. So if smoke is surrounded by hot air, it will
drift upwards along with the air. However, all this only applies to
materials that have densities very close to the density of air (like smoke).
It doesn't apply to many other materials such as cool water which does not
normally drift along with air, even if its temperature is higher than the
environment temperature.
Since the temperature feature does not apply to all uses of the system, can
it be turned off?
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 <3a983257@news.povray.org>, "Rune" <run### [at] inamecom>
wrote:
> > Huh? Water normally doesn't float in air...
>
> When water is below 100 degrees Celsius / 212 degrees Fahrenheit it
> falls. When it is above, it rises. The "threshold" is at 100 degrees
> Celsius, not at the temperature of the environment. So the "rule"
> does not apply to water, not always anyway.
Uh, water boils above 100C. This is phase change, not convection. My
patch doesn't simulate phase changes. (well, it might, if you use
inter-particle forces and simulate temperature change by changing the
velocity of the particles, but it has nothing to do with the temperature
feature of atmospheric particles)
> > The reason convection happens is the density difference between one
> > mass of air, and the surrounding air. The density is affected by
> > the temperature, which will cause a warmer mass of air to rise.
>
> But the particles themselves are not air, right? They just drift
> around with the air surrounding them. So if smoke is surrounded by
> hot air, it will drift upwards along with the air. However, all this
> only applies to materials that have densities very close to the
> density of air (like smoke). It doesn't apply to many other materials
> such as cool water which does not normally drift along with air, even
> if its temperature is higher than the environment temperature.
The particle system doesn't simulate the interactions of different kinds
of fluids yet. The atmospheric particles simply assume the environment
has a very similar density when at the same temperature. And as I said
before, it doesn't do phase change, so you can't simulate the boiling
off of water into steam which then rises into the air with a single
group of particles, you will have to use separate particles for the
liquid water and for the steam, maybe separate systems.
I plan on eventually giving each particle a density value, along with
support of multiple fluid types.
> Since the temperature feature does not apply to all uses of the
> system, can it be turned off?
It only applies to atmospheric particles.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bill DeWitt" wrote:
> That is a very realistic (for POV) animation. I mean
> discounting the missile and the colored smoke that fades
> a little jerkily and all the other things one should
> discount...
I didn't go for realism... :)
> What kind of render time did you get for that.
I used emission and absorption media, method 3, with only one sample. I
think though that more samples are created internally, since the spheres
overlap so much.
The animation is 40 frames. It took perhaps 50-55 sec. a frame. 48 of those
are tracing.
And note that my computer is a slow P150 w. 16 MB RAM.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
