Tim, this all looks fabulous. Incredible work. You have something really 
great going on here.

There's just one thing I thought of this morning while looking out over 
the yard, which just acquired its first good snow yesterday. Snow 
doesn't fall evenly or perfectly vertically, and even once it falls 
there's still significant scattering once on the ground due to wind. I 
think a good addition to your macro, if you're still in a programming 
mood, would be a randomization step. It would come after you run the 
particles through the filters but before you calculate drifts. Something 
that would randomize the location of each particle for a small amount. 
You would probably have to run the filters again to make sure you don't 
end up with particles hanging out in space.

I think this would help eliminate that "blobby" look there sometimes is 
and would give it a more natural look. It would also add the very 
natural occurence of uneven coverage and even bare spots on a tree (a 
pine tree in the backyard has small spots of snow (six inches or so) 
every so often and the rest of the tree is bare).

I would also add in a filter that would take snow off of objects that 
are really small (third level branches, for example). Snow just doesn't 
often stick to objects that small anyway, unless there's a huge amount 
of snow, in which case it covers everything.


But even without that you have some great work here, and some incredible 
results. I'm first in line to download the macros when you release them 
(I have a project all scoped out - actually one I've wanted to try for 
some time). :)

Keep it up!

~Mike

Tim Nikias wrote:
> So, the final version, of which I won't do another excessive test. Here we
> have 1700 spheres and 49600 cylinders in a blob, and there are still a few
> places where a cylinder pops up when it should be a sphere. This one already
> required 50 minutes. The point is that even though I could do long and
> excruciating parses with ridiculously high settings, the same effect can be
> achieved by combining a simpler, pure sphere-version with a cylinder-version
> on a less detailed structure.
> 
> OTOH, if you have an admirable piece of hardware as a CPU, the parsing times
> could drop to a level where it might be feasible doing them. But these "ifs"
> pop up everywhere: *if* the PC where much faster, I'd do some Navier Stokes
> Equations in Realtime... ;-)
> 
> Regards,
> Tim

Post a reply to this message

> That one looks quite good.  How do you sample the surfaces - do you just
> trace the whole bounding box area or is it some adaptive process?  How
> well does it work with some wind (i.e. with the snow coming a bit from
> the side and sticking to the vertical parts)?

Haven't followed the progress of this project, eh? ;-)

First, a macro generates a camera which creates an orthographic view onto
the object with the direction intended to be used for the surface sampling.
This view is plain black/white where the object is white.
Then, I do a pretest. Given the orthographic view, I divide the area into
cells and check each if they have cross from white to black at their edges.
If that fails, I check the center of the cell in case the entire cell is
enclosed within the object. This step is done by using the image as the
basis for a heightfield and applying trace() along the edges of the cells. I
know that I could probably save a little parsing time on this if I'd reuse
the edge-tests for neighbouring cells, but then again, this step is really
the smallest step in the entire chain and not really worth the work.
Once I've figured which cells to be active, I trace() the object with a type
of fibonacci distribution which spreads the samples a lot nicer than plain
u-v-discrete samples would have: this doesn't create such obvious patterns.
The trace() just passes through the entire object, collecting every surface
along the way. These are all saved into one giant file, along with the
discovered normal of those samples.

Then, I apply some selecting macros, which remove samples on surfaces that
are too steep (just a simple angle test between sample-normal and a given
direction), or are within/outside of a given boundary-box or object. A more
tricky macro will check for each sample how much of the sky can be seen when
viewing towards a given direction. A certain percentage is required to keep
the samples, otherwise, the macro assumes that the particle couldn't have
got there and removes it. Hence I get snow-free areas on the CSG object (not
on the trees, obviously there's lots of sky to be seen).

And finally, to calculate how high the cylindrical part of a sample may be,
I trace the upper hemispherical view and check how close the object is. If
enough of the samples are close enough, the particle grows in y-direction to
simulate wall-stacking behaviour.

Note that I use *many* trace() calls for all this, mainly because with
meshes functions are not really an option (and because I'm no pro on
functions, this fits me well). :-)

And as you can see, dependant on how many samples the hemispherical test
uses and with which distance the hemisphere still affects the particle, some
of the particles just grow because lots of hemisphere-samples just hit a
very tiny branch. Like I said, increasing sampling and decreasing distance
would help, but raise parsing even further. And since the stacking effect is
really just needed and visible near the trunk, I can use a simpler tree to
do all those tests, and get away with it. :-)

> Note parsing speed is not so much a question of the CPU but of general
> system performance.

I've always thought that POV-Ray relies heavily on the CPU, it's *the*
driving force. Of course, if the entire system is slow and has low resources
to offer, a CPU can only do *that* much. I guess that *I* would probably
notice the most difference when switching to a faster CPU. Of course, the
data bus and I/O transfer between CPU, Harddrive, RAM etc can slow down
things a lot if picked improperly, but would that really affect the render
*that* much? Honest question, not rhetorical.

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

> Tim, this all looks fabulous. Incredible work. You have something really
> great going on here.

Thank you. Motivating feedback is always good. :-)

> There's just one thing I thought of this morning while looking out over
> the yard, which just acquired its first good snow yesterday. Snow
> doesn't fall evenly or perfectly vertically, and even once it falls
> there's still significant scattering once on the ground due to wind.
SNIP

Yeah, drifts and the like... What actually *is* implemented is a check if
the surface below the particle is thick enough, if it isn't, the particle
gets removed. Of course, if you shoot vertically down a thin cylinder, the
bottom would be far enough to pass the test... Generally, I think this set
of macros is best used with some manual tweaking, like using a slightly
different object for the particle sampling than for the filters. As for
drifts: You'd still need some order within the randomization process, or
you'd just end up with chaotic displacements of particles. Still, this is
something I plan on integrating somehow, probably for the visualization
phase. One could use the turbulence field or a function to modify the
heights of particles or remove them altogether (e.g. interpolating from
unchanged particles to smaller particles and finally removing them). It's
something I've got in mind. Actually, like with my I/O Particle System, I
want to create a macros which make it easy for advanced Users to build their
own filters and modifiers.

> But even without that you have some great work here, and some incredible
> results. I'm first in line to download the macros when you release them
> (I have a project all scoped out - actually one I've wanted to try for
> some time). :)

Oooh, pressure! Someone needs my macros! Ups! Deleted everything, can't work
under pressure. ;-)

I'll post a note when the macros are released, but that might still be a few
weeks off.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Tim Nikias wrote:
> 
> Haven't followed the progress of this project, eh? ;-)

No, not really.

> First, a macro generates a camera which creates an orthographic view onto
> the object with the direction intended to be used for the surface sampling.
> This view is plain black/white where the object is white.
> Then, I do a pretest. Given the orthographic view, I divide the area into
> cells and check each if they have cross from white to black at their edges.
> If that fails, [...]

That will have problems with geometric features that are smaller than 
the cells i assume.  Still a clever idea of course - it will improve 
performance for thing like trees but if the orthographic view is nearly 
totally white a conventional sampling of the whole area would be more 
efficient.

> 
> I've always thought that POV-Ray relies heavily on the CPU, it's *the*
> driving force. 

That's the case for *rendering* but not for *parsing*.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 23 Sep. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

> That will have problems with geometric features that are smaller than
> the cells i assume.

The typical problem with sampling: inbetween samples you can of course miss
things which fit between two samples. Still, the main idea is to supply a
single, connected object, not pairs to groups of objects. In such a case,
when the boundary box isn't way too big, the boundary box should give a
reasonable scaling as to at least fill a few cells.

> Still a clever idea of course - it will improve
> performance for thing like trees but if the orthographic view is nearly
> totally white a conventional sampling of the whole area would be more
> efficient.

True. But I assume that in most cases, this won't happen. Also, if the
topview-image isn't supplied, there won't be any pretesting and sorting of
active and inactive cells, it'll just be a subdivided sampling. Not too much
loss.

> > I've always thought that POV-Ray relies heavily on the CPU, it's *the*
> > driving force.
>
> That's the case for *rendering* but not for *parsing*.

Oh, yeah, right. Duh... Should have thought a little harder. :-)

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Tim Nikias wrote:

The tree looks great, but there is a problem with the accumulation near 
vertical surfaces on the simple CSG object. There is no reason for 
accumulation on the bottom of the cylinder, because no snow could have 
fallen into that area.

  -Shay

Post a reply to this message

Shay wrote:
> Tim Nikias wrote:
> 
> The tree looks great, but there is a problem with the accumulation near 
> vertical surfaces on the simple CSG object. There is no reason for 
> accumulation on the bottom of the cylinder, because no snow could have 
> fallen into that area.

...assuming that snow falls perfectly vertically and doesn't blow around 
once it gets to the ground. Which it doesn't and does, respectively.

~Mike

Post a reply to this message

Mike Thorn wrote:

> ...assuming that snow falls perfectly vertically and doesn't blow around 
> once it gets to the ground. Which it doesn't and does, respectively.
> 
> ~Mike

The entire algorithm is built around the assumption that snow doesn't 
blow around *that* much. Otherwise, the entire horizontal surface of the 
lower platform would be covered. It's an excellent fake still. Just 
pointing out one little area that might be improved.

  -Shay

Post a reply to this message

> The entire algorithm is built around the assumption that snow doesn't
> blow around *that* much. Otherwise, the entire horizontal surface of the
> lower platform would be covered. It's an excellent fake still. Just
> pointing out one little area that might be improved.

The algorithm is very straightforward and simple: place samples and remove
undesired ones (e.g. a macro removes the samples underneath the "roof" of
the CSG object, but not on the edges, as some snow could have fallen there)
and as a last step: check for every particle if there's a wall and how close
it is to the particle.

I intend to make a modifying macro, which will modify the heights of such
particles. With the proper setup, such spots can be corrected manually, as
well as introducing some more "natural" randomness into the distribution.
Overall, the system is designed to just provide the basic building blocks,
and then some work is required to model it to perfection. It's less a "real"
simulation than more a hybrid system of various sampling methods to select
and modify particles.

But thanks for the feedback. :-)

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

I've written a macro which will read the particles' data and let the User
define two macros to modify the snow: one will just modify the height (by
multiplying with the return-value of the Macro), the other will add/subtract
from the height. Once the multiplier and/or the height gets negative, the
particle will be removed.

This is the result when pairing the existing snow with the turbulence-field
to adjust the height of particles. Just a rough proof-of-concept.

As a final note: I've now figured the official name for the macros: I'll
name them the "Surcoat-Macros". The Surcoat-System is just used to sample a
surface and collect/remove samples with various macros to take care of steep
surfaces or the like. The files returned by the Surcoat-System are pretty
simple: a succession of a sample's positions and it's surface normal. Other
Macros build on this data and are called Plug-Ins. The snowfall-macros is
one such plug-in, as it adds a little more data (e.g. the height of a
particle) to simulate snow-related effects.

Other effects, like moss or paint, may follow and/or can be written by the
User himself.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>

Post a reply to this message

Attachments:
Download 'csg_snow.jpg' (15 KB)

Preview of image 'csg_snow.jpg'