I think the links here are fairly useful, in part due to great suggestions from people on Twitter – get them while they’re fresh. Let me know what other cool things I’m missing.

I also update our own site’s portal page and graphics books page for good measure. One cool new link on the portal page is for Shader School, for learning shader programming, which a few people have recommended. The shader compile error messages are unfortunately obscured on some platforms, but if all else fails you can check the answers.

]]>http://www.realtimerendering.com/blog/web-page-updates/feed/0WebGL MOOC this summerhttp://www.realtimerendering.com/blog/webgl-mooc-this-summer/
http://www.realtimerendering.com/blog/webgl-mooc-this-summer/#commentsTue, 28 Apr 2015 00:56:15 +0000http://www.realtimerendering.com/blog/?p=3928Want to learn computer graphics using WebGL from a MOOC during the summer? Learn for free from a master, Ed Angel, at Coursera.
]]>http://www.realtimerendering.com/blog/webgl-mooc-this-summer/feed/1Why not?http://www.realtimerendering.com/blog/why-not/
http://www.realtimerendering.com/blog/why-not/#commentsFri, 24 Apr 2015 19:04:22 +0000http://www.realtimerendering.com/blog/?p=3900I like to ask researchers whether they think the release of code should be encouraged, if not required, for technical papers. My argument (stolen from somewhere) is, “would you allow someone to publish an analysis of Hamlet but not allow anyone to see Hamlet itself?” The main argument for publishing the code (beyond helping the world as a whole) is that people can check your work, which I hear is a part of this science stuff in “computer science.”

Often they’re against it. The two reasons I hear are “my code sucks” and “we’ve patented the technique.” I can also imagine, “I don’t want those commercial fatcats stealing my code,” to which I say, “put some ridiculous license on it, then.” If the reason is, “I want to publish to enhance my resume and reputation, but I also want to keep it all secret because I’m going to make money off it,” then choose A or B, you can’t have both (or shouldn’t, in my Utopian fantasy world).

Don’t worry about code quality. I love “there are codebases that suck, and there are codebases that aren’t used“. This quote was by a lead programmer on one of the best selling videogame development platforms, Unity3D; he got it from someone else. Show us the code, we won’t laugh (much). It doesn’t have to be easy to build. For example, MeshLab, for me at least, is about impossible to build, and has (or had – they’ve improved considerably over the years) some horrific bugs, but I still appreciate that the code is available to look at. I also use the program a lot, I just reached my hundredth use of it this week.

It takes a few minutes to slap your source files onto Github and costs nothing. If you’re worried about code quality, don’t – you’re in good company, about 90% of all code on Github is crap (Sturgeon’s Law), including my own (the executable of which gets like 15,000 downloads a month). Notch’s $2.5 billion code for Minecraft sucks. Let it go.

Patents: I admit to not liking most software patents, perhaps all. But that’s irrelevant, or should be. If you’re embarrassed to admit you have a patent on some algorithm, that shouldn’t stand in the way of others understanding your research – deal with your shame. The point of a patent is that you are revealing the process. In return your idea is protected for a number of years. This is as opposed to a trade secret, where the process is kept quiet. A patent stops others from using your idea without paying you a licensing fee. However, your part of the bargain is to explain the idea. A trade secret risks someone reverse engineering your clever idea, for which you have little protection. Obvious, but people seem to forget that.

I expect these arguments are entirely convincing and code publication still won’t happen, due to pride and lawyers. No one likes to show off their dirty laundry. And lawyers will see no benefit to revealing code: “What’s this ‘research’ stuff you’re talking about? We’re making I.P. here, not research. Releasing code will increase the risk of undetected infringement by others of our I.P., or, worse yet, we might be found to be infringing on someone else’s algorithm patent.”

Ah well, I tried. Now get off my lawn.

]]>http://www.realtimerendering.com/blog/why-not/feed/1New CRC Bookshttp://www.realtimerendering.com/blog/new-crc-books/
http://www.realtimerendering.com/blog/new-crc-books/#commentsFri, 24 Apr 2015 16:05:31 +0000http://www.realtimerendering.com/blog/?p=3867Well, newish books, from the past year. By the way, I’ve also updated our books list with all relevant new graphics books I could find. Let me know if I missed any.

This post reviews four books from CRC Press in the past year. Why CRC Press? Because they offered to send me books for review and I asked for these. I’ve listed the four books reviewed in my own order of preference, best first. Writing a book is a ton of work; I admire anyone who takes it on. I honestly dread writing a few of these reviews. Still, at the risk of being disliked, I feel obligated to give my impressions, since I was sent copies specifically for review, and I should not break that trust. These are my opinions, not my cat’s, and they could well differ from yours. Our own book would get four out of five stars by my reckoning, and lower as it ages. I’m a tough critic.

I’m also an unpaid one: I spent a few hours with each book, but certainly did not read each cover to cover (though I hope to find the time to do so with Game Engine Architecture for topics I know nothing about). So, beyond a general skim, I decided to choose a few graphics-related operations in advance and see how well each book covered them. The topics:

Overall this is a pretty great book. It’s not meant as a graphics programming guide; rather, it’s more a course about all the aspects of actually programming a videogame. I’m impressed with its quick summaries of hundreds of different algorithms, techniques, and tools and what each is used for. It performs a valuable service, alerting the reader that a topic even exists and giving some sense of what it’s about, all in plain English. The main problem with writing about current practices is that the book is about two years old, so of course some newer techniques and tools are not covered. However, it gets you about 90% up to speed. The book is not full color, rather has color plates, and that’s just as well. Full color throughout would have been expensive and made the book quite heavy (possibly unpublishable) without adding a lot of value.

Antialiasing: generally good coverage, though it assumes the reader already knows what jaggies actually are. Discusses MSAA and FXAA, and notes the idea of MLAA. MSAA is described correctly and clearly. FSAA is covered briefly and (properly) dismissed. CSAA is covered, since at the time it was a thing. SMAA is not discussed, since it hadn’t really been picked up by games yet at the time of writing. There’s a minor typo on page 506, “4 X MLAA” when MSAA is meant.

Phong: the term Phong doesn’t appear in the index. Perhaps this is fair enough for Phong shading, which is often replaced with the more descriptive term “per pixel shading”. I blame my age and schooling for considering these to be important terms. This book has a bit of confusion on the subject, however, mixing per pixel evaluation with the implication that texture mapping fixes Gouraud shading artifacts (p. 462). This is too bad – I want to like everything about this book, since it gets so much correct. Phong illumination is not in the index, nor is Blinn-Phong. I did finally find Blinn-Phong and Phong under “lighting” in the index. In general the index is somewhat weak, as it has less cross-referencing than I would like. Presentation of Blinn-Phong is short and succinct, which is appropriate for the survey nature of this book. A set of thumbnails showing the effect of changing the exponent would have been useful. A long Wikipedia URL is given for more information; better would have been to say “Search on ‘Blinn-Phong’ on Wikipedia”, since no one will type in the URL.

Clip coordinates: Clip coordinates for a perspective view usually have a W value that’s not 1, and clipping is done on points that have X, Y, or Z values that are outside the range [-W,W] (when W is positive). Clip coordinates are what the vertex shader produces, so are important to understand properly. Unfortunately, this book gets this topic a bit wrong, but so do most texts. This text mixes clip space with Normalized Device Coordinates (NDC). This is a common “shorthand” used to explain clipping, but something of a false savings. We as humans tend to think about clipping against the NDC coordinates, but clip space is where clipping actually happens, before dividing by W. The book does point out something that is (surprisingly) rarely mentioned in other books, that along the z-axis NDC goes from 0 to 1 for DirectX.

Summary: despite my criticisms, four out of five stars, maybe higher. It covers a huge number of subjects, has much practical advice (e.g., performance and debugging tool recommendations), and is written in a clear and intelligent style. The author clearly cares about his subject and does his best to help the reader learn all about it. As important, he cuts the fluff – I didn’t see any signs of pet topics he cares deeply about that mostly don’t matter to the field. Finally, at $62.96 for a thousand-plus page book, a great price per page.

This book is about computer graphics in general. It has a focus on interactive techniques and uses WebGL for exercises (good plan!), but also tries to give a wider view of the field. Theory is favored over practice. One factor in favor of this book is that I haven’t (yet) found any serious errors. I would expect no glaring errors from these authors, researchers all. However, there are omissions or short explanations where a bit more ink would have been useful, along with a number of typos for important terms. At 375 pages (not including table of contents), this book overall feels condensed, given its scope. I sometimes found it terse and quick to jump to equations without enough background. To its credit, there are many helpful figures. The book suffers from not being fully in color, rather including just some color plates. The small book page size makes the text feel a bit crowded.

Antialiasing: somewhat abstract coverage, first talking about line rasterization in HSV space. Mentions full-screen antialiasing, mislabelling it FSSA, but fails to note that this is rarely done in practice. Important antialiasing techniques for interactive rendering, such as MSAA and FXAA/SMAA/MLAA, are not mentioned.

Phong: properly indexed and fully covered, and a warning given to the reader to not confuse shading with illumination. The difference between Phong and Blinn-Phong is covered, though it does not discuss that the exponent in each has a considerably different effect (Game Engine Architecture notes the exponent is “slightly different”, when in fact it’s about a factor of 4 different – see “R.E versus N.H Specular Highlights,” in Graphics Gems IV, also here). Oddly, fragment and vertex shaders are not listed in the index, though fragment shaders are presented in the text for the exercises. Typo, repeated in the index: “Match banding” instead of “Mach banding”.

Clip coordinates: not incorrect, just omitted. Clip space is briefly mentioned on page 117 and the text properly notes that it is not the same as NDC. Much else along the pipeline is dealt with in some depth, but clipping in homogeneous space is given a sentence. There is an interesting pipeline figure on page 121, but clipping is left out. DirectX’s range of [0,1] for the Z axis of its space is not mentioned. Classical clipping algorithms such as Sutherland-Hodgman are covered, but without mention of clip space vs. NDC space. Proper clipping for perspective views is feeling like a lost art to me. It’s an easy topic to skip – the GPU does all the clipping nowadays – but some brief coverage can help save students from screwing up the w-coordinate when writing vertex shaders. The best (and brief) online explanations I’ve seen are here and here, and by “best” I mean “basically correct”. More on this topic later.

Summary: an average of three and a half stars out of five, though it depends. This book contains solid information, could be used as a textbook for teaching graphics, or possibly a fairly-reliable (though terse) reference. It looks tough to plow through if you’re on your own, and it tends to be more theoretic than practical. In the long term, this theoretical bent is a good thing for someone learning this area - a proper foundation will serve anyone well for life, vs. memorizing ever-evolving APIs – but the book does not feel strongly connected to present-day practice. For example, it barely discusses the various types of shaders – vertex, fragment, geometry, etc. The fragment shader gets a paragraph, and no entry in the index. GLSL is mentioned but also does not have an index entry. The geometry shader is never discussed. In fairness, vertex and fragment shaders are indeed used in the WebGL exercises, there’s just not much explanation. Again, it feels like an abridged textbook, where the instructors in class would spend time on how to actually program shaders. I look forward to a second edition that is more fleshed out.

This book is tangentially related to computer graphics, but I mention it here anyway. Unlike most books about GPGPU programming, this one does not use CUDA, but rather uses DirectX’s DirectCompute. I can’t fairly assess this book, as I still haven’t taken on GPGPU.

While the book is ostensibly about GPU programming, computer graphics sneaks in here and there, and that I can comment on. Chapter 4, called “GPU Computing”, is the heart of the book. However, it spends the first part talking about vertex, pixel, and geometry shaders, rasterization, perspective projection, etc. Presenting this architecture is meant as an example of how parallelism is used within the GPU. However, this intent seems to get a bit sidetracked, with the transformation matrix stack taking up the first 8 pages. While important, this set of transforms is not all that related to parallelism beyond “SIMD can be used to evaluate dot products”. For most general GPGPU problems you won’t need to know about rendering matrices. 8 pages is not enough to teach the subject, and in an intermediate text this area could have been left out as a given.

Chapter 6, “Linear and Affine Algebra”, is an 84 page standalone chapter on this topic. It starts out talking about template classes for this area, then plows through the theory in this field. While an important area for some applications, this chapter sticks out as fairly unrelated to the rest of the chapters. The author clearly loves the topic, but this much coverage (a fifth of the book) does not serve the reader well for the topic at hand. I was strongly reminded of the quote, “In writing, you must kill all your darlings”. You have to be willing to edit out irrelevant pieces, no matter how sound and how much you love them. The author notes in the introduction, “I doubt I could write a book without mathematics, so I included chapter 6 about vector and matrix algebra.” The nature of the physical book market is “make it thick” so that it looks definitive. Putting tangential content into a book does the customer who is paying and spending time to learn about GPGPU programming a disservice. I don’t blame the author in particular, nor even the publisher. Most technical books have no real editors assigned to them, “real” in the sense of someone asking hard questions such as, “can this section of the book be trimmed back?” We have to self-edit, and we all have our blind spots.

Overall I’m a bit apprehensive about truly reading this book to learn about GPGPU programming. I had hoped that it would be a solid guide, but its organization concerns me. It seems to go a few different directions, not having a clear “here’s what I’m going to cover and here’s what you’re going to learn” feel to it. A lot of time is spent with groundwork such as floating point rounding rules, basic SIMD, etc. – it’s not until 123 pages in that the GPU is mentioned. The book feels more like a collection of articles about various elements having to do with performing computations efficiently on various forms of hardware. That said, Chapter 7, “Sample Applications”, does offer a fairly wide range of computational tasks mapped to the GPU. It’s a chapter I’ll probably come back to if I need to implement these algorithms. The author is a well-respected veteran and I trust his code to be correct. He’s done wonderful work over the years in growing his Geometric Tools site – it’s a fantastic free resource (at one point I even tried to find external grants to support his work on the site - no luck there. A MacArthur Fellowship sent his way would be great). What might have made more sense is a focused, stripped down book, half of chapter 4 and all of chapter 7, offered for $10 as an ebook treatise.

This book is, unfortunately, currently broken, because of a faulty index. The index page numbers are off by quite a bit. For example, Sutherland-Hodgeman (which should be spelled Hodgman - Angel & Shreiner’s Interactive Computer Graphics, a book I generally like, also makes that goof; no biggie) in the index is listed as page 589, but actually appears on page 556 – a 33 page error. This problem appears to be a scale problem. Entries early in the book are correct, e.g. clipping is listed as page 33 and indeed appears there. Selection is listed on page 184 and appears on page 174, a 10 page error. Near the end, homogeneous coordinates are listed as 879 but are actually 826. By curve fitting using Excel, the equation is:

Of the four books reviewed, this one has the nicest layout and presentation. Full color, wide format, with helpful figures in the margins. Stylistically, the author attempts a chummy style with frequent exclamation points. Expect passages such as, “By the way, do you even know what a floppy disc is, young reader?! If not, look it up on Wikipedia.” The author has a typographic conceit, heading various sections with arbitrary camelcase, e.g., ExpeRimenT, ExercisE, ExAmPlE. I can’t fully replicate the feel here, because the capitalized letters are actually lowercase but of varying font size. This might be a cute little flourish if the book was excellent. It’s not cute.

The book is in its second edition. Though the cover says “Comprehensive coverage of OpenGL 4.3″, what this means is that two extra chapters were added to the end of the book. Even then, these chapters are as much an introduction to OpenGL 2.0 as 4.3; for example, they are the first places GLSL gets discussed. I had a theory that the first edition of this book came out before 2004, which would explain the dependence on pre-shader OpenGL for the vast majority of the book. I was incorrect; the first edition came out in 2010. My impression overall is that the author misses the days of the fixed function pipeline. This is understandable, and I had the same dilemma designing an introductory course: when do you hit the students with shader programming? It’s possible early on, though mysterious. You need a fair bit of understanding of the transformations used, as well as what a shading model is, to really get traction. Old OpenGL, with its built-in shader model and simple, clear, and now-vastly-inefficient way of specifying triangles makes for an appealing teaching environment.

So, I understand the desire to not throw the students into the deep end on day one. However, given 919 pages to work with, GLSL should be mentioned much earlier than page 745, along with vertex and fragment shaders and all the rest. The book actually ends 75 pages later after introducing shaders, with the rest being appendices. So, it has 75 pages to cover everything that has happened to OpenGL since 2004. This is insufficient.

The bulk of the book includes tangential topics, such as scan-based polygon rasterization. Rasterization of polygons with concavities is not used by GPUs, so is mostly irrelevant, though possibly useful for teaching about parity. However, the algorithm is then presented incorrectly, worrying about singularities with ray/edge testing instead of using the proper rounding rules (in contrast, Eberly presents rasterization correctly, on page 133 of his GPGPU book). As I say, I skimmed this book, but noticed one strange grouping along the way: the perspective matrix and rational Bézier surfaces are covered in the same chapter. This feels like a Jeopardy! clue for Letters of the Alphabet, “Perspective and Bézier surfaces have this in common.” “What is w, Alex?” I shouldn’t joke, but I then uncovered such a deep flaw in the book that I, well, read on.

Antialiasing: the basic idea of pixel coverage is discussed as the solution, so that’s fine. Multisampling is skimmed over, being described as if it was supersampling. There is also a bit of filler on page 797 about how multisampling in OpenGL 4.3 is done exactly as described on page 527. There’s no reason to say this if there’s no change from “pre-shader OpenGL”. A few pages past this topic I noticed the accumulation buffer is covered. This functionality is rarely used nowadays and doesn’t appear in OpenGL ES, but again it can be useful for teaching about motion blur, antialiasing, etc. The book describes the accumulation buffer, but doesn’t explain what it is for – a missed opportunity.

Phong: the index does note Phong lighting vs. shading. The description of Phong shading is correct and concise, and its relationship to Phong lighting described properly. However, both Gouraud and Phong shading are not illustrated in any form (and this is a full-color book), e.g., showing specular highlighting and how it improves with per pixel evaluation. Phong lighting itself is explained, though the author does not note that what he’s covering is actually Blinn-Phong. Again, there is no simple image showing how varying the specular exponent changes the highlight. There’s an odd notation on Figure 11.14, “(not exact plots)” for the various cosine to a power curves formed by varying the exponent. Why not exact?

Clip coordinates: the coverage here is deeply incorrect, not just a typo or oversight. On page 703 the pipeline is given as perspective division followed by clipping; the correct way is clipping followed by perspective division. There is also an odd step 5, “Projection to the back of the canonical box”, but that’s a minor detail. The author does understand the incredible difficulties involved if you attempt to clip after performing perspective division (for starters, you have to deal with division by zero). He spends the next few pages creating some method to deal with “semi-infinite segments”, which he also discusses elsewhere when talking about clipping. I admit to not carefully wading through his presentation, as the standard way to clip works fine. Eleven pages later he resolves his difficulties by presenting the rendering pipeline again, with a revised step “Perspective division with mechanism to handle zero w-values” (his emphasis), still performed before clipping. He clearly loves projective spaces, having a 46 page appendix on the topic. Unfortunately, he missed Appendix A in Sutherland and Hodgman’s original paper, or Blinn and Newell’s followup. This is extremely upsetting to see. The author seems like a nice person and clearly knows a fair bit, but there appears to be at least one small but serious hole in his education. We certainly made goofs in our book, and there are sections which I’d love to improve, but we did our best to read through existing literature before inventing our own solutions.

I don’t think I need to give a rating. It’s unfortunate, and I’m more than a bit embarrassed and hesitant to post this review, but honestly can’t recommend the book to anyone (even with the index fixed). There looks to be much valid information in the text, but as soon as trust is severely lost, the book is no good to me.

[Update: Sumanta Guha, the author, was understandably bothered by this last review, posted to Amazon; his reply is here. I stand by my review; my main regrets are attempting to be witty by my comment, “It’s not cute” and by my Jeopardy quiz. I’ll leave those bits there, and please think less of me because of them (honestly). I should also clarify that his algorithm for performing clipping after division may be correct (as I say, I did not check it), but it’s incorrect to present such a pipeline in a book that uses OpenGL, as OpenGL performs clipping before division. – Eric]

I’m being a lazy reporter here, simply passing on the press release. That said, of all the research-oriented gathering out there, this one I find the most relevant to what I do (well, GDC, too, but HPG is better for new ideas, vs. the “proven implementations” seen at GDC). This year the HPG committee is trying to include topics relating to emerging display technologies e.g. virtual and augmented reality.

High Performance Graphics is the leading international forum for performance-oriented graphics and imaging systems research, including innovative algorithms, efficient implementations, languages, parallelism, compilers, hardware and architectures for high-performance graphics. The conference brings together researchers, engineers, and architects to discuss the complex interactions of parallel hardware, novel programming models, and efficient algorithms in the design of systems for current and future graphics and visual computing applications.

High Performance Graphics is co-sponsored by Eurographics and ACM SIGGRAPH. The program features three days of paper and industry presentations, with ample time for discussions during breaks, lunches, and the conference banquet. The conference is co-located with SIGGRAPH 2015 in Los Angeles, United States, and will take place on August 7–9, 2015.

High Performance Graphics invites original and innovative performance-oriented contributions to the design of hardware architectures, programming systems, and algorithms for all areas of graphics, including rendering, virtual and augmented reality, ray tracing, physics, animation, and visual computing. It also invites contributions to the emerging area of high-performance computer vision and image processing for graphics applications. Topics include (but are not limited to):

Hardware and systems for high-performance graphics and visual computing

]]>http://www.realtimerendering.com/blog/cfp-hpg-2015/feed/0Limits of Triangleshttp://www.realtimerendering.com/blog/limits-of-triangles/
http://www.realtimerendering.com/blog/limits-of-triangles/#commentsMon, 10 Nov 2014 16:42:59 +0000http://www.realtimerendering.com/blog/?p=3836You’re mapping a latitude-longitude texture on to a sphere. Pretty straightforward, right? Compute the UV coordinates at the vertices and let the rasterizer do the work. The only problem is that you can’t get exactly the right answer at the poles. Part of the problem is that getting a good U value at each pole is problematic: U is essentially undefined. It’s like asking what longitude you’re at when you’re sitting at the north pole – you can take your pick, since none is correct.

One way around this is to look at the other vertices in the triangle (i.e., those not at the pole) and average the U values they have. This gives a tessellation at the north pole something like this:

What’s interesting about this tessellation is that it leaves out half of the horizontal strip of texture near the pole. The sawtooth of triangles will display one half of the texture in this strip, but will not display the triangles covered in red. Even if you form these triangles, adding them to the mesh, they won’t appear. Recall that all points along the upper edge of the texture are located at the same position in world space, the north pole of the model itself. So any red triangles added will collapse; they’ll have zero area, as their two points along the top edge are co-located.

I show a different tessellation along the bottom strip of the texture, a more traditional way to generate the UV coordinates and triangles. Again, all the triangles with edges along the bottom of the texture will collapse to zero area, and half of the texture in the strip will not be rendered. The triangles that are rendered here are somewhat arbitrary – at least the triangles along the top edge have a symmetry to them.

There are two ways I know to improve the rendering. One is to tessellate more: the more lines of latitude you make, the smaller the problem areas at the poles become. The artifacts are still there, but contained in a smaller area. The other, ultimate solution is that you could compute the UV location per pixel, not per vertex.

That works for texturing, if you can afford to fold the spherical mapping into the pixel shader. However, this problem isn’t limited to spheres, and isn’t limited to textures. Another example is the cone and having a normal per vertex. This is a common object, but is surprisingly messy. For a cone pointing up you typically make a separate vertex for each triangle meeting at the tip, with a separate normal. This is similar to the uppermost strip for the sphere mapping above: the normal points out in a direction somewhere between the two bottom normals for the triangle in the cone.

However, you have the same sort of interpolation problem! Here’s a cone with a tessellation of 40 vertices around the top and bottom edges:

From triangle to triangle along the side of the cone, you have normals smoothly interpolating along the bottom of the cone. Moving across a vertical edge near the tip, you have sudden shifts in the normal’s direction as you go from one normal to another. Each zero-area triangle that is formed by two points touching the pole is what “causes” the discontinuity in shading when crossing an edge.

If you start to add “lines of latitude”, to vertically tessellate the surface, things improve. Here are cones with two strips of triangles, three strips, then ten strips:

It’s interesting to me that the first image, two strips of triangles, doesn’t fully improve the bottom part of the cone. Even though there are no zero-area triangles and so the normal is the same for each vertex in this area, the normals change at different rates across the surface and our eyes pick this up as Mach banding of a sort. Three strips gives three bands of poor interpolation, and so on. With ten bands things look good, at least for this lighting and amount of specularity. Increasing the tessellation gets us closer and closer to the ideal per-pixel computation.

Here are some images of the cone mapping to show the discontinuities. The first gives a low tessellation: 10 vertices around, no tessellation vertically

Half of the texture is missing on each face of the cone. If you increase the vertical tessellation, like so:

You get this:

It’s better, but there’s still a dropout at the tip (it should say “1,0 | 0,0″), plus you can see the lines on the surface are not straight – the vertical lines on the faces wobble. Each quadrilateral is a trapezoid, so using two triangles for this mapping doesn’t match it all that well.

If you increase the tessellation in both directions, you get closer still to a per pixel mapping, the correct answer:

This tessellation is 40 points around, 10 points from bottom to top. The very tip still has half its information missing, but otherwise things look reasonable. Cranking the resolution up to 50 around and 50 from bottom to top mostly cleans up the tip (ignoring the lack of high-quality texture sampling):

This is an old phenomenon, but still a surprising one, at least to me. We’re used to tessellating any higher-order surface into triangles for rasterization or ray tracing. Usually I increase tessellation just to capture geometric details, not normal or texture interpolation. You would think it would be possible to easily set up triangles in such a way that relatively simple mappings would not have problems such as these. You basically want something more like a quadrilateral mapping, where the left edge of the triangle is using, say, U = 0.20 along its edge and the right edge uses U = 0.30. The problem is that the point at the tip has a U of say 0.25, so both edges interpolate from there.

I should note that this problem is solvable by messing with the mappings themselves. For example, you could instead use a different texture and a cube map projected onto a sphere to solve that case, which would also decrease distortion and so require less texture resolution overall.

Woo, Pearce, and Ouellette have a lovely old paper about this and other common rendering bugs and their solutions. They reference a paper by Nelson Max from 1989, “Smooth Appearance for Polygonal Surfaces” for using C1 continuity. This doesn’t seem easy to do on the GPU without a lot of extra data. Has anyone tried solving this general problem, of treating two triangles as a quadrilateral mapping? I don’t really need to solve this problem right now, I just think it’s interesting, something that’s doable in a pixel shader in some way. I’m hoping someone’s created an elegant solution.

The effect of temporal smoothing leads to the way we perceive light
that blinks, or flickers. When the blinking is slow, we perceive the
individual flashes of light. Above a certain rate, called the critical
flicker frequency (or CFF), the flashes fuse together into a single
continuous image. Far below that rate we see simply a series of still
images, without an objectionable sense of near-continuity.

Eizo can drive the LCD panel at 240 Hz by either showing each frame twice or by inserting black frames between the pictures, which is known to significantly reduce blurring on LCD panels.

This is interesting: the 240 Hz is not that high because the eye can actually perceive 240 Hz. Rather, it is used to compensate for response problems with LCD panels. The very fact that an entirely black frame can be inserted every other frame means that our CFF is clearly way below 240 Hz.

So, my naive conclusions are that (a) 240 Hz could indeed be meaningful to the monitor, in that it can use a few frames that, combined by the visual system itself, give a better image. This Hz value of the monitor should not be confused with the Hz value of what the eye can perceive. You won’t have a faster reaction time with a 120 Hz monitor.

The thing you evidently can get out of a high-Hertz monitor is better overall image quality. I can imagine that, on some perfect monitor (assume no LCD response problem), if you have a game generating frames at 240 FPS you’re getting rendered 4 frames blended per “frame” your eye received. Essentially it’s a very expensive form of motion blur; cheaper would be to generate 60 FPS with good motion blurring. Christer Ericsson long ago informally noted how a motion-blurred 30 FPS looks better to more people than 60 FPS unblurred (and recall that most films are 24 FPS, though of course we don’t care about reaction time for films). What was interesting about the Eizo Foris review is that the reviewer wants all motion blur removed:

You probably already own a 120 Hz monitor if you are a gamer, but your monitor most likely does not have the black frame insertion technology, which means that motion blurring can still occur (even though there is not [sic] stuttering because of 120 Hz). These two factors are certainly not independent, but 120 Hz does not ensure zero motion blurring either, as some would have you believe.

The type of motion blur they describe here is an artifact, blending a bit of the previous frame with the current frame. This sort of blur I can imagine is objectionable, objects leaving (very short lived) trails behind them. True (or computed) motion blurring happens within the frame itself, simulating the camera’s frame exposure length, not with some leftover from the previous frame. I’d like to know if gamers would prefer 60 FPS unblurred vs. 60 FPS “truly” blurred. If “unblurred” is in fact the answer, we can cross off a whole area of active research for interactive rendering. Kidding, researchers, kidding! There would still be other reasons to use motion blur, such as the desire to give a scene a cinematic feel.

For 30 vs. 60 FPS there is a “reaction time” argument, that with 60 FPS you get the information faster and can react more quickly. 60 vs. 120 vs. 240, no – you won’t react faster with 240 Hz, or even 120 Hz, as 60 Hz is essentially our perceptual maximum. My main concern as this monitor refresh speed metric increases is that it will be a marketing tool, the equivalent of Monster cables to audiophiles. Yes, there’s possibly a benefit to image quality. But statements such as “there is not [sic] stuttering because of 120 Hz” make it sound as if our perceptual system’s CFF is well above 60 Hz – it isn’t. The image quality may be higher at 120 or 240 Hz, and may even indirectly cause some sort of stuttering effect, but let’s talk about it in those terms, rather than the “this faster monitor will give you that split-second advantage to let you get off the shot faster than your opponent” discussion I sometimes run across.

That said, I’m no perception expert (but can read research by those who are), nor a hard-core gamer. If you have hard data to add to the discussion, please do! I’m happy to add edits to this post with any rigorous or even semi-rigorous results you cite. “I like my expensive monitor” doesn’t count.

p.s. I got 4/11 on the test, mainly because I couldn’t tell a darn bit of difference.

]]>http://www.realtimerendering.com/blog/60-hz-120-hz-240-hz/feed/8SIGGRAPH 2014 Book Crophttp://www.realtimerendering.com/blog/siggraph-2014-book-crop/
http://www.realtimerendering.com/blog/siggraph-2014-book-crop/#commentsSun, 14 Sep 2014 22:28:33 +0000http://www.realtimerendering.com/blog/?p=3810I’ve updated the graphics books listing hosted at our site. This is excruciatingly dull HTML editing; I hope it helps you out. Many of the additions are from CRC, since I was able to view their books at SIGGRAPH – the number of book vendors seemed way down this year, maybe two total? If you find (or wrote!) a relevant book that’s not listed, let me know.

The secret takeaway on our webpage: check the additional links I give at the end of most listings. Many books have some sort of free preview and a related website with code, lecture notes, etc. For example, Multithreading for Visual Effects has a website that includes the SIGGRAPH 2013 course notes that the book is based on.

There are also other interesting resources you can find tucked away in these websites, such as this list of on-line articles related to Game Engine Architecture. A bunch of the URLs listed there are easily-discovered wikipedia links, but quite a few are solid blog entries or other web pages you might not find in a quick search. This sort of editorial grooming of web resources is valuable. The 2nd edition’s list of URLs is not up yet, and I can understand why. Please don’t remind me how dated a fair bit of our own main page has become – managing links is a giant time suck, so I appreciate it whenever anyone else makes this sort of effort.

Dig deep enough on some of these book websites and you might find oddities such as this list of ten reasons to write a computer graphics textbook. I guess we’re in the bastard category?

I did do some back-filling, adding older books that could (someday) be relevant to interactive rendering, e.g., Production Volume Rendering. I didn’t add all possible vaguely-related books. From the cover and title, The Magic of Computer Graphics looks like a coffee-table book, pretty pictures and minimal content. Looking inside, it turns out to be a heavy-duty text on materials and illumination theory. For example, by page 11 you’re exposed to an integral for the BRDF, and that’s the ninth equation introduced by then. I left it out mostly because it’s an odd duck. The book Visual Perception from a Computer Graphics Perspective looks like a good volume if you’re really really into perception, but not all that related to interactive 3D graphics. I was also tempted by Digital Geometry in Image Processing, mostly because of the cover – I’m in solidarity with anyone who voxelizes teapots. This book sounds like computer graphics, but instead turns out to give a glimpse at how huge the world is. There’s a whole area of study of the theory of measurement for pixel and voxel centered coordinates? Wow. But it doesn’t look all that relevant. Feel free to read it and prove me wrong, that would be great.

No book reviews for now, as I haven’t seriously examined the newer books yet. I’ve asked for a (very) few review copies, and hope to cover these in the upcoming months. There is one book I know I won’t review (and won’t list), this alternate-universe version of Real-Time Rendering, accidentally issued by CRC Press without the realization that they already had a book with this title. An embarrassment for them, so I feel a little rude to mention it, but honestly… It was on display at the CRC booth, but not next to their “other” Real-Time Rendering, which would have made a good photo.

Luckily CRC can’t sue itself for passing off and unfair competition. It’s an interesting area of the law – titles are not copyright; trademark applies to only a series of books (e.g. “… for Dummies”). Searching on Introduction to Computer Graphics will turn up about four books, including the new one from CRC. This is fair, since the title is pretty generic and none of the books has established itself as the well-known one. I look forward to someone testing the waters in the future and publishing Physically Based Rendering: From Hog to Lard.

]]>http://www.realtimerendering.com/blog/siggraph-2014-book-crop/feed/8Free New Computer Vision Bookhttp://www.realtimerendering.com/blog/free-new-computer-vision-book/
http://www.realtimerendering.com/blog/free-new-computer-vision-book/#commentsSun, 27 Jul 2014 20:49:53 +0000http://www.realtimerendering.com/blog/?p=3808The book “Computer Vision Metrics: Survey, Taxonomy, and Analysis” is available for free download as a PDF or other formats. Go to the “Source Code/Downloads” tab in the middle of the page and work your way through the labyrinth. Also, you can get the Kindle edition for free. From my pretty limited knowledge of image processing, this looks like a useful survey book, running through common techniques and pointing to relevant references. Me, I was interested in segmentation algorithms for non-photorealistic rendering, and it has a reasonable section all about this topic.

]]>http://www.realtimerendering.com/blog/free-new-computer-vision-book/feed/0Big World, Secrets of the Teapothttp://www.realtimerendering.com/blog/big-world-secrets-of-the-teapot/
http://www.realtimerendering.com/blog/big-world-secrets-of-the-teapot/#commentsSun, 06 Jul 2014 22:03:42 +0000http://www.realtimerendering.com/blog/?p=3804If you’re a member of SIGGRAPH, one perk is that you have access to the ACM Digital Library’s graphics related content. The SIGGRAPH benefits document notes:

Access to all ACM SIGGRAPH related content in the ACM Digital Library (This includes SIGGRAPH, SIGGRAPH Asia, and about 20 or more small conferences)

I learned where to find the list of 20 small conferences, it’s here. And it’s not 20, it’s over 100. Admittedly, some of these symposia were run just once or twice, but I appreciate the access nonetheless. It’s a big world! Wandering through this list is fascinating, and a little nostalgic – “Ahh, remember when that topic was a hot new trend? Whatever happened to it?” Honestly, it’s exciting to see so many areas where graphics has an effect. If I had students looking for research topics in graphics and no strong preference about what area they wanted to explore, I’d point them at this page as a source for inspiration, dry as it looks.

I asked about this list because I had a problem accessing some NPAR papers through the DL. As usual, I drove around the damage by using Google Scholar and finding the papers I wanted elsewhere, for free. To the ACM’s credit, they responded to my query about whether I was supposed to have access to NPAR, since I had access in the past. I was indeed, and they fixed the DL the next day. So, the takeaway is that if you find you don’t have access and think you should, let the ACM know at acmhelp@hq.acm.org.

Seriously? The secrets of the teapot cannot be fully revealed? Who (the heck) would not give reprint permission? Or was it just a matter of someone being unreachable, and the default being the text couldn’t be reprinted? There’s a story there…