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

[Nathan Goldbaum]

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