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.
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'
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
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,
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:
(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