[yt-dev] GridsSource in vr refactor

[Sam Skillman]

Those belong in the #bugsareawesome album.

I think you're right on with the color *= alpha.  So here's the real crux
of the problem in my mind. With a VolumeSource you are generally in one of
two regimes:
A) The max accumulated intensity is << 1, and you're "optically thin", and
likely have (usually) grey_opacity=False
B) The max intensity is ~1, you're "optically thick" and likely have
(usually?) grey_opacity=True

If you are in A, then Z-ordering the blended grid lines doesn't mean
anything since everything is optically thin anyways. In this case the easy
way to avoid guess and check is to set alpha equal to
~0.3*(mean/max/median) of the image. Note this is done *after* the
rendering.

If in case B, then setting alpha=0.3 will generally result in something
decent since the volume source is relatively bright itself. To get the
blending correct, the alpha of the grid lines has to be set before the
volume rendering.

The problem comes when you are operating in case A and end up being opaque,
or case B and end up being translucent/optically thin. The only robust
solution, I think, is to do a two-pass to render the volume source, get a
max intensity, then render again with grids at some fraction of the
(mean/max/median) of the final image for the alpha of the grids.  An
alternative might be to  bump up the brightness in all the add_layers
functions, or provide some sort of normalization so that the area under the
transfer function curve is equal to 1. I think part of this might come from
that value being << 1 for default TF modifications.

Hope that core dump helps...
Sam

On Sat, Jun 6, 2015 at 8:11 PM Matthew Turk <matthewturk at gmail.com> wrote:

> Hey Sam,
>
> It certainly changed something!
>
> http://i.imgur.com/OvBGsEo.png
>
> I did find one interesting thing.  I backed out the grey_opacity
> argument and then changed the code for the GridsSource to include:
>
> colors[:, 3] = alpha
> colors[:, :3] *= alpha
>
> Now with alpha = 0.0001 I get:
>
> http://i.imgur.com/kSS4c9y.png
>
> What this suggests to me, which might be wrong, is that the absolute
> color values are saturating way past all the other color values.  By
> cutting those down, I'm getting grid lines that don't overpower the
> image normalization.  Does that make sense?
>
> I guess now the question is, how do we implement that without the
> finicky process of "guess and check" I went through.  Any ideas?
>
> -Matt
>
> On Sat, Jun 6, 2015 at 7:56 PM, Sam Skillman <samskillman at gmail.com>
> wrote:
> > Hey Matt, can you try specifying grey_opacity=True in your custom
> > ColorTransferFunction? I don't have any test data at this particular
> moment
> > but I think that might be the culprit...
> >
> > On Fri, Jun 5, 2015 at 3:04 PM Matthew Turk <matthewturk at gmail.com>
> wrote:
> >>
> >> Thanks -- I will check it out.  Rotation seems to destroy a bunch of
> >> stuff too, which looks to me more like an issue with the ray
> >> traversal.
> >>
> >> http://i.imgur.com/qMazCaK.png
> >>
> >> On Fri, Jun 5, 2015 at 5:00 PM, Cameron Hummels <chummels at gmail.com>
> >> wrote:
> >> > It's probably just a problem in the z scale, which caused some issues
> in
> >> > the
> >> > initial overlay of points as well.
> >> >
> >> > You could pdb into it and see what the z values the grid vertices
> have.
> >> > I
> >> > think they go from inf in the back to 0 in the front, but I'd have to
> >> > check.
> >> >
> >> > On Fri, Jun 5, 2015 at 2:50 PM, Matthew Turk <matthewturk at gmail.com>
> >> > wrote:
> >> >>
> >> >> Hi all,
> >> >>
> >> >> Anybody here know why with the scene refactor, no matter how low I
> set
> >> >> the opacity of the grids, they (villainously) blot out the sun?
> >> >> Here's a script:
> >> >>
> >> >> http://paste.yt-project.org/show/5608/
> >> >>
> >> >> Here's the output of new_tf_clip.png:
> >> >>
> >> >> http://i.imgur.com/ZRTz4kR.png
> >> >>
> >> >> and now, what the script calls grids_overlay.png:
> >> >>
> >> >> http://i.imgur.com/fPvVDdP.png
> >> >>
> >> >> I mean, I *must* be missing something, right?
> >> >>
> >> >> -Matt
> >> >> _______________________________________________
> >> >> yt-dev mailing list
> >> >> yt-dev at lists.spacepope.org
> >> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Cameron Hummels
> >> > Postdoctoral Researcher
> >> > Steward Observatory
> >> > University of Arizona
> >> > http://chummels.org
> >> >
> >> > _______________________________________________
> >> > yt-dev mailing list
> >> > yt-dev at lists.spacepope.org
> >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >> >
> >> _______________________________________________
> >> yt-dev mailing list
> >> yt-dev at lists.spacepope.org
> >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> >
> > _______________________________________________
> > yt-dev mailing list
> > yt-dev at lists.spacepope.org
> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
> >
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150607/56c07f83/attachment.html>