Am 21.01.2018 um 21:56 schrieb William F Pokorny:

> Is this the expected behavior for media_attenuation?

The documentation for the feature specifically mentions "fog or
atmospheric media" (as opposed to object-contained media), so I'd say,
yes, that's the intended behaviour. Other portions of that same docs
section refer to "the fog or media", but I'd take that to be just a lazy
reference to the more precise term used earlier.

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:

>
> This is an interesting/important find indeed! My image 'Cat Alley'
> above, takes about 6 hours to render as you can expect. Like you, I
> always assumed media to severely slow down a render no matter what. I
> need to play with this a bit now. Thanks!
>

Same here; I never noticed this behavior before. I need to play with Bill's
example code.

Post a reply to this message

Question: The Docs are silent about this, but do fade_distance and 
fade_power have to be added to the light source or not, in order for the 
media attenuation to work?

http://wiki.povray.org/content/Reference:Light_Source#Atmospheric_Attenuation

-- 
Thomas

Post a reply to this message

On 01/22/2018 05:21 AM, clipka wrote:
> Am 21.01.2018 um 21:56 schrieb William F Pokorny:
> 
>> Is this the expected behavior for media_attenuation?
> 
> The documentation for the feature specifically mentions "fog or
> atmospheric media" (as opposed to object-contained media), so I'd say,
> yes, that's the intended behaviour. Other portions of that same docs
> section refer to "the fog or media", but I'd take that to be just a lazy
> reference to the more precise term used earlier.
> 

Thanks.

Does our documentation then push the use of the media container too much 
if using scattering media?

It looks to me like it's probably not the right thing to do if a user 
doesn't need/want media attenuation. Global media in my testing is quite 
a bit faster than any container with scattering media - except those 
where the light is inside the container.

--- media_attenuation on
1541.79user 0.67system 12:56.48elapsed (global media. outside postion)
                                        (Media Samples: 4,295,692,846)

--- media_attenuation off
403.22user 0.04system 3:22.24elapsed  (container. outside postion)
404.69user 0.05system 3:22.99elapsed  (Media Samples: 1,064,722,061)

32.04user 0.01system 0:16.67elapsed  (global media. outside postion)
32.10user 0.01system 0:16.67elapsed  (Media Samples: 58,877,772)

8.71user 0.01system 0:05.00elapsed  (container. inside postion)
8.63user 0.01system 0:04.94elapsed  (Media Samples: 11,828,518)


While I'm happy to know I can contort my media containers to contain the 
light for really fast scattering media renders, I do wonder a little why 
media attenuation is always off in that case.

Instead of contorting the container shape, would a media {} block 
'media_attenuation off' capability could be useful for those wanting to 
use scattering media and attenuation for final renders, but wanting fast 
working renders?

While you can sort of fake a media initially at much better performance 
using emitting media over scattering, you don't get a very good feel for 
the final scattering look of any given media-density that way.

Bill P.

Post a reply to this message

On 01/23/2018 03:32 AM, Thomas de Groot wrote:
> Question: The Docs are silent about this, but do fade_distance and 
> fade_power have to be added to the light source or not, in order for the 
> media attenuation to work?
> 
> http://wiki.povray.org/content/Reference:Light_Source#Atmospheric_Attenuation 
> 
> 
By experimentation just now it looks like no. If you have a fade power / 
fade_distance it will of course affect media results apart from or in 
addition to any media_attenuation.

Aside: In running these recent tests I wanted the media on black so I 
could better see any attenuation in addition to noting the run time 
changes when media_attenuation is on. I forgot global media needs a 
terminating shape on which the ray stops & my media disappeared causing 
me a spot of confusion until I thought to put the background box back 
into the scene but colored black.

Bill P.

Post a reply to this message

Am 23.01.2018 um 16:57 schrieb William F Pokorny:

> Instead of contorting the container shape, would a media {} block
> 'media_attenuation off' capability could be useful for those wanting to
> use scattering media and attenuation for final renders, but wanting fast
> working renders?

I'd say yes, that would be quite useful indeed.

(And maybe also `media_attenuation on` for light sources inside the
media container.)

Post a reply to this message

On 01/23/2018 03:28 PM, clipka wrote:
> Am 23.01.2018 um 16:57 schrieb William F Pokorny:
> 
>> Instead of contorting the container shape, would a media {} block
>> 'media_attenuation off' capability could be useful for those wanting to
>> use scattering media and attenuation for final renders, but wanting fast
>> working renders?
> 
> I'd say yes, that would be quite useful indeed.
> 
> (And maybe also `media_attenuation on` for light sources inside the
> media container.)
> 
Ah yes! A good idea to be able to turn attenuation on inside too if 
possible. Thanks. I've no experience with the media code, but will take 
a look to see if I can figure something out as a start.

Bill P.

Post a reply to this message

On 01/23/2018 03:28 PM, clipka wrote:
> Am 23.01.2018 um 16:57 schrieb William F Pokorny:
> 
...
> I'd say yes, that would be quite useful indeed.
> 
> (And maybe also `media_attenuation on` for light sources inside the
> media container.)
> 

I have been weeks now on and off digging into media and media code. It 
turns out there are scenes - abyss.pov for example - where the 
light_source IS inside the media container. We get no attenuation no 
matter other settings in those cases and often a washed out visual 
result. I'm starting to wonder if this lack of attenuation is behind the 
struggles with contrast in some media scenes.

Anyway, I want to immediately let folks know there is a way to get 
media_attenuation on in cases where your light source(s) are inside your 
media container. If you set up a difference creating either a small void 
or small divot around your light source(s) - presto media_attenuation is 
on.

It's an obvious idea since for lights outside the media container in my 
original posting the attenuation is always on. Of course, the small void 
idea didn't work when I first tried it...

Turns out in the global - the post transforms - scene coordinate space, 
the distance from the light outside to surface of the media container 
must be >= 0.001. This value appears to come from '#define 
SHADOW_TOLERANCE 1.0e-3' value being used in trace.cpp, but I've not 
spent time hacking at that code to be 100% sure.

Getting the lights outside the container >= 0.001 for attenuation works 
all the way back to 3.6.1 in my testing.

Bill P.

Post a reply to this message

Le 18-02-11 à 09:47, William F Pokorny a écrit :
> On 01/23/2018 03:28 PM, clipka wrote:
>> Am 23.01.2018 um 16:57 schrieb William F Pokorny:
>>
> ...
>> I'd say yes, that would be quite useful indeed.
>>
>> (And maybe also `media_attenuation on` for light sources inside the
>> media container.)
>>
> 
> I have been weeks now on and off digging into media and media code. It 
> turns out there are scenes - abyss.pov for example - where the 
> light_source IS inside the media container. We get no attenuation no 
> matter other settings in those cases and often a washed out visual 
> result. I'm starting to wonder if this lack of attenuation is behind the 
> struggles with contrast in some media scenes.
> 
> Anyway, I want to immediately let folks know there is a way to get 
> media_attenuation on in cases where your light source(s) are inside your 
> media container. If you set up a difference creating either a small void 
> or small divot around your light source(s) - presto media_attenuation is 
> on.
> 
> It's an obvious idea since for lights outside the media container in my 
> original posting the attenuation is always on. Of course, the small void 
> idea didn't work when I first tried it...
> 
> Turns out in the global - the post transforms - scene coordinate space, 
> the distance from the light outside to surface of the media container 
> must be >= 0.001. This value appears to come from '#define 
> SHADOW_TOLERANCE 1.0e-3' value being used in trace.cpp, but I've not 
> spent time hacking at that code to be 100% sure.
> 
> Getting the lights outside the container >= 0.001 for attenuation works 
> all the way back to 3.6.1 in my testing.
> 
> Bill P.
> 

So, we should add :
looks_like{sphere{0, 0.001 pigment{rgbt 1}}}
to the lights that are inside some media container.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

>
> So, we should add :
> looks_like{sphere{0, 0.001 pigment{rgbt 1}}}
> to the lights that are inside some media container.

I just tried that, and it doesn't work, unfortunately. (And the placement of the
looks_like(..) entry in the light code doesn't fix it either, relative to the
light's translation statement; I thought it might, but no luck.)

Apparently, Bill's successful trick needs an actual CGS difference of a tiny
object from the media container; then media_attenuation comes back on (as if the
light was again outside the media.) Very nice! By the way, here's an interesting
little detail about that small void. My media object code looks like this:

difference{
sphere{0,1}
sphere{0, .005 translate <-.2, 0, .9>} // translation same as light's position
hollow on
.....

The hollow keyword applies to BOTH objects AFAIK-- meaning both objects will
'contain' media. Yet the CSG-difference trick works anyway-- even though the
light is again 'inside a media container' rather than outside it. I don't know
what to make of that, re: a required media-free(?) void , but it's interesting.

My tests so far have been with object media, and with the camera outside the
object. I haven't yet tested atmospheric media. Or a situation where the camera
is *inside* the media object.

Post a reply to this message