"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> "clipka" <nomail@nomail> wrote:
> > Um... yeah, if aside from area lights and radiosity you also did use isosurfaces
> > and media, then I'll keep my cake-hole shut :X
>
> The isosurface isn't obvious (although probably more needed than in the other
> image), but I would expect you to spot the media in the subsurface scattering
> on those gems... :-D

Now that you mention it...

.... honestly I still don't :}

Maybe it's one of those subtle things you only notice when it's missing, like in
"I can't really tell why, but the material doesn't look convincing to me"; and
maybe the 2000x2000 shot reveals it more clearly.

Anyway, I take that as a hint to get back into gear for further integration of
the experimental SSLT code :P

Post a reply to this message

Bill Pragnell wrote:
> "clipka" <nomail@nomail> wrote:
>> "Bill Pragnell" <bil### [at] hotmailcom> wrote:
>>> (took 140 hours to render at 2000x2000 - eek!)
>> Sounds to me like a case of "ur doin' it wrong": I see nothing in that shot that
>> would justify such a long render time.
> 
> Yes, it's entirely possible.

  I'm pretty certain that if instead of an isosurface you used a plane
with the proper normal block, you would get an almost identical image in
1/10th of the rendering time, if not even faster.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   I'm pretty certain that if instead of an isosurface you used a plane
> with the proper normal block, you would get an almost identical image in
> 1/10th of the rendering time, if not even faster.

I still think the media and aa are bigger culprits, but I agree it would be
faster. However, I'd have to use normal on in the radiosity block if I wanted
the shape of the floor visible in the shadowed areas, and that might well knock
the render time back again. I'll try it next time I make one of these images.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Bill Pragnell" <bil### [at] hotmailcom> wrote:
> > The isosurface isn't obvious (although probably more needed than in the other
> > image), but I would expect you to spot the media in the subsurface scattering
> > on those gems... :-D
>
> Now that you mention it...
>
> .... honestly I still don't :}

What! </mock outrage> :)

> Maybe it's one of those subtle things you only notice when it's missing, like in
> "I can't really tell why, but the material doesn't look convincing to me"; and
> maybe the 2000x2000 shot reveals it more clearly.

This is all true - it *is* intended to be subtle (as a rock sss effect would
be), and it *is* clearer in the larger version. It is definitely visible in
this version though: look at the edges of shadowed areas in the lower (closer)
half of the image. The sharp red one (no 12 from the centre) shows it most
dramatically, as well as the vivid green ones directly <-1,-1> from the centre.

> Anyway, I take that as a hint to get back into gear for further integration of
> the experimental SSLT code :P

Yes, why not? ;-)

Post a reply to this message

Bill Pragnell wrote:
> However, I'd have to use normal on in the radiosity block if I wanted
> the shape of the floor visible in the shadowed areas, and that might well knock
> the render time back again. I'll try it next time I make one of these images.

  It would still be radiosity-rays-against-isosurface vs.
radiosity-rays-against-plane, even with when the radiosity rays take
into account the normal perturbation.

  OTOH, if you don't have anything for a "sky", I don't think making the
radiosity take into account normal perturbation would make any
difference with a plane. There's nothing to reflect light onto the plane.

  One possible idea to speed up this kind of scene is to ditch the
radiosity completely. It often doesn't contribute significantly in this
type of scene, and if necessary can be substituted with secondary light
sources (which might in fact produce even better lighting; eg. see
http://warp.povusers.org/povtips/ )

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> I still think the media and aa are bigger culprits, but I agree it would be
> faster. However, I'd have to use normal on in the radiosity block if I wanted
> the shape of the floor visible in the shadowed areas, and that might well knock
> the render time back again. I'll try it next time I make one of these images.

Consider this:

"normals on" in a radiosity block causes radiosity to take fake surface normal
variations into accunt, thereby increasing the number of samples required...

.... as compared to a perfectly flat surface. If you generate the same variations
in surface normals via true geometry, you get the same increase in required
number of samples. *Plus* the general ray-object intersection testing slowdown
from using isosurfaces.

The isosurface may turn out to be superior though, because of its ability to
self-shadow at the perimeter where the angle between light source and surface
is very shallow.

Post a reply to this message

"Bill Pragnell" <bil### [at] hotmailcom> wrote:
> This is all true - it *is* intended to be subtle (as a rock sss effect would
> be), and it *is* clearer in the larger version. It is definitely visible in
> this version though: look at the edges of shadowed areas in the lower (closer)
> half of the image. The sharp red one (no 12 from the centre) shows it most
> dramatically, as well as the vivid green ones directly <-1,-1> from the centre.

Now I *do* see it, too.

(Yeah, I have seen the light! :P)

Post a reply to this message

clipka wrote:
> "normals on" in a radiosity block causes radiosity to take fake surface normal
> variations into accunt, thereby increasing the number of samples required...

  Are you sure that radiosity taking into account normal perturbation
requires additional sampling? Why would it?

  (Or do you mean that normal perturbation may create more changes in
the lighting, in which case the error_bound is triggered more easily,
resulting in more sampling?)

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Are you sure that radiosity taking into account normal perturbation
> requires additional sampling? Why would it?

Yes, I'm positively sure. I actually did a bit of work on the code, you know :P

The surface normal vector affects radiosity in multiple ways:

(1) It defines the hemisphere from which indirect illumination is sampled at
all.

(2) It defines the direction from which indirect illumination has the strongest
effect. (Indirect illumination is cosine-weighted with respect to the angle of
incidence.)

(3) The deviation in the surface normal vector is one of the key criteria for
the "reusability" of an existing samples for a certain surface point.

(4) Surface normal vectors of other objects may affect the actual sample values.


Specifying "radiosity { normal on }" tells POV-Ray to work with the fake surface
normal for the sake of all (1) through (3).

(3) is the one that causes a higher sample density, because even on a plane the
samples' surface normals now don't always match.


>   (Or do you mean that normal perturbation may create more changes in
> the lighting, in which case the error_bound is triggered more easily,
> resulting in more sampling?)

I guess you're referring to (4) here. Ironically, neither of your assumptions
here is true: (a) fake normals are *always* taken into account in this respect,
regardless of the "normal" setting (maybe there is some potential for speedup
here); and (b) actual changes in the lighting do *not* affect the sample
density; instead, sampling is controlled by an *estimate* of *potential*
lighting changes, derived solely from geometric properties.

Post a reply to this message

This is a very beautiful scene. My congratulations!

Sven

Post a reply to this message