[yt-dev] OpenGL VR

Wed Mar 9 09:51:04 PST 2016

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 at 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 at gmail.com>
>> wrote:
>>
>>
>>>
>>> On Thu, Feb 25, 2016 at 11:40 AM, Matthew Turk <matthewturk at 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 at lists.spacepope.org
>>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> yt-dev mailing list
>>> yt-dev at lists.spacepope.org
>>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160309/e6a7a034/attachment.htm>