Christoph Hormann <chr### [at] gmxde> wrote:



> Geoff Wedig wrote:
>> 
>> Well, the water isn't really all that big, maybe 200 x 300 feet (in my
>> personal scaling 1 pov unit = 1 foot.  Makes visualization easier)  What do
>> you suggest doing for the water?  A small photoned area cut out from the
>> rest?  I don't like doing differences with isos, so I'm not certain that's a
>> good idea.
>> 

> Exactly that, it's probably really worth trying, i not yet tried it with
> isosurfaces, but i don't see a reason why it sould not work.  For a
> realistic horizon you will need quite a large water shape so you would
> even have no choice.  

Well, I'm trying it with a test render now.

>> 
>> That's really tricky.  I'm using PVMega, so most output is mostly
>> surpressed.  The full picture took 72:56:00 using 15 PII 400's running
>> Mosix.  Probably not as long as the Tulip pic on a single processor, but I'm
>> not about to try it. :/
>> 

> That really sound quite long, the photon time is probably negligible
> anyway with only 20000 photons.  

The dark pictures take between 12-24 hours with the same setup (and varying
levels of detail).  To be honest, I'm finding PVM much slower than I would
have thought.  Perhaps ti's the radiosity (which PVMega has trouble with),
but the same things running on my desktop 1 Ghz Athlon seem to zip much
faster.  Either the information swapping is much greater than I expected, or
something.

>> This was significantly longer than the darkness pictures, despite those
>> having the major light sources within scattering media, and area lights
>> besides.  The bright picture uses a far off point light, so photons slow
>> things down immensely (of course, photons + isos + radiosity is never going
>> to be fast)
>> 

> I was just about to suggest a lower error_bound when i saw your picture
> first, but it's probably out of question with such a slow render.  

> BTW, do you use some kind of manual bounding for the bricks?

Yes, the bounding block for each brick is calculated based upon the
positions of their eight vertices and the curvature of the tower they belong
to.  It's given a 1 % growth just to give a bit of extra room.

The bricks seemed to be the slowest part right now, and mostly due to the
textures.  The texures are many layers of procedural texture, and that makes
things quite slow.  I've wished more than once for a version optimized for
textures (using 3Dnow equivalents, since I gather those only do single
point) or a method of layering textures that's not quite so slow, but I
don't think that's really an option.

On the other hand, the 3-6 times slowdown when removing two area lights and
replacing with a single light source, but also adding a new iso with photons
seems to be fairly significant.

Geoff


Geoff

Post a reply to this message