On 12/3/19 12:07 PM, jr wrote:
> 
...
>>
>> Anyway, very likely more than a month before I'd have the time to look
>> at this in any depth.
> 
> also no problem (for me).  out of interest, what advantages does your fork have
> wrt media artefacts, media in general?
> 
...
> 

:-) Simple question with a non-simple answer...

I've never published a merged branch of all the branches I run as 'povr' 
- partly because what I run contains more branches / differences to 
master than those I've published to github. Also 'povr' is meant to be a 
temporal thing based on the current master branch into which continually 
re-based to master branches are merged.

That said, my published solver branch addresses many artifacts media and 
otherwise - and extends the range over which containers work for media. 
This work though is limited to shapes using the common solvers.

There is a published branch addressing the photon media deposit banding. 
I assume that was some debugging left in as I see no reason to introduce 
banding except to get some visual feedback of the sampling periodicity 
while developing code.

There is a published branch for one version of a change published for 
jitter and adaptive media 3 which helps scene-performance up to 5%, if 
your scene is media dominated and you're not using media jitter - and 
one shouldn't with media method 3 unless they want noise.

Non-published branches...

I have another version of the media 3 jitter changes which is faster 
still, but it's also more intrusive code wise and so more difficult to 
re-base. I didn't use/re-base this branch in my last create a 'povr' 
pass.

Suppose some of the recent pattern and wave modifier work touches media 
too and issues fixed more likely to show up with media given the 
containing shapes like isosurfaces, but also the sampling periodicity is 
more likely to numerically land badly. With that last though, the 
sampling, if set deep enough, probably mostly hides any wave modifier 
issues.

Aside: At one time I naively thought there was an issue or two with 
media, but a year plus back mentally carrying 8-10 media media artifact 
causes. It's a bunch of stuff - and media turns out to be a great way to 
test for underlying problems! Though, if you asked me in this moment to 
list them all, I'd be hard pressed to do it. Not worked specifically on 
media in a while. For me, newer work tends to push the old out of my 
head - given the lack of space, the near continual wind storm and 
general clutter up there... :-)

Oh, I never got to testing code, but I started a local branch supporting 
a second emission specific media absorption specification/control. In a 
scene Norbert posted a year or more back based on Gilles Tran's cloud 
technique using scattering, emission and absorption together with media 
there was color clipping due how the emission was cleverly used and this 
demonstrated that media emission needs it's own media, 
emission-absorption control(1).

Lastly, something not fixed in any code of which I'm aware - I tried and 
failed for a fix. One needs to be sure light sources are outside any 
media container, if you want all the media related controls/attenuation 
to best work(2). True even if you have to cut a small void in the media 
container around your lights to get this set up. See:

http://news.povray.org/povray.binaries.images/thread/%3C5a842989%241%40news.povray.org%3E/

Bill P.

(1) Or - maybe - should always internally absorb at a color matching the 
emission color. This, I think, would align OK with physical behavior for 
florescent media, but it would be more limiting and it would change the 
look of current scenes with emissive media.

(2) I've since stumbled across a post from back in the 2000s where 
someone else (Bruno Cabasson?) had discovered this issue too suggesting 
the same work-around. IIRC even with the workaround we are left not 
being able to turn media attenuation off in containers.

Post a reply to this message