[yt-users] volume rendering

Wed Apr 6 01:27:37 PDT 2011

Hi Matt,

many thanks for this really nice explanation! But I still
don't understand how the color transfer function works.
I thought that, if you add a Gaussian with peak (r,g,b),
then the intensity that arrives at the camera from cells
that contain the center of the Gaussian has exactly intensity
(r,g,b), when I am neglecting absorption. Otherwise I don't
understand how one can relate the color of the Gaussian
to the color at the camera.

Now, say I want to visualize an isosurface of density
on an AMR grid with 10 refinement levels, then the actual
intensity contribution j * delta s will differ by 3 orders
of magnitude for cells with the same density but different
cell size. How do you make all these cells emit the same color?
This is what I don't understand.

I guess it boils down to the question of how exactly you
calculate your j in the radiative transfer equation when
you have a color transfer function, say a single Gaussian
with peak (r,g,b).

Many thanks,
Maike

-------- Original-Nachricht --------
> Datum: Tue, 5 Apr 2011 16:29:02 -0400
> Von: Matthew Turk <matthewturk at gmail.com>
> An: Discussion of the yt analysis package <yt-users at lists.spacepope.org>
> Betreff: Re: [yt-users] volume rendering

> 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
> >
> _______________________________________________
> yt-users mailing list
> yt-users at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org

-- 
NEU: FreePhone - kostenlos mobil telefonieren und surfen!			
Jetzt informieren: http://www.gmx.net/de/go/freephone