A change to the new volume rendering API
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
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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
I think this is a good idea. On Thu, Mar 3, 2016 at 3:07 PM, Matthew Turk <matthewturk@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
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
On Thu, Mar 3, 2016 at 2:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
+1. On Thu, Mar 3, 2016 at 12:36 PM, Michael Zingale < michael.zingale@stonybrook.edu> wrote:
I think this is a good idea.
On Thu, Mar 3, 2016 at 3:07 PM, Matthew Turk <matthewturk@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
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
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
On Thu, Mar 3, 2016 at 2:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: the 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
-- Michael Zingale Associate Professor
Dept. of Physics & Astronomy • Stony Brook University • Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale@stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale github: http://github.com/zingale
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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
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
On Thu, Mar 3, 2016 at 2:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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
On Thu, Mar 3, 2016 at 3:43 PM, Cameron Hummels <chummels@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@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
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
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
On Thu, Mar 3, 2016 at 2:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: the 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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? 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@gmail.com> wrote:
On Thu, Mar 3, 2016 at 3:43 PM, Cameron Hummels <chummels@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@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
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
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
On Thu, Mar 3, 2016 at 2:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: the 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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
On Thu, Mar 3, 2016 at 3:50 PM, Cameron Hummels <chummels@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@gmail.com> wrote:
On Thu, Mar 3, 2016 at 3:43 PM, Cameron Hummels <chummels@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@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
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
On Thu, Mar 3, 2016 at 2:04 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: 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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@gmail.com> wrote:
On Thu, Mar 3, 2016 at 3:50 PM, Cameron Hummels <chummels@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@gmail.com> wrote:
On Thu, Mar 3, 2016 at 3:43 PM, Cameron Hummels <chummels@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@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@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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
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@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@gmail.com> wrote:
On Thu, Mar 3, 2016 at 3:50 PM, Cameron Hummels <chummels@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@gmail.com> wrote:
On Thu, Mar 3, 2016 at 3:43 PM, Cameron Hummels <chummels@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@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@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@lists.spacepope.org > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org > _______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@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@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
participants (6)
-
Andrew Myers -
Cameron Hummels -
Matthew Turk -
Michael Zingale -
Nathan Goldbaum -
Sam Skillman