[yt-users] volume rendering

Tue Apr 5 13:29:02 PDT 2011

Hi Maike,

(I think this is your first post -- welcome to yt-users!)

On Tue, Apr 5, 2011 at 11:34 AM, Maike Schmidt <maikeschmidt2 at gmx.de> wrote:
> Hi together,
>
> I would like to better understand how the volume rendering works.
> It is explained here
>
> http://yt.spacepope.org/doc/visualizing/volume_rendering.html
>
> that the user defines transfer functions in terms of RGB values.
> From the description of the add_gaussian function, I understand
> that these RGB values describe the color value in the interval
> [0,1]. Now, in the radiative transfer equation on the above
> website, the emissivity gets multiplied by the path length
> delta s. I am now wondering how this works: Depending on how
> big the step size is, one could get extremely large or extremely
> small intensities that are essentially unrelated to the RGB
> values that were previously specified. How is it possible that,
> for example, the color of a density isosurface depends on the
> density only and not on the cell size? I guess I am missing
> something.
>
> Cheers,
> Maike
>

The short answer, I think, is that you are right, you can get very
large intensities in large cells that are unrelated to what came
before.  But, for the most part, this is not an issue because of how
the weighting and color assignments are typically done.

[begin long, rambly answer]

There are a couple things in what you ask -- the first is that there
are two primary methods for volume rendering.  The first is to tell a
story using somewhat abstract visuals; this is typically what people
think of when they think of volume rendering, and it is supported by
(and possibly the primary application of) yt.  This would be what's
used when the ColorTransferFunction is used.  The other is designed to
perform a meaningful line integral through the calculation; this is
what's done with the ProjectionTransferFunction and the
PlanckTransferFunction.  In all cases, the RT equation *is*
integrated, but what varies between the two mechanisms is where the
emission and absorption values come from.

In all cases, while the code may call things RGB, they need not be RGB
explicitly.  In fact, for the ProjectionTransferFunction, they are
not.  For the ProjectionTransferFunction, the code simply integrates
with the emission value being set to the fluid value in a cell and the
absorption value set to exactly zero.  This results in the
integration:

dI/ds = v_local

Where v_local is the (interpolated) fluid value at every point the
integration samples, which defaults to 5 subsamples within a given
cell.  So the final intensity is equal to the sum of all
(interpolated) values along a ray times the (local-to-a-cell) path
length between samples.  For the PlanckTransferFunction, the local
emission is set to some approximation of a black-body, weighted with
Density for emission, and the absorption is set to an approximation of
scattering, which we then assign to RGB.  The PTF also utilizes a
'weighting' field inside the volume renderer, which I discuss briefly
below, to allow it to utilize multiple variables at a given location
to calculate the emission and absorption.  (i.e., Temperature governs
the color, density governs the strength of the emission -- sliding
along x and scaling along y, in the plot of the transfer function.)

When integrating a ColorTransferFunction, the situation is somewhat
different.  I've spent a bit of time reviewing the code, and I think I
can provide a definite answer to your question.  For reference, the
code that this calls upon is defined in two source files:

yt/visualization/volume_rendering/transfer_functions.py
yt/utilities/_amr_utils/VolumeIntegrator.pyx

Specifically, in the class ColorTransferFunction and in the
FIT_get_value and TransferFunctionProxy.eval_transfer functions.

The ColorTransferFunction, which is designed for visualizing abstract
isocontours, rather than computing an actual line integral that is
then examined or modified, sets a weighting *table*.  (For the
PlanckTransferFunction, a weight_field_id is set; this means to
multiply the value from a table against a value obtained from another
field.  This is how density-weighted emission is done.)  The
weight_table_id for CTF is set to the table for the alpha emission.
Functionally, this means that we accentuate the peaks and spikes in
the color transfer function, because alpha is typically set quite high
at the gaussians included.

So in essence, with a color transfer function we accentuate only the
regions where we have isocontours.  I think it's easiest to speak
about this in terms of a visualization of Density isocontours.  If you
place contours in the outer regions, if your emission value is too
high, it will indeed obscure completely the inner regions.  I have
experimented with this and have found that it is extremely easy to
create a completely visually confusing image that contains only the
outer contours and wispy hints of the inner contours.

However, even if you do have outer isocontours, if you set the
emission and color values lower, you can indeed provide glimpses into
the inner regions.  The inner regions are likely generating *higher*
emission values (this is certainly how it is done in yt, with the
add_layers method on ColorTransferFunction.)

Anyway, I hope that helps clear things up a little bit -- but please
feel free to write back with any further questions about this or
anything else.

Best,

Matt

>
> --
> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>