[yt-users] Stars on volume rendering

[j s oishi]

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
>