[yt-users] Stars on volume rendering

John Wise jwise at astro.princeton.edu
Fri Jan 7 12:01:28 PST 2011 

Hi Matt,

This all sounds great.  I like the idea of associating stars with bricks to simplify the search.

I think it's the easiest and best approach now (maybe not at petascale) to have all star particles duplicated on each processor.  I can't think of any simulation with more than a few million star particles, and that easily fits into memory.  This is the same approach I've taken with the new star particles in Enzo.  I thought it would be best to exploit the fact that the problem wasn't memory limited.

My 2c.
John

On 6 Jan 2011, at 18:30, Matthew Turk wrote:

> Hi John,
> 
> (As a quick comment, one can export to Sunrise from yt, so that could
> also serve as a mechanism for rendering star particles.)
> 
> I have been thinking about this a lot lately, and I think you're
> right: we need a proper mechanism for compositing star particles on
> the fly during the traversal of rays across a homogenized volume.  I
> had planned on this being one of my first yt projects this year.  The
> current process of volume rendering (for more detail see the method
> paper) is basically:
> 
> 1) Homogenize volume, splitting fields up into uniquely-tiling bricks
> 2) Sort bricks
> 3) For every brick, for every ray:
>  a) Calculate intersection
>  b) Update all channels (typically 3) based on *local* emission and absorption
>  c) Update ray position
> 4) Return image plane
> 
> This is true for both the old, homogenized volume rendering technique
> and the new kD-tree technique.  To fit star particles into this, we
> would regard them as exclusively sources of emission, with no impact
> on the local absorption.  Nominally, this should be easy to do: for
> every cell, simply deposit the emission from a star.  As you noted in
> your email, this results in very, very ugly results -- I tested it
> last summer with the hopes of coming up with something cool, but was
> unable to.  Testing it today on an airplane showed it had bitrot a
> bit, so I haven't attached it.  :)
> 
> I think we would need to move to, rather than cell-based emission (so
> that the smallest emission point from a star is a single cell) to a
> method where emission from star particles is calculated per ray (i.e.,
> pixel).  This would require an additional step:
> 
> 1) Homogenize volume, splitting fields up into uniquely-tiling bricks
> 2) Sort bricks
> 3) For every brick, for every ray:
>  a) Calculate intersection
>  b) Calculate emission from stars local to the ray
>  c) Update all channels (typically 3) based on *local* emission and absorption
>  d) Update ray position
> 4) Return image plane
> 
> This would enable both density-based emission *and* star emission.
> This could be both density isocontours, for instance, and individual
> stars.  The visual language in that would probably be very confusing,
> but it would be possible, particularly for pure annotations.
> 
> The issue here is that step 2b is probably very, very slow -- even
> using a (point-based) kD-tree it would likely add substantial run
> time, because there's no early termination mechanism.  What I think we
> could do, however, is execute a pre-deposition phase.  For the
> purposes of rendering, we can describe a star particle by only a few
> characteristics:
> 
> Emission(Red, Green, Blue)
> Gaussian(Radius)
> Position(x,y,z)
> 
> We should instead define an effective radius (ER), say at the 1%
> level, at which we won't worry anymore.  We could then deposit delta
> functions of size ER for every star particle.  This would give a cue
> to the ray caster, and we could modify:
> 
> 1) Homogenize volume, splitting fields up into uniquely-tiling bricks
> 2) Sort bricks
> 3) For every brick, for every ray:
>  a) Calculate intersection
>  b) If local delta_field == True, execute ball query and calculate
> emission from stars local to the ray
>  c) Update all channels (typically 3) based on *local* emission and absorption
>  d) Update ray position
> 4) Return image plane
> 
> For the first pass, we would probably want all our stars to have the
> same ER, which would then be the radius of our ball-query.  For
> parallel rendering, we would still have to have all of the star
> particles loaded on every processor; I don't think this is a problem,
> since in the limit where the star particles are memory-limiting, you
> would likely not suffer from pre-deposition.  This also solves the
> grid-boundary issues, as each processor would deposit all stars during
> its initial homogenization.
> 
> What do you think?  I think that the components external to the ray
> tracer could be assembled relatively easily, and then the ray tracer
> might take a bit of work.  As a post-processing step we could even add
> lens flare, for that extra Star Trek look.
> 
> -Matt
> 
> 
> On Thu, Jan 6, 2011 at 8:45 AM, John Wise <jwise at astro.princeton.edu> wrote:
>> I forgot to mention that another way to do this is making a derived field
>> that adds the stellar density to the gas density.  However this doesn't look
>> good when particles are in coarse grids, when they should be point sources
>> in the image.
>> 
>> def _RelativeDensityStars(field, data):
>>    return (data["Density"] + data["star_density"])/dma
>> add_field("RelativeDensityStars", function=_RelativeDensityStars,
>>          take_log = False)
>> 
>> where dma is a scaling variable.
>> 
>> I'm uploading my stand-alone script if you want to try to decipher it,
>> although I tried to comment it some.
>> 
>> http://paste.enzotools.org/show/1475/
>> 
>> Also I uploaded the colormap based on B-V colors that I ripped from
>> partiview to
>> 
>> http://www.astro.princeton.edu/~jwise/temp/BminusV.h5
>> 
>> John
>> 
>> On 01/06/2011 11:14 AM, John Wise wrote:
>>> 
>>> Hi Libby,
>>> 
>>> I'm afraid that there isn't a good solution for rendering stars, at
>>> least to my knowledge!
>>> 
>>> You can add them as pixels after you've determined the pixel numbers (as
>>> in Andrew's email) of the particles with the splat_points() routine in
>>> the image_writer module.
>>> 
>>> I wrote my own stand-alone splatter to put Gaussian splats for
>>> particles, but I never incorporated it into yt. I meant to a few months
>>> back when I wrote it but never did! It will produce these types of splats
>>> 
>>> 
>>> http://www.astro.princeton.edu/~jwise/research/GalaxyBirth_files/combine.png
>>> 
>>> 
>>> I had to manually blend the gas volume rendering and star splats
>>> afterwards to produce that image.
>>> 
>>> I hope I can make something that looks as good as partiview soon. This
>>> is the same dataset but with partiview.
>>> 
>>> 
>>> http://www.astro.princeton.edu/~jwise/research/GalaxyBirth_files/stars_only.png
>>> 
>>> 
>>> I'll see if I can make time (first I have to find the code!) to
>>> incorporate my splatter into yt.
>>> 
>>> John
>>> 
>>> On 01/06/2011 09:15 AM, Elizabeth Harper-Clark wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> Thanks for all your help over the last couple of days. One more question:
>>>> - Can I plot particles on a volume rendered image?
>>>> I have stars and I want to show where they are!
>>>> 
>>>> Thanks,
>>>> 
>>>> Libby
>>>> 
>>>> --
>>>> Elizabeth Harper-Clark MA MSci
>>>> PhD Candidate, Canadian Institute for Theoretical Astrophysics, UofT
>>>> Sciences and Engineering Coordinator, Teaching Assistants' Training
>>>> Program, UofT
>>>> 
>>>> www.astro.utoronto.ca/~h-clark <http://www.astro.utoronto.ca/%7Eh-clark>
>>>> h-clark at cita.utoronto.ca <mailto:h-clark at cita.utoronto.ca>
>>>> Astronomy office phone: +1-416-978-5759
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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

More information about the yt-users mailing list