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

Sam Skillman samskillman at gmail.com
Thu Mar 3 21:27:28 PST 2016 

Seems OK to me. It should simplify a bunch of the logic in there if you can
climb back out to something that knows units. Right now there is a bunch of
going back and forth between unitful and bare numpy arrays, iirc.
On Mar 3, 2016 2:56 PM, "Cameron Hummels" <chummels at gmail.com> wrote:

> 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
>
> _______________________________________________
> 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/20160303/c1e92153/attachment.htm>

More information about the yt-dev mailing list