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

Nathan Goldbaum nathan12343 at gmail.com
Thu Mar 3 13:52:10 PST 2016


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160303/77aca846/attachment.html>


More information about the yt-dev mailing list