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

Matthew Turk matthewturk at gmail.com
Thu Mar 3 12:07:52 PST 2016


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
>



More information about the yt-dev mailing list