It depends on several factors. For the parsing time,
the resolution of the array which holds the heights
is the main factor, along with the amount of steps that
have to be calculated per frame.
After the simulation, my Mesh-Modifying-Macros kick
in to generate the mesh and its surface-normals. These
also take a little time, but very little compared to the
simulation.
The tracing time depends on the features I'm using. The
mesh itself can be traced fairly quick, but if I'm using
a transparent surface, variable reflection and photons,
render time rises of course. Along with that, I use antialiasing
for the the final renders, so that even the large high-quality
MPGs I keep for myself look smooth.
On a render I'm doing right now, I'm using 60*60 Nodes, so
thats 3600 nodes for the simulation. Mind that the simulation
sort of "clips" dead nodes and doesn't touch them. On these
spherical pools, this saves a lot, since the corners are
completely left out. The mesh uses a reflecting surface to get
that liquid metal look. Additionally, I use antialiasing on the
current render.
Thus, on my Athlon 1.4GHz, it parses at about 13 seconds
per frame, and traces with about 23 seconds per frame.
So thats 36 seconds per frame. For 250 frames, this takes
roughly 2h.
Still, parsing time wouldn't go up with more or less waves,
their height doesn't matter. So, thats an advantage, and
can guesstimate fairly good how long an animation
might take. OTOH, it'll take that long for parsing even
if there's no wave present.



--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: Tim### [at] gmxde

>
> --------------( oo )--------------
>
> Your simulation are very interresting.
> You said that it tooks a lot of calculation to render this. How much time
> does it tooks? Is the Parsing is longer than the render time?
>
> --------------( oo )--------------

>
>

Post a reply to this message