[Yt-dev] Inline Volume Rendering

[Sam Skillman]

Hi Matt,

First things first - I've never even tried to do a volume rendering inline.

If we don't want to move data around, it should be straightforward for
simulations without load balancing turned on because the enzo domain
decomposition mimics the kd-tree breadth-first decomposition (with a few
adjustments).  If load-balancing is turned on, I really have no clue how one
would do this without some major additions.

If we are okay with moving data around then there are more options and we
would just have to put an initial data distribution function before the
rendering begins.  We could even add in some better memory management so
that chunks of data are sent as needed instead of having to load everything
into memory at one time.

Alternatively, if we don't care about back-to-front ray-casting (in some
cases you can't tell much of a difference), then the problem gets very
simple...we may want to try this out on some post processing renders and get
a feel for how much it matters.

Anyways, I guess the current status would be that if we want it to work for
all cases, it's going to take quite a bit more work.  If we want it to work
in some of the cases, it shouldn't be too much more work.

Sam

On Wed, Dec 8, 2010 at 4:00 PM, Matthew Turk <matthewturk at gmail.com> wrote:

> Hi all, (especially Sam)
>
> What's the current status of inline Enzo volume rendering?  Sam, you
> had mentioned to me that with the new kD-tree decomposition that this
> should be feasible.  If we opt not to move data around, which is my
> preference, is it still possible to partition every grid that belongs
> to a processor and then do the appropriate number of intermediate
> composition steps of the image?  I recall Sam saying this may require
> log_2 Nproc composition steps, which may in fact be acceptable.
>
> Thanks,
>
> Matt
>
> PS Stephen, Britton and I have been chatting off-list about inline
> HOP, but once we come to a consensus we'll float it back onto the
> list.
> _______________________________________________
> 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/20101208/2b7d81f4/attachment.html>