Well maybe the sea is a bit more violent at theplace you life... in bahrain
I love the still water sea shore..........




"Geoff Wedig" <wed### [at] darwinepbicwruedu> wrote in message
news:3adc329a@news.povray.org...
> Saadat Saeed <saa### [at] batelcocombh> wrote:
>
> > Try to make the water a bit more still!
>
> More still?  I thought the water was a bit *too* still.  It looks a little
> flat.  Needs to have some rolling waves, I thought.
>
> Geoff

Post a reply to this message

Was it Tom Melly or Gilles Trans that did the 'Wet bird' scene? I remember
that fog was used to give the effect of rain. It is sort of the same thing
anyway...?!  If it worked for him, I guess it could work for you   :)

Nekar

"Geoff Wedig" <wed### [at] darwinepbicwruedu> wrote in message
news:3adc57cd@news.povray.org...
> Gail Shaw <gsh### [at] monotixcoza> wrote:
>
>
> > Geoff Wedig <wed### [at] darwinepbicwruedu> wrote in message
> > news:3adc4434@news.povray.org...
> >>
> >> Gack!  Anyone have a good method for doing rain that doesn't involve
> >> millions of drops? :/
>
> > Try a plane/box very close to the camera with a mostly transparent
> > bozo texture. Should be fairly convincing, especially if you also
> > use a fog/media for murkiness
>
> Hmm, yeah, I could try that.  If I scale it a bit, and rotate it to get an
> angle.  Yeah, could work.
>
> Hmmm.
>
> Maybe I should have the storm coming in, then I don't have to have actual
> rain in the picture. :/
>
> Geoff

Post a reply to this message

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



> Geoff Wedig wrote:
>> 
>> Only used 20,000 photons, which isn't near enough for the size of the water
>> plane.  There's a lot of speckling.  

> You don't need the whole water plane, i elaborated this a bit in my
> 'outdoor water photons' experiments.  

> If only 20000 photons are distributed over the whole water the light
> structures are probably fairly random and not related to the water
> structure.  

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.

>> What type of statistics did you want?
>> 

> mostly render and photon times.  

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. :/

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)

>> 
>> When talking about the glow, did you mean the light from it, or the glows
>> themselves?  

> I meant the glows themselves.  Imagine for example a fire in sunlight. 
> Even  if it is very bright, it's brightness is hardly visible.  

Ah, that doesn't bother me.  You can still see the fire, after all, and the
glow isn't that much brighter than the surrounding bricks.  I may tone it
down slightly, but not much.

Geoff

Post a reply to this message

Nekar Xenos <vir### [at] iconcoza> wrote:

> Was it Tom Melly or Gilles Trans that did the 'Wet bird' scene? I remember
> that fog was used to give the effect of rain. It is sort of the same thing
> anyway...?!  If it worked for him, I guess it could work for you   :)

Hmm, maybe.

Geoff

Post a reply to this message

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.  

> 
> 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.  

> 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?

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

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

Geoff Wedig wrote:
> 
> 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.
> 

How about a hierarchical bounding structure, i made very good experiences
with regular tilings using recursive macros, in your case things are much
more complicated of course.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

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



> Geoff Wedig wrote:
>> 
>> 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.
>> 

> How about a hierarchical bounding structure, i made very good experiences
> with regular tilings using recursive macros, in your case things are much
> more complicated of course.  

Well, sections are unioned together, so that should bound them somewhat. 
So, for example, the front tower is made up of the base unit, the upper
unit, the outward sloping part of the crennelations and the wall part of the
crennelations.  That what you're talking about, or are you thinking of
bounding it at smaller segments than that?

Geoff

Post a reply to this message

Geoff Wedig wrote:
> 
> Well, sections are unioned together, so that should bound them somewhat.
> So, for example, the front tower is made up of the base unit, the upper
> unit, the outward sloping part of the crennelations and the wall part of the
> crennelations.  That what you're talking about, or are you thinking of
> bounding it at smaller segments than that?
> 

That surely already helps, but the more 'bounding levels' you have the
faster it gets.  I'm not sure how you build up the walls, but for example
horizontal slicing could work.  Then bound together two neighbored slices
and then put two of these blocks together and so on.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

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



> Geoff Wedig wrote:
>> 
>> Well, sections are unioned together, so that should bound them somewhat.
>> So, for example, the front tower is made up of the base unit, the upper
>> unit, the outward sloping part of the crennelations and the wall part of the
>> crennelations.  That what you're talking about, or are you thinking of
>> bounding it at smaller segments than that?
>> 

> That surely already helps, but the more 'bounding levels' you have the
> faster it gets.  I'm not sure how you build up the walls, but for example
> horizontal slicing could work.  Then bound together two neighbored slices
> and then put two of these blocks together and so on.  

Unfortunately, there are rarely horizontal lines that go completely around
(if ever.  The algorithm is such that it tries to break both horizontal and
vertical lines)  I can do *some* breaking up by 

A. Reducing the number of blocks generated that aren't actually visible. 
This has already been done somewhat.

B. Breaking things behind the scenes.  The two foremost towers on the left,
for example, could be broken behind the crennelations and no one could tell.

But honestly, the untextured isos are pretty quick.  It's only when you
combine my complex textures with radiosity and so on that things get bad.  I
need to do some optimizing.

Geoff

Post a reply to this message