Dear Anonymous Reviewers,

Thank you sincerely for the conditional acceptance of our paper. We have attempted to address every concern as best we could. If you have any further feedback we would be happy to work it in before the camera-ready deadline. 

Response is as follows.

------------------------ Submission 268, Review 3 ------------------------

   * The support radius for truncation affects rendering quality and speed.
   This trade-off should be discussed.

Done, in section 6. 

   * I am not sure about the quality discussion the authors provide. I don't
   see that their approach would be better than the one by Fraedrich et al.
   when using similar samplings along the rays. Also, the result in Figure 1
   cannot be judged. First, the viewpoints for the renderings are not
   identifical and, second, the two views do not render the same thing (2
   fields vs. 1 field). This should be fixed.

We fixed the teaser as requested. Our method would be identical to that of
Fraedrich et al. with a buffer as wide as the full image, though in their paper
they did not always do that. Because the Fraedrich method maintains a single
proxy for the entire GPU, as opposed to separate smaller buffers per thread, we have lower memory consumption. 

   * The generation of the transfer function for multi-fields is not clear.
   Is this just adding the contributions of multiple 1d transfer functions
   applied to different fields? Or are we actually talking about some more
   sophisticated multi-dimensional transfer function? If yes, how is it
   done?

Exactly — it is multi-field classification but we only perform 1D classification, not multidimensional classification (though that certainly could be possible…?). There is nothing particularly complicated about this, except for the fact that it’s expensive to do with structured volumes (both the memory to store the extra volume, and 2x or more samples). While this technique is simple, it is potentially very useful, especially for computational chemists.

   * How much gain did the early ray termination provide?

Moderate amounts, but nothing out of the ordinary compared to structured volume rendering. I added discussion and a plot in Section 6.

   * Concerning the performance the authors state that it is "more affected
   by the number of volume samples than by the number of particles". I
   believe that this is true, but I would like to see plots showing how the
   method scales for the two numbers (e.g., applying it to multiple
   downsampled version of data sets).

Done in Section 6. and Figs. 5 and 6. Rather than using downsampled datasets, we used subsets of the 82M particle data set. This enables us to fairly evaluate the same RBF reconstruction regardless of data size, which would be difficult with LOD data.

   * The authors claim that RBF volume rendering has the same quality as
   cubic B-spline reconstruction of structure data. This statement is not
   obvious and needs to be backed up.

Good point. We implemented tricubic B-spline filtering using the method of Sigg and Hadwiger, and put an image in the Teaser.

   * In general the structure of the paper is good  but I would recommend
   the authors to reduce `some text in the section 5, because some
   subsections are over explained and they are not relevant for the paper in
   general, for instance section 5.1. Section 5.6 is claimed as a major
   contribution but the current text is not clear enough to validate it, a
   little more of details would be very useful.

Done. We reduced the text in 5.1 (which I think would help with reproduce ability, but could be less verbose). We expand on Section 5.6, and provide Figure 4 to help explain it.

   * From my point of view, the weak part of the paper is the results
   section. Some statements are not well justified with the results,
   specially on section 6.1. I encourage the authors to rewrite this section
   and try to be precise on their discussions.

Done — we have added many new benchmarks and done a thorough rewrite of that section. 

   * In Fig. 1, the authors used a dt = 1.0, \sigma  = 3.1, and 2 voxels per
   angstrom. What is the length of the integrated ray? What is the size of
   the domain? When reading the paper, I (incorrectly) assumed that the ray
   is parameterized in the interval [0,1], but this is clearly not the case,
   since the dt=1. The authors should provide more details about the
   dimensions of the datasets so that the reader would have a better idea on
   the numerical errors involved in the approximation used.

Done at the top of the Results section. We state that all molecular data are in Angstrom units, and the CubeP3M simulation uses the unit cell defined by that simulation. Dt is given in world space units.

   * The authors have introduced two improvements: packet of rays, coherent
   traversal with BVH. I'd like to see which of these improvements
   contributes the most to the speedups shown Table 2 and Figure 5. What
   happens if a packet of rays contains a single ray?

Unfortunately there is no easy way to implement single-ray traversal in this framework; and if we could it would not be particularly efficient (e.g., compared to a “naive” OpenMP implementation). Unlike Embree, bnsView/RIVL never had a “single ray” implementation. In terms of evaluating the impact of packets, there is already a large body of work that has done that: the short answer is “they are worth it”, particularly for primary rays. 

Anecdotally, SSE (4-wide) performs nearly as well as AVX (8-wide) on the SandyBridge CPU’s (due to missing integer instructions in AVX1, and some other reasons). We thought this was too much information for this paper so we left out SSE benchmarks.

In short: we acknowledge that this is a limitation of the IVL/ISPC route, and are writing our desire to compare with efficient single-ray OpenMP implementations into future work. 

   * I think the authors should stress out the new contributions compared to
   the previous publications in terms of memory and quality. Especially I
   would like to see the memory usage changes to provide sufficiently high
   quality results. Also it would be good to provide good reasons to build
   up the direct RBF evaluation instead of using a high resolution proxy
   although there is sufficient memory on CPU side.

Excellent point. We emphasize the memory advantages in the teaser, abstract and conclusion, as well as a dedicated paragraph in Section 6..

   * Fix all glitches in the presentation of the work as listed by the
   reviewers.

OK.

   Methodology:
   * The choice of the kernel in form of a truncated Gaussian is suboptimal,
   as the truncation leads to discontinuities. I would have preferred the
   authors to use a cubic spline with sinite support, as it is typically
   done in the SPH community. This may have made teh integration a bit more
   complicated, but I do not see why it would not have been possible to do
   so. Are there any issues I don't see?

The reason we used the Gaussian is (1) it’s fast to evaluate on MIC, (2) its derivative is very fast to evaluate, and (3) discontinuity is not really a problem as long as you clamp the transfer function and choose an appropriate sigma. In fact, as we show in Fig. 7, the Gaussian’s infinite support enables multiscale modeling abilities that would require some modification to compact RBF’s. 

   * Also, the support radius for truncation affects rendering quality and
   speed. If the authors want to stick to their Gaussians, this trade-off
   should be discussed.

Good point, done in Figs. 7 and 9 in section 6, discussing the truncation and scale coefficients.

   * I am not sure about the quality discussion the authors provide. I don't
   see that their approach would be better than the one by Fraedrich et al.
   when using similar samplings along the rays. Also, the result in Figure 1
   cannot be judged. First, the viewpoints for the renderings are not
   identifical and, second, the two views do not render the same thing (2
   fields vs. 1 field). This should be fixed.

Done (see above).

   * Also, the statement about pre-computation (e.g., the 2 minutes listed
   in Figure 1) is not a strong one (still valid though), as the simulation
   times are typically significantly larger.

It depends; that MD simulation (LAMMPS) would be capable of generating data faster than 2 minutes/frame. It is unlikely however that the user would choose to save that many timesteps to the filesystem. But good point! 

I updated the teaser to handle multi field data at 1 voxel per Angstrom, which is a more realistic preprocess and just as detrimental to the structured pipeline approach.

   * The generation of the transfer function for multi-fields is not clear.
   Is this just adding the contributions of multiple 1d transfer functions
   applied to different fields? Or are we actually talking about some more
   sophisticated multi-dimensional transfer function? If yes, how is it
   done?

Yes, that’s basically it, just 1D TF’s. But very useful. See above.

   * When a paper talks about tera- to petabyte data sets in the motivation,
   I do expect to see some in the result section.

Agreed… but we have to walk before we can run! In our case, I used that to motivate (i) why we care about CPU/MIC vis in the first place and (ii) why we need methods that reduce memory costs.

   * How much gain did the early ray termination provide?

Added a plot in Fig. 6.

   * Concerning the performance the authors state that it is "more affected
   by the number of volume samples than by the number of particles". I
   believe that this is true, but I would like to see plots showing how the
   method scales for the two numbers (e.g., applying it to multiple
   downsampled version of data sets).

Done in Fig. 6. 

   * The authors claim that RBF volume rendering has teh same quality as
   cubic B-spline reconsttruction of structure data. This statement is not
   obvious and needs to be backed up.

Added an explicit image comparison in the teaser.

   Presentation:
   * I believe it is supposed to be "diffuse Phong illumination" instead of
   "diffuse and Phong shading".
   * herachy -> hierarchy.

Good catch! Thanks!

   Figure 1
   --------
   The comparison shown on Figure 1 is confusing: the authors used two
   transfer functions for the top image and one for the bottom image. How
   can the authors say that the top image is better? I'm not sure why the
   image on the bottom "exhibits noticeable loss in reconstruction quality".
   The difference seems to be due to the fact that the image rendered with
   the proposed technique uses two transfer functions, and not due to the
   reconstruction, i.e., the interpolation of the scalar field \Phi. The
   authors should explain in more details why one is better than the other.

Fixed — all comparisons in the teaser now use two fields.

   In Fig. 1, the authors used a dt = 1.0, \sigma  = 3.1, and 2 voxels per
   angstrom. What is the length of the integrated ray? What is the size of
   the domain? When reading the paper, I (incorrectly) assumed that the ray
   is parameterized in the interval [0,1], but this is clearly not the case,
   since the dt=1. The authors should provide more details about the
   dimensions of the datasets so that the reader would have a better idea on
   the numerical errors involved in the approximation used.

Done. In the first paragraph of Sec 6, we clarify that all units are in domain space (Angstroms or CubeP3M unit cells). 

   Equation (3) and Listing 1.
   ---------------------------

   In Equation (3):

   I(t) = \int C(\Phi(t)) \alpha(\Phi(t)) \exp( -\int_a^t \alpha(\Phi(s))ds
   ) dt

   The function I(t) does not depend on t. Instead, I is parameterized by
   the pixel position (x,y). Thus, I(x,y) is more appropriate. What is $a$
   in the Equation (3)? It should start at zero.

Thanks — I tried to simplify the DVR integral some things are best not tampered with.
I went off of the formulation of Sabella 1988

   The authors assume that \alpha is the opacity transfer function, and not
   the extinction coefficient \tau, as described in Nelson Max's "Optical
   Models for Direct Volume Rendering" (which should be referenced).
   Typically, \alpha is approximated as \alpha = 1 - exp(-\tau * d) and
   further approximated as \alpha = \tau * dt. Thus, when the user builds
   the transfer function \alpha, it automatically specifies the product \tau
   * dt. This means that line 3 in Listing 1 should use 's.a', instead of
   's.a * dt' in the exponent.

Thanks for the Max95 citation, definitely appropriate.
Good point about tau; I always conflate alpha with anything involving opacity, but that was a bad idea in this case. I was trying to keep the code as simple as possible and introduce dt in the right spot.

I think the choice of whether or not to premultiply by dt is arbitrary; I always leave it in (prevents artifacts when taking nonuniform step sizes, at some small extra cost).

   Also, Listing 1 does not seem to be a correct discretization of the
   Equation 1. Please, check that algorithm for typos or add a reference. It
   seems that the correct discretization (assuming a front-to-back
   algorithm) should be something like:

   void dvr_integrate(float Phi, Ray ray, TransFunc tf){
        Color s = shade(tf.classify(Phi))
        ray.color.rgb += s.rgb * (1 - ray.color.a) * s.a
        ray.color.a += (1-ray.color.a) * s.a
   }

   Example: by assuming that \alpha = 1, i.e., opaque, dt = 1, and C
   constant, the algorithm shown in Listing 1 will not return the correct
   color value (which is C):

   Iteration 1
   ray.color.a = 0 + 1 - exp(-1*1) = 0.63
   ray.color.rgb = 0 + C * 0.63 * (1-1) = 0

   Iteration 2
   ray.color.a = 0.63 + 1 - exp(-1*1) = 1.26
   ray.color.rgb = 0 + C * 1.26 * (1-1) = 0,

   whereas the above algorithm will return:

   Iteration 1
   ray.color.rgb = 0 + C * (1-0) * 1 = C
   ray.color.a = 0 + (1-0) * 1 = 1

   Iteration 2
   ray.color.rgb = C + C * (1-1) * 1 = C
   ray.color.a = 1 + (1-1) * 1 = 1

   which is the correct output. It follows an implementation that assumes
   constant color and opacity (http://jsfiddle.net/AWCbU/4/).

  Thanks very much for catching that — you are absolutely right. It turns out I’d hastily conflated “alpha” with another variable that was really alpha*(1-ray.color.a). I’ve hopefully corrected this with the following snippet:

  Color s = shade(tf.classify(Phi))
  float alpha = 1 - exp(-s.a * dt)
  ray.color.rgb += s.rgb * (1 - ray.color.a) * alpha
  ray.color.a += (1 - ray.color.a) * alpha

and I’ve elaborated on where we get dt.

   Results
   -------
   The authors have introduced two improvements: packet of rays, coherent
   traversal with BVH. I'd like to see which of these improvements
   contributes the most to the speedups shown Table 2 and Figure 5. What
   happens if a packet of rays contains a single ray?

Discussed above. Unfortunately there’s no easy way to revert to single-ray in bnsView. However, related methods using structured volumes have shown the advantage of using packets with SSE (see e.g. Knoll et al. 2011 “Full Resolution Interactive CPU Volume Rendering…”; with MIC and 16-wide vectorization the effect should be much more pronounced. I’m writing this into things we’d like to pursue in future work; it should be straightforward with new compiler technology coming down the road.

   List of minor issues and suggestions
   ------------------------------------
   * It flexibly reconstructs … -> It reconstructs …

   * … enabling better insight than surface-based visualization. -> …
   enabling better insight than surface-based visualization in many
   application.

   * tens- to-hundreds … -> tens- to hundreds- …

   * steps;large -> steps; large

   * More recent GPU implementations, e.g. using a grid acceleration
   structure [RKN*13] have proven -> More recent GPU implementations, e.g.
   using a grid acceleration structure [RKN*13], have proven

   * There is no need for the paragraph "The paper is organized as
   follows:…" because the authors do not offer any interesting way of
   navigating through the paper, but only the canonical way starting with
   Section 2 and ending at Section 7.

   * 3D scalar field by reconstructing the field at sample points -> 3D
   scalar field by evaluating the field at sample points. The authors use
   'reconstruction' where 'evaluation' is more appropriate (since we are
   talking about function evaluation at a specific set of points).

   * using basis functions from the SPH data for reconstruction. -> using
   basis functions from the SPH data for image reconstruction.

   * The same general method -> The same method

   * We refer to this more general technique as RBF volume rendering. -> We
   refer to this class of techniques as RBF volume rendering.
   The word 'class' is more suitable in this context, as 'RBF volume
   rendering' is not more general than 'volume rendering' but only subset of
   it.

   * Yt [TSO*11] converts -> Turk et al. [TSO*11] convert

   * Add line numbers to all Listings.

   * as shown in Figure 4: -> as shown in Figure 2:

Done all of these.

   * Figure 2: As I understand, the set of rays composes a packet. So, I
   suggest that the authors remove 3 of the four rays so that the concept of
   packet is left for Figure 3. This will help reader to see the distinction
   between a standard ray integration and a packet-based approach. Also,
   there is no need for the insets in the bottom.

I removed the code snippets, but I was trying to convey that the samples are physically close together. Hope it is ok to leave that figures as-is?

   * Reconstructing \Phi(x) requires determining -> Evaluating \Phi(x)
   requires determining

   * Remove '(SOA)': No need for another acronym (appears twice)

I removed the first sentence where I spell it out. 

   * Use semi-colon (;) at the end of each item after the sentence: 'our
   algorithm is fundamentally new in that:'

   * e.g. it reconstructs F for samples along -> e.g. it evaluates F for
   samples along

   * front to back -> front-to-back (check all)

All fixed, thanks.

   * and integrates these samples front to back (Equation 3). -> and
   integrates Equation 3 using the front-to-back algorithm shown in Listing
   1.

   * Use semi-colon (;) at the end of each item after the sentence: 'For
   each packet, we then do the following'

   * K = texit - tenter / dt -> K = (texit - tenter) / dt

Good thing this paper isn’t code! You just caught a bug ;)

   * For larger data in particular, -> In particular, for larger data

   * K=32 samples) -> K=32 samples

   * Use semi-colon (;) at the end of each item after the sentence:
   'Specifically, CPU and MIC offer'. Check all.

   * herachy. -> hierarchy.

   * t = 0 (incorrect font)

   * IEEE TVCG -> IEEE Transactions on ….. Make all references consistent.
   Check all TVCG, TOG, and others.

   * (to appear). Isn't this paper already published?

All of the above are fixed — thanks!

Thank you for that very thorough review!!!

------------------------ Submission 268, Review 2 ------------------------

   contribution of the paper is a bit vague. Major part of the system was
   already published [KWN*13] except computing the RBF using fixed-size
   buffers(Phi-buffers) instead of using a uniform grid proxy, which means
   that memory overhead might be reduced (or could be same or increased for
   the datasets used in the paper) but this might cause slower rendering
   speed. I think this is already a good progress but it would be good to
   compare this paper with the previous publication. 

Pretty much the only thing they share is the BVH and ball-and-stick. This paper is a fairly new approach to RBF volume rendering. 

But the concern is noted — we expand on the comparison with KWN*13 in Section 6. 

   Now I am wondering what
   the new contribution of this paper is, other than Phi-buffer. This makes
   me think that the work is incremental. Therefore I think the authors
   should stress out the new contributions compared to the previous
   publications in terms of memory and quality. Especially I would like to
   see the memory usage changes to provide sufficiently high quality
   results. Also it would be good to provide good reasons to build up the
   direct RBF evaluation instead of using a high resolution proxy although
   there is sufficient memory on CPU side. One minor thing is that “Figure
   4” on Page 3 should be “Figure 1”.

The memory, quality and (surprisingly) performance considerations are what make this worth doing. We’ve added a paragraph in section 6 and discuss this more explicitly.

------------------------ Submission 268, Review 4 ------------------------

Novelty concerns are noted. Our argument is that:
- there are very few published systems on CPU and MIC
- known (published) GPU approaches for doing this are not all that fast
- there is a clear need from HPC for these algorithms
- this is a way of doing it that hasn’t been done before

   General:
   --------
   There are several expressional and spacing errors in the text, e.g.
   - "tens- to-hundreds"
   - "steps;large"
   - "with K=32 samples)"
   - "we describe implementation"
   - "can classify separate field using"
   - "high- quality"
   Please review you own text in detail.

Thanks, doing a more thorough revision!

   Abstract:
   ---------
   Please be more careful with the term interactive. Even with grace, 1 fps
   is definitely not interactive.

Fast is relative; considering that the state-of-the-art tools in this space are offline batch, and the last published GPU paper ran at 0.1 fps for a 40M particle data set, 1 fps is almost in the interactive realm. But I agree; I’m replacing “interactive” with “semi-interactive” where appropriate.

   1. Introduction
   ---------------
   The limitations of multi-field classifications in the approach of FAW10
   should be elaborated in more detail. In the cited paper, two quantities
   are resampled into the grid and there seems to be no reason that at least
   up to four quantities can be resampled into a volumetric RGBA texture,
   which should be sufficient for the majority of cases.

That is true, but the grid has to grow in size to accommodate that. The FAW10 algorithm will face memory pressure far earlier than this approach; in practice that means they would have to reduce the proxy size (lower quality) or proceed in multiple passes (slow).

   Figure 1:
   ---------
   Instead of a split image with both modes I would rather wish to see a
   direct comparison of the same image with a zoom-in comparison for the
   printed version.

Done in new teaser. Good point.

   2.1 Volume rendering of point data
   ----------------------------------
   Missing references:
   - [OKK10] Jens Orthmann, Maik Keller, and Andreas Kolb, Topology-caching
   for dynamic particle volume raycasting, Proceedings of the Vision,
   Modeling and Visualization Conference, Eurographics Ass., 2010, pp.
   147–154.

Added. Thanks. 

   Furthermore, you should again be careful in writing that FAW10 filters
   pixel using a proxy volume. This is not true when a full resolution grid
   is used (see also the comments on scattering vs. proxy below).

Good point. I changed “proxy” to “grid” in one spot where I was suggesting that. 
I could be wrong, but I believe in most cases in the FAW10 paper the authors used a downsampled grid to achieve better performance (either that or the image resolution is relatively low). In practice, theirs is not a “bad” approach; the results look great. The only casualty might be sharp (i.e. aliased) surfaces using certain transfer functions.

   Listing 1:
   ----------
   * Since listing 1 represents more precisely a blending step than an
   integration, the function might be named dvr_blend instead of
   dvr_integrate.

Done. 

   * the attribute "color" is the only attribute that is used from the
   parameter "ray". Accordingly, the function is far better to understand if
   you would use "void dvr_blend(float Phi, Color c, TransFunc tf)" instead.

I left it that way because the traversal/TF might want to modify the ray (e.g., ray tracing, path tracing).

   * What does the shade function compute? Shading is not possible since the
   return value of tf.classify(float Phi) is obviously a color.

It uses that color as a material and does diffuse Phong shading. But I agree “Color” is left to the reader’s imagination. Can’t think of any better alternatives…  if you can will be happy to modify.

   3.1 Radial Basis Function
   -------------------------
   It should be noted, that the dynamic change of the support radius might
   require and update of the BVH, which is only interactive for small data
   sets with tens of thousands of particles.

Because of how we traverse the BVH, order of traversal doesn’t matter and the width of nodes can be updated dynamically. This means changing support radius doesn’t require updating the BVH. I now state this explicitly in Sections 5 and 6.

   3.3 Reconstruction
   ------------------
   Your classification of the reconstruction options are unconventional and
   rather imprecise. The distinction in literature are "gathering"
   (collecting the contributions from neighboring particles per sample) and
   "scattering" (distribution the contributions to the neighboring samples
   per particle). In general, both methods yield the same result (apart from
   numerical issues).

   A proxy method is a modification of the scattering approach by sampling
   the scalar field into a proxy grid (or other data structure) which is
   resampled using some kind of filtering for the actual volume rendering.
   Please take care to distinguish these techniques in your description as
   well as in Listing 3 and Figure 2. In particular in Listing 3, it is not
   apparent whether Phi_grid(t) accesses existing samples or performs a
   filtering step from a proxy grid.

Added that terminology in Section 3.3, right after mentioning the “direct” and “proxy” methods.

I removed the pseudocode for the methods, because it was slightly too detailed and we are running low on space with the new results. 

   Figure 2:
   ---------
   It is not apparent that in the bottom part of the image you try to
   highlight the elements that have an impact on the sample point. You might
   emphasize this by additional arrows from the particles/vertices to the
   sample point and/or by extending your description.

   4. RBF DVR with Coherent BVH Traversal
   --------------------------------------

   Note, that the benefit of a more coherent memory access is a common
   feature for all techniques using a scattering approach.

   Regarding the four aspects that are meant to be fundamentally new:

   1) "by computing…"
   - As mentioned before, packets have already been used (e.g. by Orthmann)
   for SPH data.
   - The term "per-frame" is misleading and seems to be wrong. If the
   meaning should be that the sampling is done for the whole "frame buffer"
   it is not correct since resampling is performed into a volume with a
   certain depth. If it is meant "one per frame", this is not different to
   the approach presented in this paper.

I see what you’re saying; it is a subtle difference. Instead of saying “per-frame”, I should have said “across the entire image”. 

In practice, it’s a fairly technical difference between broader parallel sampling and deeper parallel sampling. 

I modified this in the bullets in Section 4.

   - as stated before, in FAW10 there is also no subsampling needed when
   using a full resolution volume.

   2) "with coherent…"
   - In every method using scattering, each particle is "traversed" only
   once.

Good point. 
\item with \emph{coherent BVH traversal}, the nodes of the acceleration
  structure (as well as particles within) are traversed only once, improving
  efficiency;

   - Empty space skipping is also not fundamentally new, but can be employed
   rather easily when using space partitioning data structures

Agreed, but we’re able to use the same structure that’d you’d use for ray tracing; that’s what I’m trying to say there (not that accel. structs are new).

   - on the first glance, the approach should scale worse than methods using
   some kind of LOD since the LOD eliminates the linear dependency of the
   number of particles. If I should be wrong, this needs to be clarified in
   much more detail.

In theory, anytime you use a tree structure you are changing rendering cost from linear to logarithmic, LOD or no. LOD just makes that linear part just a little bit smaller (and memory access a lot better).

   3) "using object-…"
   - There is no apparent reason why any spatial subdivision structure (i.e.
   also kd-trees or octrees) can not be used to accelerate ball-and-stick
   ray tracing as well.

Fair point; I rephrased that to say “we use the \emph{same structure} for both RBF volume rendering   and ray tracing of ball-and-stick geometry”

   4) "by performing…"
   Multiple passes and early ray termination are actually employed in FAW10.

True, but it’s more likely that a small packet would have terminated than an entire (broad) image buffer. I rephrased it as follows:
  \item by performing this integration in multiple passes, we are able
  to further lower the memory requirements of our buffer, and take
  advantage of \emph{early ray termination} on a per-packet basis.

   Listing 4
   ---------
   - the listing should be placed beneath the text block with reference to
   it.
   - the function phi(...) is not trivial and needs to be explained! From
   the description at the beginning of the section, this should be a loop
   over all particles within a packet scattering. It is unclear how this is
   efficiently performed in parallel using SIMD vector instructions, which
   is of fundamental importance. Furthermore an outer loop over t and an
   inner loop over all particles is contradictory to the note that each
   particle is traversed only once.

I’ve spelled this out, replacing “packet” with “varying Ray”. It should be more straightforward now.

   - Furthermore it is not mentioned how the distinct directions of the
   single rays determined based on the direction of the whole package. Even
   though this is rather trivial there are different options and should be
   briefly noted, which one was used by the authors.

In coherent BVH traversal, single rays are only traversed when a leaf node is hit and every ray needs to intersect every object.

   - Accordingly, the term "packet.color.a" represents a vector as well and
   should be written as "min(packet.color.a)" to be precise.

I used “all” instead, makes more sense for a boolean.

   4.1 Coherent RBF volume rendering algorithm
   --------------------------------------------
   The statement that packets instead of rays are used in phi() and
   dvr_integrate() should be placed near Listing 4.

This whole process is now spelled out in more detail in 4.1. 

   6.1 Overall performance and quality
   -----------------------------------
   - The effect of early ray termination needs to be evaluated in terms of
   performance (timings with and without for a set of images). In all
   images, the transfer function is set such that the particles are rendered
   almost opaque and the rays will terminate very early. Direct volume
   renderings on the other hand (e.g. in the field of astrophysics) are
   often highly transparent and therefor do not profit from this
   optimization.

Done in Sec. 6 and Fig 6.

   - The resolution for the resampled is stated to be 1 voxel per Angstrom
   in the paragraph whereas Figure 1 states 2 voxel per Angstrom.

Fixed — I used 1 voxel per Angstrom everywhere in the paper now for consistency.

   Figure 4
   --------
   - What are the reference scenes? Those from Table 2?
   - what does "dt of 0.5" stands and what is its unit?

Yes. dt is in world (domain) space units, e.g. Angstroms or unit cells. This is now stated in Sec 6 at the top.

   Figure 4 and 5
   --------------
   - Having experience in the field of astrophysics, the shown images seem
   not be meaningful at all. Please take a look at volume renderings on
   astrophysical data sets to improve the renderings.

To be fair, astrophysics images never look good at 1”x1” in a paper; they always look like a tiny uniform block. I’ve used an alternate rendering for that data in the scalability benchmark in Fig. 5; I am not sure it is much better but at least there is more contrast.

   - Furthermore most of the other images seem not to be particularly
   meaningful as well. They reveal primarily an outer shell and no
   information inside the data set or a video, in which the effectiveness
   with different transfer functions is shown.

These are mostly for benchmark purposes; but I think at least in many of these it is more useful to be able to separate the atoms than not.

------------------------ Submission 268, Review 5 ------------------------

   In general the structure of the paper is good  but I would recommend the
   authors to reduce `some text in the section 5, because some subsections
   are over explained and they are not relevant for the paper in general,
   for instance section 5.1. Section 5.6 is claimed as a major contribution
   but the current text is not clear enough to validate it, a little more of
   details would be very useful.

Done. 

   From my point of view, the weak part of the paper is the results section.
   Some statements are not well justified with the results, specially on
   section 6.1. I encourage the authors to rewrite this section and try to
   be precise on their discussions. Regarding the references, the most
   important and related works are cited correctly.

Done: major rewrite in Section 6.

   Some minor changes:
   * Can Figure 1 be captured using the same camera parameters in order to
   compare the subimages?

Done

   * Section 3.3: it references to Figure, but it should be Figure 2

Fixed, thanks.

   * Section 4.2: misplaced ‘)’

Fixed.

   * Section 5.6: “An advantage of direct RBF volume rendering the ability
   to construct multi-field volume …” should be “An advantage of
   direct RBF volume rendering is the ability to construct multi-field
   volume… ”

Thanks!

   * Section 6.1: What does “.5-10 fps range on the CPU” mean? Is there
   any typo?

Nope, 0.5–5 fps at 1024^2. But actually, the CPU results are generally a bit better than that; it’s really more like 0.5-10 fps.

   * Figure 3: caption should be improved.

I added the explanation:  “In this manner, particles can be added to the buffer in any order, allowing for traversal of each particle once per packet and improving memory access.”