Fresh from the tome of POV-Ray Voodoo:

Beware when mixing media with complex textures using texture_map: It will slow
down rendering in an unexpected fashion!

I just found in the POV 3.7 code that media is computed *per component* in such
a case; so if for instance you try to average three textures using the "average
texture_map" construct, it will result in media effects being computed *thrice*
for any ray travelling towards that surface.

(Layered textures are safe in this respect, and so are all patterns that
strictly choose between one of multiple textures, like checker or hexagonal.)

Don't know if it has already been this way in 3.6, but in any case this asks for
a change...

Post a reply to this message

clipka wrote:
> Fresh from the tome of POV-Ray Voodoo:
> 
> Beware when mixing media with complex textures using texture_map: It will slow

> Don't know if it has already been this way in 3.6, but in any case this asks for
> a change...

Oh, the media code asks for a lot of changes. There were some in there early 
on, but due to the complexity of the expected side effects, we had to take 
them out again as they did tend to break all but the most trivial media. 
Some pieces of that code made my head want to separate from my body so it 
would no longer have to sit in front of the screen with the rest of me. The 
code is really "interesting"...

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Oh, the media code asks for a lot of changes. There were some in there early
> on, but due to the complexity of the expected side effects, we had to take
> them out again as they did tend to break all but the most trivial media.
> Some pieces of that code made my head want to separate from my body so it
> would no longer have to sit in front of the screen with the rest of me. The
> code is really "interesting"...

Ah... okay... then I guess the next beta (in case it features change #4845)
should be tested thoroughly, with a keen eye on media issues. I'm rather sure I
didn't break anything, but your comment makes me a bit uneasy...

Post a reply to this message

clipka <nomail@nomail> wrote:
> Don't know if it has already been this way in 3.6, but in any case this asks for
> a change...

  The fact that averaged textures send rays for each of the textures is
"abused" for the blurred reflection trick.

  If the way averaged textures are handled is changed, this should be taken
into account. It would be a bummer to lose such a useful side-effect.
(Maybe send a ray-per-texture only for reflected rays but not refracted
ones...)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   The fact that averaged textures send rays for each of the textures is
> "abused" for the blurred reflection trick.

I'm not talking about the number of media tests on *reflected* rays (or
refracted rays, for that matter).

I'm talking about the media between the *observer* and the (complex) texture in
question. It's even *there* that media is computed multiple times.

Pray tell, that doesn't sound like it's needed for blurred reflections (or
anything else), or am I missing something here?


Imagine this: You're rendering a shot with both scattering media and blurred
reflection, achieved by averaging, say, 50 differently-pertubed textures.

That means media will be computed *50* times over for the space in between the
camera and the blurred mirror. (Not to speak of the 2500 times for the space in
between that blurred mirror and any other blurred mirror...)

Yuck. If scattering media spells "sloow", with how many "o" does *this* spell!

Changing this, to do media computations only after having computed the true,
real, full, all-encompassing effective texture of an object, blurred-reflection
users will be among those on the winner side for sure.

Post a reply to this message