[yt-users] Stars on volume rendering

Matthew Turk matthewturk at gmail.com
Mon Jan 17 06:34:12 PST 2011 

Hi everyone,

After this discussion last week, we had a bit of back and forth on
yt-dev on how to implement this, and then a very simple first-pass was
added.  I've resolved to blog about progress in yt on a (possibly)
weekly basis, and this was the subject of the first entry in that
series:

http://blog.enzotools.org/yt-development-star-particle-rendering-simple

It includes a bit of discussion on how to access the nascent star
particle rendering, along with a bit on some other topics.

Best,

Matt

On Fri, Jan 7, 2011 at 3:13 PM, j s oishi <jsoishi at gmail.com> wrote:
>
> As a note, that's what Orion does for all its particles, and it works just fine.
>
> On Fri, Jan 7, 2011 at 12:01 PM, John Wise <jwise at astro.princeton.edu> wrote:
> > 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
> >
> > _______________________________________________
> > 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