Gilles Tran <tra### [at] inapginrafr> wrote:
> Geoff Wedig wrote:

>> Hmm, from a physical standpoint, it seems the droplets form based upon the
>> surface tension and the amount of water available.  I don't know how true
>> this is to real life, but I'd try something like scattering points on the
>> surface.  Those are the drop points.  Then, for any other point on the
>> surface, add it's strength (assume all points have uniform strength) to the
>> point closest to it.  Once you've simulated long enough (where long enough
>> is probably on the range of 10 - 1000 * number of drops), each drop can be
>> formed based on its weight.  Other statistics (direction?) could be kept to
>> shape the drop rather than having them all spherical.  You should get
>> something approximating the right pattern, I'd think.
>>
>> But that's all idle speculation.  I dunno if it'd work.

> Not that idle. I like the idea. I'll give it a try if I find the time (the potential
> parsing time is scary).

Trust me, I understand.  I'm not adverse to high parse times, though.  Some
of my code takes ~2 hours to parse, then another 2-3 to allocate
memory/bounding boxes, etc.  *then* I get to render.  It gets about three
lines in 12 hours.  I run it over night/while I'm at work (which means I get
to reparse each night.  Ghods I wish there was a 'pickle' function for
parsed POV files!).  It might be done by Christmas.

But even I have limits.  I wrote a particle system for simulating cloth, and
even with relatively small numbers of points (~200), it took forever.  So I
rewrote it in C++.  Now, the above idea could be coded in C++, but that
requires knowing the points on the surface, which means you have to code the
surface in c++.  I'd probably do it in 3 stages. Create object and choose
drop points (in POV).  Use the output system to output those drop points. 
Read file as input to a c++ program which takes them, finds some reasonable
distribution (minimum distance between drops?), then does the simulation.

In any reasonable programming language, the simulation is almost trivial to
run.  It's only a couple of million points after all.  May take 10 minutes,
but compared to render time....

Tell me if it works.  I'm curious.

Geoff

Post a reply to this message

In article <39bf701f@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> Trust me, I understand.  I'm not adverse to high parse times, though. 
>  Some of my code takes ~2 hours to parse, then another 2-3 to 
> allocate memory/bounding boxes, etc.  *then* I get to render.  It 
> gets about three lines in 12 hours.  I run it over night/while I'm at 
> work (which means I get to reparse each night.  Ghods I wish there 
> was a 'pickle' function for parsed POV files!).  It might be done by 
> Christmas.

"Pickle" function?
You could have it output the objects after calculating them, so the 
calculations don't have to be done again. The file sizes would probably 
be quite big, though.
You might also get a speedup by turning vista buffering off...doing that 
will slow down rendering, but the 2-3 hours you save by not calculating 
them might make it worth it. It will also cut your memory usage down a 
bit.
If not all of the objects are visible and they aren't reflective or 
transparent, consider dropping some of them from the scene.


> But even I have limits.  I wrote a particle system for simulating 
> cloth, and even with relatively small numbers of points (~200), it 
> took forever.  So I rewrote it in C++.  Now, the above idea could be 
> coded in C++, but that requires knowing the points on the surface, 
> which means you have to code the surface in c++.  I'd probably do it 
> in 3 stages. Create object and choose drop points (in POV).  Use the 
> output system to output those drop points. Read file as input to a 
> c++ program which takes them, finds some reasonable distribution 
> (minimum distance between drops?), then does the simulation.
> 
> In any reasonable programming language, the simulation is almost 
> trivial to run.  It's only a couple of million points after all.  May 
> take 10 minutes, but compared to render time....

Instead of writing a separate program, you could do what I did with my 
particle system, and turn it into a POV patch. If you want to get points 
on an object, you have all the necessary tools right there.

-- 
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 <chr### [at] maccom> wrote:
> In article <39bf701f@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> Trust me, I understand.  I'm not adverse to high parse times, though. 
>>  Some of my code takes ~2 hours to parse, then another 2-3 to 
>> allocate memory/bounding boxes, etc.  *then* I get to render.  It 
>> gets about three lines in 12 hours.  I run it over night/while I'm at 
>> work (which means I get to reparse each night.  Ghods I wish there 
>> was a 'pickle' function for parsed POV files!).  It might be done by 
>> Christmas.

> "Pickle" function?

Sorry, python term.  Pickling an object is taking it and turning it into a
file. Basically, I'm thinking of something like a memory map of the object
space saved to disk.  This would require no parsing, basically, because the
memory map could then be reloaded and just placed in memory.

> You could have it output the objects after calculating them, so the 
> calculations don't have to be done again. The file sizes would probably 
> be quite big, though.

*very* big.  The current image is >200,000 objects, most with their own
textures (based on an algorithm).  I don't think that's practical.

> You might also get a speedup by turning vista buffering off...doing that 
> will slow down rendering, but the 2-3 hours you save by not calculating 
> them might make it worth it. It will also cut your memory usage down a 
> bit.

Unfortunately, many of the objects are small, so removing vista buffers and
bounding boxes would be fatal (I think.  I must admit I don't know for sure)

> If not all of the objects are visible and they aren't reflective or 
> transparent, consider dropping some of them from the scene.

already done.  There were a few that cast particular shadows that I removed
after those shadows were rendered (because I'm doing this incrementally, I
can do that)

Most of the problem is related to disk thrashing, I must admit.  I have 256
MB, and after the parse it never goes to disk, but while it's parsing, the
disk goes non-stop.  It's pretty ugly.

To be honest, I could reduce a lot of the work done in the macros given the
new features added in Megapov.  I just haven't had time so far to fiddle
with the code.

> Instead of writing a separate program, you could do what I did with my 
> particle system, and turn it into a POV patch. If you want to get points 
> on an object, you have all the necessary tools right there.

I didn't have the time to learn the POV code.  Secondly, I really wasn't
certain that doing it in pov was the best thing (from an efficiency
standpoint) and finally, I could run my simulation on a different computer,
so it could run while I rendered other stuff.

I haven't looked at your particle system patch yet, but I plan to the next
time I have a reason to use it.

Geoff

Post a reply to this message