Hi folks, Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then: https://www.youtube.com/watch?v=yiiBDK1OJDo As of right now, it can do these things: * Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object. The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.) Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out. https://bitbucket.org/yt_analysis/yt/pull-requests/1598 Note that this requires cyglfw3, which is accessible via pip. I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc. I'd really like to see this be a part of 3.3. -Matt
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Does this have a similar API / interface to the standard VR? On Thu, Feb 25, 2016 at 9:45 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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
Right now it's somewhat different. There's a cookbook recipe in the pull request you can look at to get an idea of how to set it up. In principle the details could be wrapped up to make the user-facing API more similar. On Tuesday, March 1, 2016, Cameron Hummels <chummels@gmail.com> wrote:
Does this have a similar API / interface to the standard VR?
On Thu, Feb 25, 2016 at 9:45 AM, Nathan Goldbaum <nathan12343@gmail.com <javascript:_e(%7B%7D,'cvml','nathan12343@gmail.com');>> wrote:
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com <javascript:_e(%7B%7D,'cvml','matthewturk@gmail.com');>> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org <javascript:_e(%7B%7D,'cvml','yt-dev@lists.spacepope.org');> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org <javascript:_e(%7B%7D,'cvml','yt-dev@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
I think we should aim to have the VR interface and the OpenGL VR interface as similar as possible. Otherwise, it is likely that users, both new and old, will get pretty confused when jumping back and forth between two pieces of code that offer similar functionality. On Tue, Mar 1, 2016 at 6:43 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Right now it's somewhat different. There's a cookbook recipe in the pull request you can look at to get an idea of how to set it up.
In principle the details could be wrapped up to make the user-facing API more similar.
On Tuesday, March 1, 2016, Cameron Hummels <chummels@gmail.com> wrote:
Does this have a similar API / interface to the standard VR?
On Thu, Feb 25, 2016 at 9:45 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@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
If you can make the new VR work with particle date like Gadget data I would be happy. :) On Tue, Mar 1, 2016 at 7:49 AM, Cameron Hummels <chummels@gmail.com> wrote:
I think we should aim to have the VR interface and the OpenGL VR interface as similar as possible. Otherwise, it is likely that users, both new and old, will get pretty confused when jumping back and forth between two pieces of code that offer similar functionality.
On Tue, Mar 1, 2016 at 6:43 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Right now it's somewhat different. There's a cookbook recipe in the pull request you can look at to get an idea of how to set it up.
In principle the details could be wrapped up to make the user-facing API more similar.
On Tuesday, March 1, 2016, Cameron Hummels <chummels@gmail.com> wrote:
Does this have a similar API / interface to the standard VR?
On Thu, Feb 25, 2016 at 9:45 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- ------------------------------------------------------------------------ Joseph Smidt <josephsmidt@gmail.com> Theoretical Division P.O. Box 1663, Mail Stop B283 Los Alamos, NM 87545 Office: 505-665-9752 Fax: 505-667-1931
Hi Cameron, On 03/01/2016 08:40 AM, Cameron Hummels wrote:
Does this have a similar API / interface to the standard VR?
You can recreate image that you're seeing in software renderer. There's a helper for that (well stub for a helper...). Therefore, it could be used as a tool to quickly identify key frames and pass them to sw VR to make full HD movie. We are also working on native support for TransferFunction, but it requires more work. If you'd like to help with that, that'd be awesome. However, similarities end here. GPU VR needs to care about things like mouse movement, key callbacks, OpenGL context, OpenGL shaders. By definition it will create different API / interface. Cheers, Kacper
On Thu, Feb 25, 2016 at 9:45 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi all, It came up in the PR discussion today that we didn't settle in this thread on whether the new openGL vr should be included in the yt 3.3 release. I'd like to raise that now. First, I want to say that I think that the PR is really awesome and adds a really nice new feature to yt - one that it would be very nice to include in the 3.3 release. That said I'm nervous about including it as it currently stands due to the relative lack of documentation. Right now the documentation consists of cookbook recipes that aren't linked in the documentation, which means users won't be able to see them unless they clone the repository. I understand the desire to not add documentation until the API is less experimental, but I'm nervous about adding a big chunk of new code with little documentation. In addition, if we *do* want to advertise this functionality to people, then I think the path of highest empathy for those people is to provide them with some documentation. We could easily warn them in the documentation that the API is unstable, but at least they'll have a place to look. In addition, that it will be less work in the future to update the docs if the API ever does change rather than creating docs entirely from scratch. I think just a bit more documentation, and making sure that the documentation is visible in the docs build along with warnings about the experimental API would be enough for me to withdraw my reservations. -Nathan On Tue, Mar 1, 2016 at 9:00 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
Hi Cameron,
On 03/01/2016 08:40 AM, Cameron Hummels wrote:
Does this have a similar API / interface to the standard VR?
You can recreate image that you're seeing in software renderer. There's a helper for that (well stub for a helper...). Therefore, it could be used as a tool to quickly identify key frames and pass them to sw VR to make full HD movie. We are also working on native support for TransferFunction, but it requires more work. If you'd like to help with that, that'd be awesome.
However, similarities end here. GPU VR needs to care about things like mouse movement, key callbacks, OpenGL context, OpenGL shaders. By definition it will create different API / interface.
Cheers, Kacper
On Thu, Feb 25, 2016 at 9:45 AM, Nathan Goldbaum <nathan12343@gmail.com>
wrote:
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hi Nathan, On Wed, Mar 9, 2016 at 11:51 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
Hi all,
It came up in the PR discussion today that we didn't settle in this thread on whether the new openGL vr should be included in the yt 3.3 release. I'd like to raise that now.
First, I want to say that I think that the PR is really awesome and adds a really nice new feature to yt - one that it would be very nice to include in the 3.3 release.
That said I'm nervous about including it as it currently stands due to the relative lack of documentation. Right now the documentation consists of cookbook recipes that aren't linked in the documentation, which means users won't be able to see them unless they clone the repository.
Yup, those need to be linked.
I understand the desire to not add documentation until the API is less experimental, but I'm nervous about adding a big chunk of new code with little documentation.
In addition, if we *do* want to advertise this functionality to people, then I think the path of highest empathy for those people is to provide them with some documentation. We could easily warn them in the documentation that the API is unstable, but at least they'll have a place to look. In addition, that it will be less work in the future to update the docs if the API ever does change rather than creating docs entirely from scratch.
I think just a bit more documentation, and making sure that the documentation is visible in the docs build along with warnings about the experimental API would be enough for me to withdraw my reservations.
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?
-Nathan
On Tue, Mar 1, 2016 at 9:00 AM, Kacper Kowalik <xarthisius.kk@gmail.com> wrote:
Hi Cameron,
On 03/01/2016 08:40 AM, Cameron Hummels wrote:
Does this have a similar API / interface to the standard VR?
You can recreate image that you're seeing in software renderer. There's a helper for that (well stub for a helper...). Therefore, it could be used as a tool to quickly identify key frames and pass them to sw VR to make full HD movie. We are also working on native support for TransferFunction, but it requires more work. If you'd like to help with that, that'd be awesome.
However, similarities end here. GPU VR needs to care about things like mouse movement, key callbacks, OpenGL context, OpenGL shaders. By definition it will create different API / interface.
Cheers, Kacper
On Thu, Feb 25, 2016 at 9:45 AM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi folks,
Over the last little while, Kacper, Andrew and I have been picking up on some work started by Chuck Rozhon to implement OpenGL-based volume rendering of AMR data. Kacper recorded a demo about a week ago, although it has improved considerably even since then:
https://www.youtube.com/watch?v=yiiBDK1OJDo
As of right now, it can do these things:
* Load up a "data source" (which can be all_data, but doesn't need to be) * Utilize orthographic and perspective cameras * Maximum intensity projection * Integrated projection * Apply colormaps to these two things, using two-pass rendering * Trackball camera with keyboard shortcuts for moving around the domain * Output camera information that is compatible with the software renderer (i.e., it can be used to get a sequence of camera positions) * Save images out * Preliminary support for color transfer function-based VR. At present this only supports isosurfaces that are manually encoded. It will soon take 1D textures from the CTF object.
The system has been designed to be very modular, with extensible keyboard and mouse shortcuts. Kacper has even been able to build a very lightweight Qt-based GUI around it (on BB as xarthisius/reason ) without changing much/any of the internal-to-yt code. Also, it works reasonably well even on fairly old graphics cards for reasonably sized data. (And since it'll accept data objects that are cutouts, this means you could pull a sphere or block out of a gigantic dataset and use that.)
Anyway, the reason I'm writing is that I'd like to bring it to people's attention sooner rather than later. It'll need some testing, and we're also working to make it in a readily usable state as well. As of right now, before WIP gets removed from the pull request, we're going to add documentation (with notes that it is likely an unstable API) and hopefully a short screencast. But before then, I would like to invite folks to either review the PR or to test it out.
https://bitbucket.org/yt_analysis/yt/pull-requests/1598
Note that this requires cyglfw3, which is accessible via pip.
Also needs glfw3, which I installed via homebrew.
I'm pretty excited about this, and the design we have been aiming for with the way it accepts objects and shaders should enable a lot of cool things to be done -- especially with respect to selecting data, presenting it, etc etc.
I'd really like to see this be a part of 3.3.
-Matt _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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.
I agree with Nathan on this. The functionality looks cool, but I think without docs it is a non starter for going into stable. Just because an API is not finalized doesn't mean we cannot provide documentation to people on how to use it as it currently stands, and furthermore it will make things easier in the future since updating docs are easier than creating them from scratch. Even if the code doesn't go into stable this time around, it will still be available in dev, which seems appropriate since it is still under development with an API still changing. As for 3.3 release, I really want to get my existing PR into the code before stable gets released so that a stable release of yt works completely with trident. I'll finish it up this week. Cameron On Wed, Mar 9, 2016 at 10:06 AM, Andrew Myers <atmyers2@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.
_______________________________________________ yt-dev mailing list yt-dev@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
On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@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?
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk <matthewturk@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 /
On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@gmail.com> wrote: 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? Right now you need to look at the source code to see the keybindings.
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk <matthewturk@gmail.com>
wrote:
On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@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
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@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@gmail.com <javascript:_e(%7B%7D,'cvml','matthewturk@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@gmail.com <javascript:_e(%7B%7D,'cvml','matthewturk@gmail.com');>> wrote:
On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum <nathan12343@gmail.com <javascript:_e(%7B%7D,'cvml','nathan12343@gmail.com');>> wrote:
On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk <matthewturk@gmail.com
<javascript:_e(%7B%7D,'cvml','matthewturk@gmail.com');>> wrote:
On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@gmail.com
<javascript:_e(%7B%7D,'cvml','atmyers2@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@lists.spacepope.org
<javascript:_e(%7B%7D,'cvml','yt-dev@lists.spacepope.org');>
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org <javascript:_e(%7B%7D,'cvml','yt-dev@lists.spacepope.org');> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org <javascript:_e(%7B%7D,'cvml','yt-dev@lists.spacepope.org');> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@lists.spacepope.org <javascript:_e(%7B%7D,'cvml','yt-dev@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
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@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@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@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@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk <matthewturk@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@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@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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. 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. On Wed, Mar 16, 2016 at 12:37 PM, Matthew Turk <matthewturk@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.
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@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
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@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@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk <
matthewturk@gmail.com>
wrote: > > On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@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
On Wed, Mar 16, 2016 at 1:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: phase 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@lists.spacepope.org > > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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
Hi Cameron, On Wed, Mar 16, 2016 at 2:51 PM, Cameron Hummels <chummels@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@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@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@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@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@gmail.com> wrote:
On Wed, Mar 9, 2016 at 12:19 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: > > > On Wed, Mar 9, 2016 at 12:16 PM, Matthew Turk > <matthewturk@gmail.com> > wrote: >> >> On Wed, Mar 9, 2016 at 12:06 PM, Andrew Myers <atmyers2@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@lists.spacepope.org >> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> > >> _______________________________________________ >> yt-dev mailing list >> yt-dev@lists.spacepope.org >> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > > > > _______________________________________________ > yt-dev mailing list > yt-dev@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >
yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
Hey Matt, I have been swayed. You make a compelling argument for opengl vr going into stable. Thanks for going point by point through it, as I think it is a strong case. Looks cool! -- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
Hi Cameron, Thank you! I am happy that it swayed you. I can't wait to see what your galaxies look like in it. :) -Matt On Mon, Mar 21, 2016 at 4:46 PM, Cameron Hummels <chummels@gmail.com> wrote:
Hey Matt,
I have been swayed. You make a compelling argument for opengl vr going into stable. Thanks for going point by point through it, as I think it is a strong case. Looks cool!
-- Cameron Hummels NSF Postdoctoral Fellow Department of Astronomy California Institute of Technology http://chummels.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (6)
-
Andrew Myers -
Cameron Hummels -
Joseph Smidt -
Kacper Kowalik -
Matthew Turk -
Nathan Goldbaum