[yt-dev] OpenGL VR

Matthew Turk matthewturk at gmail.com
Thu Mar 17 09:19:42 PDT 2016


Hi Cameron,

On Wed, Mar 16, 2016 at 2:51 PM, Cameron Hummels <chummels at gmail.com> wrote:
> I'm fully behind this going into the development branch and not languishing
> as a PR.  My only concern is that this is getting merged into dev just prior
> to a stable release, which means that it will go into the stable branch when
> we put out 3.3 imminently.  By all of the talk on the slack channel and on
> this mailing list, it seemed like the only major holdups to 3.3 release were
> software-VR related, and I thought those were almost complete, but perhaps
> I'm mistaken in this.

I think you're correct that the major holdups are software VR related,
but I believe almost all of them have been resolved, thanks to the
sprinters a few weeks back.

>
> And given that the OpenGL VR is explicitly listed as experimental seems to
> be at odds with a fully stable version release.  That's not to say that
> people won't use it--I thought a huge number of our users were using dev as
> opposed to stable releases, no?  I just thought that dev was where
> experimental functionality existed.  But again, I am just raising these
> concerns for discussion, and if there is general consensus that this new
> functionality should be included in a stable release, then I will not block
> it.

Here's the thing for me.  This *is* experimental, but it's also *super
cool*.  I don't know if you have tried it yet, but it's pretty awesome
(credit for that goes to Chuck, Kacper and Andrew.)  It is really
lightweight, and I think that it'll get folks excited.  Kacper's added
ways to make it work with the software VR, and it should be reasonably
feasible to start sharing code.  The overall surface area of the API
at present is really small, which means even if it's "experimental"
there aren't even a lot of changes that would be *possible* to make
that would break scripts.

But the main thing I want to communicate: this is not a fire and
forget project.  This is going to be an ongoing effort.  I think it's
going to get cooler and cooler, and I want to seed the excitement in
the community.  From another perspective, this is also a way to
increase the value proposition, and I think it will also open up a lot
of new contributors.  Suddenly, data becomes more tangible.

As far as stable/development goes, we're increasingly finding folks
using the conda channels.  In the conda channel there are nightly
builds, but most folks install the "stable" release.  And with the
policy of backporting bug fixes, even having this initially in the
stable release means it can continue to be supported with bugfixes
over time.  The code may still be "experimental" but the *idea* of
interactive visualization is not experimental.  I see it as an
*enormous* opportunity for us in a bunch of ways, and since this code
is a) documented b) really fun and c) completely isolated from the
rest of the codebase, I think it should be merged.

I have a great deal of sympathy for your reluctance to include things
in a release, but I am struggling to find the cost/benefit analysis of
this new going in that says it shouldn't.  At this point I don't think
including it does a disservice to the people downstream of us.  We've
established a principle for backporting changes, but we haven't ever
established a feature freeze (I think I suggested it once and it
didn't pan out, but maybe somebody else suggested it and I nixed it)
and I don't know that we even *can* without identifying a rigorous
release schedule (again).

It's not clear to me that I've addressed all of your concerns, but I
wanted to at least try to let you know more of where I'm coming from
on suggesting this go in before a release.  I think the risks of "what
will happen if this does go in" are outweighed by the
difficult-to-quantify risks of "what if it waits another 9 months to
go into a release?".

Thanks for your thoughtful comments on this, and I hope we can figure this out.

-Matt

>
>
> On Wed, Mar 16, 2016 at 12:37 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
>>
>> My understanding was that we'd decided it was okay to include it in
>> the development branch, since that's how things get experimented with.
>> I don't think this is an invasive change, and I think that the longer
>> it lives in a pull request that's in the development branch the longer
>> it won't get used and done.  We have put out a few major releases in
>> the last few years -- 3.0, in early August 2014, 3.1 in January 2015,
>> and 3.2 in September of 2015.  In between, the backporting has gone
>> really well, but I don't really want to wait eight months to get this
>> into a "release".
>>
>> Having an experimental API like this in a "released" version of yt
>> means people will hear about it, use it, contribute to it, and also
>> that they'll see it's experimental.  That's pretty clearly demarcated,
>> and having a simple high-level wrapper to it means lots of changes can
>> happen below the surface without breaking anything.
>>
>> I'm personally keen to have either comments that can be dealt with, or
>> to have this merged and iterated on.
>>
>> On Wed, Mar 16, 2016 at 1:04 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>> > I just want to say that the concerns I raised above haw all been
>> > addressed.
>> > I'm personally OK with including experimental features as long as
>> > they're
>> > clearly marked as such.
>> >
>> > I'm also not sure where Cameron is getting that the release will happen
>> > in a
>> > week or two. There hasn't been any discussion about when 3.3 will go
>> > out,
>> > and there are still several open issues.
>> >
>> >
>> > On Wednesday, March 16, 2016, Cameron Hummels <chummels at gmail.com>
>> > wrote:
>> >>
>> >> Hey Matt,
>> >>
>> >> The OpenGL VR looks like really cool functionality, and I think
>> >> potentially it should be merged into dev soon, but I am having some
>> >> hesitation about including it in the imminent stable release.  It was
>> >> always
>> >> my opinion that the Stable branch was for code/features that have been
>> >> in
>> >> the codebase for a while, have a stable API, and aren't actively being
>> >> modified or seen as experimental.  As far as I can tell, the OpenGL VR
>> >> has
>> >> been tested by a few developers and will have been in the dev branch
>> >> for
>> >> only a very short time (a week or two) before the release of stable
>> >> version
>> >> 3.3.  Should we really be pushing this feature to stable with the
>> >> caveat
>> >> that it is still experimental?  Doesn't this go against the very idea
>> >> of the
>> >> Stable branch?  Or should we leave it in dev until its experimental
>> >> phase
>> >> has passed?
>> >>
>> >> I understand that it would be nice to have software VR and hardware VR
>> >> both go out at the same time to stable, but it just seems like the
>> >> hardware
>> >> stuff is getting pushed out the door when very few people have used it
>> >> and
>> >> it's still seen as an experimental feature.
>> >>
>> >> Thoughts?
>> >>
>> >> Cameron
>> >>
>> >> On Wed, Mar 16, 2016 at 10:35 AM, Matthew Turk <matthewturk at gmail.com>
>> >> wrote:
>> >>>
>> >>> Hi folks,
>> >>>
>> >>> As of today, all of the tests pass, and I believe all the comments
>> >>> have been addressed.  At the time of the triage one of the style tests
>> >>> wasn't passing, but I would propose that it now be merged since that
>> >>> issue has since been remedied.
>> >>>
>> >>> Unless there are extremely strong objections (in addition to the
>> >>> objections raised here and in the PR) I think it should be merged.
>> >>> This is exciting!  I can't wait to see this in the wild.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Matt
>> >>>
>> >>> On Wed, Mar 9, 2016 at 12:22 PM, Matthew Turk <matthewturk at gmail.com>
>> >>> wrote:
>> >>> > On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum
>> >>> > <nathan12343 at gmail.com> wrote:
>> >>> >>
>> >>> >>
>> >>> >> On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk
>> >>> >> <matthewturk at gmail.com>
>> >>> >> wrote:
>> >>> >>>
>> >>> >>> On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2 at gmail.com>
>> >>> >>> wrote:
>> >>> >>> >> OK, sounds good.  I'll work on some docs as soon as possible,
>> >>> >>> >> and
>> >>> >>> >> hopefully if they get in we can be set up to accept it  before
>> >>> >>> >> any
>> >>> >>> >> 3.3
>> >>> >>> >> release.  Andrew, you're 3.3 manager, right?  What's the 3.3
>> >>> >>> >> timescale?
>> >>> >>> >
>> >>> >>> > There currently isn't a set time table, but I'd say it can be
>> >>> >>> > ready
>> >>> >>> > "soon."
>> >>> >>> > We knocked out a big chunk of the remaining VR issues last week.
>> >>> >>> > The
>> >>> >>> > only
>> >>> >>> > things that remain are 1) documenting and sanity checking the
>> >>> >>> > log /
>> >>> >>> > linear
>> >>> >>> > issue for Transfer functions, and 2) addressing the issues with
>> >>> >>> > the
>> >>> >>> > default
>> >>> >>> > alpha settings. I believe that all the other things we wanted to
>> >>> >>> > get
>> >>> >>> > done by
>> >>> >>> > 3.3 are in there.
>> >>> >>> >
>> >>> >>>
>> >>> >>> Sounds good.  I will get the docs done right away, by end of week;
>> >>> >>> are
>> >>> >>> there any code changes we should aim for in the OpenGL in
>> >>> >>> addition?
>> >>> >>>
>> >>> >>
>> >>> >> No idea how hard this would be, but maybe something that prints
>> >>> >> some
>> >>> >> help
>> >>> >> text to the screen?
>> >>> >
>> >>> > Great idea.  Also, I should have solicited these requests to be
>> >>> > added
>> >>> > to the PR in comments, as they'll be easier to manage there.
>> >>> >
>> >>> >>
>> >>> >> Right now you need to look at the source code to see the
>> >>> >> keybindings.
>> >>> >>
>> >>> >>>
>> >>> >>> >
>> >>> >>> > _______________________________________________
>> >>> >>> > 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
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Cameron Hummels
>> >> NSF Postdoctoral Fellow
>> >> Department of Astronomy
>> >> California Institute of Technology
>> >> 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
>
>
>
>
> --
> Cameron Hummels
> NSF Postdoctoral Fellow
> Department of Astronomy
> California Institute of Technology
> http://chummels.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