[yt-dev] GridsSource in vr refactor

Matthew Turk matthewturk at gmail.com
Sun Jun 7 07:50:25 PDT 2015


Hi Sam,

Thanks very much for your detailed response.  I think this is all
really useful information, and I'm going to try to incorporate it into
the docs.

For now, what I've done is match how the coordinate vector rendering
source works in the GridsSource, which is to scale up to alpha in the
colormap -- I experimented with a second scaling parameter, but
decided that this was probably not worth it, since the alpha is the
right value we'd want to use anyway.  I've gone ahead and tossed this
change in my open PR to your repo.

The result now is something I'm way more comfortable with, and I'm
going to make comments about it in the script as I keep writing it.

Thanks for your help and thoughts!

-Matt

On Sat, Jun 6, 2015 at 10:23 PM, Sam Skillman <samskillman at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>



More information about the yt-dev mailing list