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

[Cameron Hummels]

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.

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