[yt-users] volume rendering
Maike Schmidt
maikeschmidt2 at gmx.de
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
More information about the yt-users
mailing list