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 Astronomy office phone: +1-416-978-5759
Hi Elizabeth, There is probably a better way to do this, but since Orion doesn't have particle support at the moment, I have a routine for drawing the particle at position "r" onto a volume rendered image with arbitrary orientation. import numpy as na def add_star_projected(r,ax,cam,ms): """ Adds the particle at position r to Axes ax. Needs information on the orientation of the image plane contained in cam """ north_vector = cam.unit_vectors[0] east_vector = cam.unit_vectors[1] N1 = cam.resolution[0] N2 = cam.resolution[1] c = cam.center r = r - c W = cam.width[0] y_pixels = floor(na.dot(r,north_vector) * (N2/W) + N2/2.0) x_pixels = floor(na.dot(r,east_vector) * (N1/W) + N1/2.0) ax.hold(True) ax.plot([x_pixels],[y_pixels],'wo', markersize = ms) ax.hold(False) ax.axis((0,N1,0,N2)) Assuming you're using the Camera interface, that contains all the information you need to do the conversion. If you can get a list of particles w/ their positions (we have our own way of doing this that probably doesn't apply), you can then loop through that and add them at the correct position on the off-axis projection. Andrew M On Thu, Jan 6, 2011 at 6:15 AM, Elizabeth Harper-Clark < h-clark@astro.utoronto.ca> 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 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
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.... 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
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....
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
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
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....
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
Matt -- This seems like a reasonable way to do it. I definitely agree with defining an effective radius for the star particles; in my limited experience, 1% is more than OK. I worry that when the number of star particles is large, the delta_field will be almost all True, killing any speed-up due to that (although clearly for small numbers of star particles, this is still very efficient). Can you explain in more detail why the search in 2b is going to be so slow? I thought maybe you could do some clever sorting of the star particles to speed this step up; I suspect I just don't understand how the intersection calculation is done in the first place (and maybe I should actually look at the code). Cheers, Greg 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
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....
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
Hi all,
What if we were able to add a set of 3 fields at ray-casting time that
correspond to the RGB emission from the stars in each brick? Then during
the cast you would add the emission from the normal transfer function then
from the RGB fields. Something I could imagine is the following:
1) Homogenize with the AMR kd-tree
2) Create R,G,B data fields
3) For every star:
a) Locate all the bricks in and ER sized cube (cube is faster logic than a
sphere) using the AMR kd-tree structure, and store the star data in the
brick object
4) For every brick:
a) For every star in the brick:
i) Deposit RGB emission in the fields based on Gaussian(|star_{x,y,z} -
cell_{x,y,z}|) or some function
b) For every ray:
i) Calculate intersection
ii) Update all channels (typically 3) based on *local* emission and
absorption + extra RGB data fields
iii) Update ray position
5) Return image plane
The benefit to this is that if you want to add other objects (DM particles,
halos, alien lasers, etc), all you'd have to do is describe the extent of
the emission and how it should be deposited into RGB fields.
Anyways, just a thought. I'd definitely be up for helping with the kd-tree
brick locator if you want. In any case, I'm looking forward to this new
functionality!
Best,
Sam
On Fri, Jan 7, 2011 at 9:24 AM, Greg Bryan
Matt -- This seems like a reasonable way to do it. I definitely agree with defining an effective radius for the star particles; in my limited experience, 1% is more than OK.
I worry that when the number of star particles is large, the delta_field will be almost all True, killing any speed-up due to that (although clearly for small numbers of star particles, this is still very efficient).
Can you explain in more detail why the search in 2b is going to be so slow? I thought maybe you could do some clever sorting of the star particles to speed this step up; I suspect I just don't understand how the intersection calculation is done in the first place (and maybe I should actually look at the code).
Cheers, Greg
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
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
On Thu, Jan 6, 2011 at 8:45 AM, John Wise
wrote: 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....
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
Sorry to reply to my own email, but I just realized that this is probably
what Matt was referring to in terms of adding it as a grid quantity and
having it not show up that great. I was thinking of a regime where the cell
size wasn't much larger than the distance between two rays. Anyways, the
location stuff should still work if that helps at all...
Sam
On Fri, Jan 7, 2011 at 11:01 AM, Sam Skillman
Hi all,
What if we were able to add a set of 3 fields at ray-casting time that correspond to the RGB emission from the stars in each brick? Then during the cast you would add the emission from the normal transfer function then from the RGB fields. Something I could imagine is the following:
1) Homogenize with the AMR kd-tree 2) Create R,G,B data fields 3) For every star: a) Locate all the bricks in and ER sized cube (cube is faster logic than a sphere) using the AMR kd-tree structure, and store the star data in the brick object 4) For every brick: a) For every star in the brick: i) Deposit RGB emission in the fields based on Gaussian(|star_{x,y,z} - cell_{x,y,z}|) or some function b) For every ray: i) Calculate intersection ii) Update all channels (typically 3) based on *local* emission and absorption + extra RGB data fields iii) Update ray position 5) Return image plane
The benefit to this is that if you want to add other objects (DM particles, halos, alien lasers, etc), all you'd have to do is describe the extent of the emission and how it should be deposited into RGB fields.
Anyways, just a thought. I'd definitely be up for helping with the kd-tree brick locator if you want. In any case, I'm looking forward to this new functionality!
Best, Sam
On Fri, Jan 7, 2011 at 9:24 AM, Greg Bryan
wrote: Matt -- This seems like a reasonable way to do it. I definitely agree with defining an effective radius for the star particles; in my limited experience, 1% is more than OK.
I worry that when the number of star particles is large, the delta_field will be almost all True, killing any speed-up due to that (although clearly for small numbers of star particles, this is still very efficient).
Can you explain in more detail why the search in 2b is going to be so slow? I thought maybe you could do some clever sorting of the star particles to speed this step up; I suspect I just don't understand how the intersection calculation is done in the first place (and maybe I should actually look at the code).
Cheers, Greg
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
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
On Thu, Jan 6, 2011 at 8:45 AM, John Wise
wrote: 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....
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
Hi Greg and Sam,
Greg -- I think my concern with locating the particles was arising
mainly from the sampling frequency. The volume renderer as it
currently stands takes N (usually 5) samples for every cell. While
this is a bit naive compared to the samplers that operate more
lockstep for each ray, it provides pretty good results. So my concern
was that querying the kD-tree for every sample would be very
expensive. Maybe this is misguided. I have to think about the idea
for sorting the particles, as I'm not yet sure how we would want to do
that. It may be possible that if we sorted them according to their
distance along the parameter defining the image plane, and then keep a
boxcar of stars-to-consider that we could eliminate the need to do a
query of a large structure.
And I share your sentiment, in many cases the delta-field would be
positive just everywhere. But I wonder if there's a breakdown there
-- maybe if the delta-field crests some threshold, it's more
appropriate to be rendering the stars as deposited in the cells? But
even there, they could end up looking quite coarse.
...but maybe we can solve that with a combination of what Sam
suggested and something else he alluded to. If we associated stars
with Bricks, we could reduce the number of stars-per-brick
substantially. We could approach this during the partitioning by
querying a box of sides LE+ER and RE+ER, and any stars that fall into
that box would then be "assigned" to that brick. Stars wouldn't be
uniquely placed in a brick, so they would still be able to interact
outside their boundaries, but then we could simplify the sort
substantially. We may need to use individual kD-trees for stars in
each brick, or else we would have to iterate over the full list of
brick_stars at every sample location, which even with 10 stars would
substantially slow down the calculation.
This is feeling more and more do-able...
-Matt
On Fri, Jan 7, 2011 at 6:11 PM, Sam Skillman
Sorry to reply to my own email, but I just realized that this is probably what Matt was referring to in terms of adding it as a grid quantity and having it not show up that great. I was thinking of a regime where the cell size wasn't much larger than the distance between two rays. Anyways, the location stuff should still work if that helps at all... Sam
On Fri, Jan 7, 2011 at 11:01 AM, Sam Skillman
wrote: Hi all, What if we were able to add a set of 3 fields at ray-casting time that correspond to the RGB emission from the stars in each brick? Then during the cast you would add the emission from the normal transfer function then from the RGB fields. Something I could imagine is the following: 1) Homogenize with the AMR kd-tree 2) Create R,G,B data fields 3) For every star: a) Locate all the bricks in and ER sized cube (cube is faster logic than a sphere) using the AMR kd-tree structure, and store the star data in the brick object 4) For every brick: a) For every star in the brick: i) Deposit RGB emission in the fields based on Gaussian(|star_{x,y,z} - cell_{x,y,z}|) or some function b) For every ray: i) Calculate intersection ii) Update all channels (typically 3) based on *local* emission and absorption + extra RGB data fields iii) Update ray position 5) Return image plane The benefit to this is that if you want to add other objects (DM particles, halos, alien lasers, etc), all you'd have to do is describe the extent of the emission and how it should be deposited into RGB fields. Anyways, just a thought. I'd definitely be up for helping with the kd-tree brick locator if you want. In any case, I'm looking forward to this new functionality! Best, Sam
On Fri, Jan 7, 2011 at 9:24 AM, Greg Bryan
wrote: Matt -- This seems like a reasonable way to do it. I definitely agree with defining an effective radius for the star particles; in my limited experience, 1% is more than OK.
I worry that when the number of star particles is large, the delta_field will be almost all True, killing any speed-up due to that (although clearly for small numbers of star particles, this is still very efficient).
Can you explain in more detail why the search in 2b is going to be so slow? I thought maybe you could do some clever sorting of the star particles to speed this step up; I suspect I just don't understand how the intersection calculation is done in the first place (and maybe I should actually look at the code).
Cheers, Greg
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
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....
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
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
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
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....
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
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
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
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....
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
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
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
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
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....
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
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi John et al - this thread is 10 years old but I'm now confronting the same situation - I'd like to be able to visualize stars in a volumetric rendering. Does the method still need to be splats or has something now been added to yt specifically for rendering stars in cosmological simulations? (I've not be able to find anything) The yt code has changed a fair bit since the suggestions in this thread were made. What's the current recommended method? Is there an example script available? Cheers Ian
Hi Ian,
Wow, this thread is a blast from the past!
If I am remembering correctly, where we got recently was to use the
stars like point sources, but I don't think we managed to composite
them *into* a volume rendering. To be honest it's been a while, but
perhaps you could hop onto slack, or we could do a live-interaction to
try to work it out sometime?
On Wed, Dec 8, 2021 at 8:41 PM Ian Woodward
Hi John et al - this thread is 10 years old but I'm now confronting the same situation - I'd like to be able to visualize stars in a volumetric rendering. Does the method still need to be splats or has something now been added to yt specifically for rendering stars in cosmological simulations? (I've not be able to find anything)
The yt code has changed a fair bit since the suggestions in this thread were made.
What's the current recommended method? Is there an example script available?
Cheers
Ian _______________________________________________ yt-users mailing list -- yt-users@python.org To unsubscribe send an email to yt-users-leave@python.org https://mail.python.org/mailman3/lists/yt-users.python.org/ Member address: matthewturk@gmail.com
Sure, thanks Matthew. I'll ask the question on Slack, and see what ideas emerge! A live interaction may be difficult - I'm in Tasmania, Australia, so there's a fair time difference. I'm also not highly versed in yt - quite new to it...but eager to learn.
participants (8)
-
Andrew Myers
-
Elizabeth Harper-Clark
-
Greg Bryan
-
Ian Woodward
-
j s oishi
-
John Wise
-
Matthew Turk
-
Sam Skillman