On Jan 6, 2011, at 6:30 PM, 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@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@cita.utoronto.ca <mailto:
h-clark@cita.utoronto.ca>
>>>> Astronomy office phone: +1-416-978-5759
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> yt-users mailing list
>>>>
yt-users@lists.spacepope.org
>>>>
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>>
>>> _______________________________________________
>>> yt-users mailing list
>>>
yt-users@lists.spacepope.org
>>>
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
>> _______________________________________________
>> yt-users mailing list
>>
yt-users@lists.spacepope.org
>>
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>>
> _______________________________________________
> yt-users mailing list
>
yt-users@lists.spacepope.org
>
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
_______________________________________________
yt-users mailing list
yt-users@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org