[yt-dev] A change to the new volume rendering API

Thu Mar 3 13:56:18 PST 2016

I guess as long as one specifies the camera positions in comoving coords,
which should retain continuity between cosmological dataset outputs, then
yes, this appears like it will be OK.

Looks good. +1

On Thu, Mar 3, 2016 at 1:52 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

>
>
> On Thu, Mar 3, 2016 at 3:50 PM, Cameron Hummels <chummels at gmail.com>
> wrote:
>
>> I thought right now the scene lacks a unit system unto itself, but
>> perhaps I'm wrong on this.  Wouldn't specifying a unit system for the Scene
>> break multi-ds VRs because each ds might have its own unit system?
>>
>
> Nope, it only breaks the situation where you want to *simultaneously*
> render data from two datasets with different units. If you're switching
> datasets but only using one at a time, everything is consistent.
>
>
>>
>> In principle just having the camera attach to the scene seems OK as
>> you've proposed, so that it inherits things by default from the scene, but
>> again, I'd like to hear Sam's opinion on all of this, since he may have had
>> a different vision of things.
>>
>> On Thu, Mar 3, 2016 at 1:45 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Mar 3, 2016 at 3:43 PM, Cameron Hummels <chummels at gmail.com>
>>> wrote:
>>>
>>>> I thought the reason we chose to do things this way was to leave the
>>>> situation open for multi-ds scenes (ie for making movies over time series
>>>> with a camera path that easily spanned the volume over individual
>>>> datasets)?  Matt is correct in that right now there is no way to do time
>>>> series movies, but I thought we redefined things this way to enable it in
>>>> the future.  Maybe I'm mistaken here?  Perhaps Sam can chime in.
>>>>
>>>> If we implement things as Nathan suggests, does this still leave us
>>>> room to make VRs over time series and have a camera in a consistent domain?
>>>>  it seems like it could be problematic if that unit system changes with
>>>> each dataset (eg for cosmological volumes).  But perhaps one could just
>>>> specify things in comoving units and then things would just "work"?
>>>>
>>>> For time series movies, does this mean we need to make a scene object
>>>> for each individual dataset?  I had thought that we'd have a single Scene
>>>> object and then add the individual time series datasets to it, along with
>>>> the timeline object to define how the camera moved, etc.  But obviously
>>>> none of this is implemented, and I don't know that we're all in agreement
>>>> on it.  I just don't want to paint ourselves into a corner so that making
>>>> movies over timeseries becomes really difficult when we get around to
>>>> implementing it.
>>>>
>>>
>>> Since I'm attaching the camera to the scene, and in principle we can
>>> switch datasets but keep the scene the same, I don't see any reason why
>>> time series wouldn't work with this modification.
>>>
>>>
>>>>
>>>> On Thu, Mar 3, 2016 at 12:07 PM, Matthew Turk <matthewturk at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi Nathan,
>>>>>
>>>>> Seems like the best way forward.  I think we're far past being able to
>>>>> do things like "mandate a unitary coordinate system for the scene" and
>>>>> so I think this is a good way forward.  The only time it would really
>>>>> break is multi-DS scenes, which I think right now aren't allowed.
>>>>> Although, that would be nice.  :)
>>>>>
>>>>> +1
>>>>>
>>>>> -Matt
>>>>>
>>>>> On Thu, Mar 3, 2016 at 2:04 PM, Nathan Goldbaum <nathan12343 at gmail.com>
>>>>> wrote:
>>>>> > Hi all,
>>>>> >
>>>>> > Right now I'm trying to resolve the issues the new VR interface has
>>>>> when you
>>>>> > try to specify a volume rendering scene using data that has units
>>>>> attached.
>>>>> >
>>>>> > Right now, the scene and camera object don't have any knowledge
>>>>> about the
>>>>> > units of the data being rendered. At the same time, there are places
>>>>> where
>>>>> > the camera, lens and scene assume things like the "width" and
>>>>> "position"
>>>>> > *do* have units, which can break in annoying ways.
>>>>> >
>>>>> > Unfortunately, the way the VR infrastructure is set up right now,
>>>>> it's very
>>>>> > difficult for the scene, RenderSource, camera, and lens to all have a
>>>>> > consistent unit system. \
>>>>> >
>>>>> > I *could* just attach a unit registry to the scene object, but then
>>>>> since
>>>>> > all of these different objects get created independently, it doesn't
>>>>> help to
>>>>> > have a unit system defined as part of the scene object, since I
>>>>> can't access
>>>>> > the scene from the camera object.
>>>>> >
>>>>> > What I'd like to do to fix this is to alter the VR API. Instead of
>>>>> being
>>>>> > able to do something like:
>>>>> >
>>>>> > sc = Scene()
>>>>> > cam = Camera()
>>>>> > sc.camera = cam
>>>>> >
>>>>> > I'd like to make it so you need to do:
>>>>> >
>>>>> > sc = Scene()
>>>>> > sc.add_camera()
>>>>> >
>>>>> > This way I can ensure that the camera object always has a reference
>>>>> to the
>>>>> > Scene object it's attached to, and thus I'll always be able to refer
>>>>> to a
>>>>> > consistent unit system.
>>>>> >
>>>>> > Does anyone have any objections to this?
>>>>> >
>>>>> > -Nathan
>>>>> >
>>>>> > _______________________________________________
>>>>> > 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
>>
>>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160303/2eb8cd3a/attachment.htm>