The paper suffers from several large problems unbefitting a systems paper. Nonetheless, Reyes (be it program, architecture or algorithm) is important enough to deserve a good publication.

The paper goes into some detail in describing what is done, but detail is surprisingly lacking in other places. Worse, previous or alternate methods are not mentioned enough, and the relationship between Reyes and these other methods is not made clear. Sometimes the paper takes cheap shots at other methods without justifying either the attack or the alternatives.

When a choice is made in the design, the benefits of the decision made are well explained, but the drawbacks are rarely mentioned, and the particular decision made in Reyes is not compared to the related decisions made in other systems. The paper assumes the reader knows about all the other systems that have been done, and can read between the lines. If that is true for some readers now, it will not be true ten years on, so other systems should be compared against and referenced.

The greatest shortcoming in the paper is that, although Reyes is clearly a powerful rendering system designed and built by extremely good architects, the architects are only willing to share their design, not the wisdom that led to that design. If the paper is intended to help other designers, rather than merely announce the system, it must share enough insight to help other designers make (what you feel are) the right decisions, even though the designers have very different backgrounds. The paper must persuade, not just describe. Talk about decisions that were avoided, ideas that were rejected, and decisions that now seem to have been wrongly made.

Is Reyes an architecture, an algorithm, a piece of software, a piece of hardware, or some combination thereof? The paper never really says, but hints at lots of possibilities. Please be very clear on this. The title may even be wrong. Also, the structure of the system is never brought out, but that is one of the most important parts of a systems paper. You may not think this is a systems paper, but most of the ideas here have appeared elsewhere, and the paper is trying to explain how the ideas are used. That is one mark of a systems paper.

In other words, how is Reyes put together, and why is it put together that way? What does that structure help Reyes do well? Not well? (The Discussion section is mostly about the effect of specific algorithmic details.) How are object and image descriptions entered into the system? Also, it's common knowledge that Reyes is one big thing (maybe program), rather than a bunch of components. Is this true? If so, say so, and say how that affects things, and why it is that way. If not, you should correct the misconception. How robust is the system, both asymptotically and when new things are being added to it? How easy is it to add things?

The writing is choppy, with things missing. One recurrent problem is a need for the reader to refer repeatedly to figures and the glossary for definitions of terms that could be described briefly in the body of the text, without breaking the flow. The glossary is helpful, and should stay, but requiring the reader to refer to it for definitions of notation and terms is bad style. Related things: u and v are used before they are defined in the text; and the `first' and `second parts' of the algorithm are not defined anywhere.

Here are some specifics, in the order that they appear in the text. Many of the specifics can be handled collectively by rearranging somewhat and explaining things better in relatively few places. The detail here is to give you ideas for improvement, and are not necessarily to be addressed explicitly.

The abstract is too much of a summary and not enough of an invitation to read. It does not explain why the reader should press on.

The beginning of the paper has too many `we's. They die down later, though.

1. Introduction

PP1: This paragraph is bad English.

PP2: Do you meet these ambitious goals? Saying so up front would urge the reader to continue reading. You mention ``the problem.'' What is it? ``radically new ideas:'' Let the reader decide. Just say they're new. ``The emphasis is on the overall structure'' is a good thing to say, but the paper doesn't really back up the claim.

List: Is the ``problem'' being addressed by the architecture or the paper? You don't define ``primitives'' very well anywhere. When first mentioned, they are immediately described as being possibly complex, which implies they are not primitives by most definitions. The relationship between texturing and things like refraction is never adequately described. (Referring to a movie [22] is not helpful.) Why is ``pixels'' in quotes? The architecture is claimed to be optimized for complex geometries and not for ray tracing. Aren't modelling and rendering mostly independent? If you think not, we'd like to know why. Ray tracing is clearly sufficient, but you shun it. Say why; we may be able to guess, but might like you to back up our opinions. The speed goal is a worthy one, but (at the end of the paper) you only say it performs ``reasonably well'' and give one number for the CPU time on a machine few people know about. How long would another system take on a similar image? ``all that more difficult'' is not English. You give examples of aliasing but not faceting. Finally, how is flexibility achieved? This is one thing the paper never addresses explicitly.

2. Principles of the Algorithm.

(An algorithm now?) Justify the use of natural coordinates, or at least say what the alternatives are and why they are inappropriate. Architectures cannot ``exploit vectorization, parallelism and pipelining.'' They can only avoid preventing it. This is one of the places where the reader wonders just what Reyes is. The paragraph on ``Vectorization'' needs more rationale. ``Flat-shaded subpixel-sized quadrilaterals'' is indeed a viable common representation. Why was it chosen? Such precise definitions do not arise fully formed: tell us how you arrived at this design. The Back Door is indeed a ``general way'' but it's also a cop-out. (The word software appears here, enticingly.) More words about textures would be welcome. We'd like to know how you arrived at this list of ``principles.''

2.1 Geometric Locality

Again, more about how texture maps can be used to help. ([22] is insufficient reference, and ``can be computed in a prepass'' is also saying little.)

2.2 Point Sampling

PP2. Is the z buffer pixels, subpixels, or what? Whatever happened to A-buffers? If you don't use them any more, say why. The objects in a scene ``that require ray tracing'' are possibly transparent, which will cause trouble in a z buffer.

PP3. Here, as in many other places, you're brushing off other ideas (and the reader) instead of informing.

2.3 Micropolygons

PP1. Why micropolygons? The sentence about antialiasing doesn't tell enough of the story: randomizing doesn't antialias.

PP2. Dicing is not well described. How do you know when to stop? The claim about storage is unconvincing unless the primitive is uniformly far from the eye when the dust has settled; otherwise excessive detail will be computed for distant parts of the primitive. However, ``dicing is done in eye space,'' not screen space; yet dicing stops when the micropolygons are ``half a pixel on a side in screen space.'' What is really going on?

PP3. ``required to model'' should be ``taken to model.'' But that opens another question: how is modeling done by the users of Reyes?

PP4, and list: The list claims to explain the advantages of micropolygons, but has more to do with subdivision. Everyone believes in subdivision; you should be convincing us about micropolygons. The first few items may, in your minds, be specific to micropolygons, but you should be clearer about where the benefits lie. The ``other architectures'' listed in the second item should be referenced. ``Displacements maps:'' Why is this statement relevant?

2.4 Texture locality.

PP1. The business about s,t vs. u,v is silly. Just define what you want to use.

The long paragraph on page 9 is excellent. It's just what the rest of the paper should be like. Some nits: you're a bit fast and loose with the descriptions of when filtering is done, and the last sentence of the paragraph doesn't explain what's up. ``pixel texture access'' is jargon, but relevant jargon. Explain.

3. Description of the Algorithm.

PP1. What about shadowing?

PP3. Decide how you want to spell u-v space. ``The first part of the algorithm:'' see above.

PP4 and list: This is fascinating, and hints at the structure. Say more about how and when these routines get linked in to the system and called. The language makes it sound almost object-oriented, although that's probably not accurate. What are the parameters to control dicing and splitting, and how are they made available to the routines? ``The most common reason for this is simply that no dicing code has been written for the primitive:'' What are we supposed to infer from this?

This section should say much more about ``the structure.''

PP5. ``used for culling....to produce micropolygons'' is confusing.

PP6. Do you really mean to ``obviate CAT filtering?'' Say more if so.

4. Extensions

How are extensions added to the ``architecture'' as opposed to the implementation?

5. Implementation

This section does not say what the implementation is. It doesn't even say that the code is written in C; it seems deliberately to avoid doing so. Describe the implementation.

PP1. ``Because that bucket will now remain empty:'' Explain.

Give more performance figures.