Search Results

Your search for codex returned the following results.

[This is a guest post from Morgan McGuire. His Graphics Codex is a pretty great thing for anyone who wants just about all graphics formulae and algorithms at their fingertips. It’s not a perfect venue yet, but I think this is an extremely interesting alternative to books, since the app can be constantly updated and improved. With links to working code for many of the algorithms, my first question, “how do I copy and paste?”, is covered. – Eric]

The Graphics Codex 1.7 costs $9.99 on the App Store. You can install it on multiple iOS devices (I use both an iPad and an iPhone). You also receive free (approximately-) monthly updates of new content and features. It supports all iPads, iPhones, and iPod touches with iOS 5 or later [my experience is that you need iOS 6 – there’s a refresh problem with anything older; evidently Apple has changed its scrolling support], although I recommend at least an iPad 2, iPhone 3, or iPod 4.

The Graphics Codex contains about 200 entries on essential computer graphics equations, algorithms, data, and figures. These span quite a range. For example, they include: the formal definition of the BSDF, source code for a shadow map pixel shader, LaTeX commands for image formatting, and figures commonly used in teaching. For me, the historical figures are particularly fun. The staff at the Chapin rare books library helped me to track down first editions of books including Newton’s Opticks, Durer’s perspective manuscripts, and even Lambert’s work. I then scanned these so that you can get Lambert’s law from his original derivation–a kind of vicarious graphics tourism. When lecturing, I connect my iPad to the classroom projector to display these; the students use their iPhones and iPads to pull up equations and details of what I’m writing on the board.

Every month I add new entries based on what I use in my own graphics work and requests that I receive by e-mail. I read all reviews posted on iTunes as well and respond to them with changes. I currently have a queue of 44 new entries to be added. For each one, I cite a primary source and actually implement the algorithm to ensure correctness. The citations include links to canonical (e.g., ACM Digital Library) and free (e.g., author version) PDFs in most cases, so you can quickly jump directly to the source to learn more. Since many functions are also supported under various APIs, I link to DirectX, OpenGL, Mitsuba, etc., documentation as well.

In addition to the reference material, version 1.7 includes “Lecture Notes on Rendering”: twelve long-form chapters suitable for use in an introductory (ray tracing) computer graphics course. This semester I taught graphics at Williams College using this as the primary reading material. I supplemented it with a few chapters from Fundamentals of Computer Graphics 3rd edition, Computer Graphics: Principles & Practice 3rd edition [to be released May 6, 2013 – Morgan is a coauthor], and two research papers: Kajiya’86 and Jensen ’96. The next three chapters I will add in future updates are deep explanations of Photon Mapping, Importance Sampling, and Color Theory. All of these can be used with any API, but are explicitly supported by the open source G3D Innovation Engine graphics library. G3D now includes a complete photon mapping ray tracer that matches the notation and structure of the renderers described in the lecture notes.

On the technical side, I completely rewrote the layout and scrolling engine for this release. The new GPU-accelerated version allows scrolling before layout completes, making even the longest chapters respond nearly instantly. The underlying code uses LaTeX for math typesetting and that runs on a second thread, so if you scroll really fast you’ll see the equations inserted as they are completed. I use dynamic layout instead of static (e.g., PDF) so that content can respond to changing device orientation and re-layout on font change rather than forcing the reader to scroll horizontally. This version also includes support for iPhone 5, iPod 5, and iPad mini resolutions and processors. I recommend using the latest iOS version 6.0.1 because that has the best GPU drivers, but the app supports everything back to iOS 5.1.

I can’t stress enough how liberating and rewarding it has been as an author to release material as an app instead of a book. There are no delays because I release content incrementally instead of in discrete editions, and the quality remains uncompromised by artificial publishing and marketing deadlines–I only release material when it is polished. Direct feedback from readers allows me to support them with appropriate content, and there are zero known errors; as soon as errata is collected, I simply patch the content and push it out to everyone. Selling for 10-20% of the cost of a textbook allows me to reach the hobbyists, indie developers, and students who will be tomorrow’s great developers and researchers. The down side, of course, is that I rely on “word of mouth” (e.g., blogs and Twitter) to promote the app, whereas traditional publications have marketing budgets and campaigns. Now that the app has a critical mass of content, I’m starting to promote it more actively. I look forward to readers letting me know what new features and entries to add in future months.

[p.s. here are links for the Graphics Codex homepage, and Morgan’s twitter feed (actually, he has two) and blog.]

Tags: , , ,

The Graphics Codex is a little $3.99 Apple app developed by Morgan McGuire, a noted researcher and practitioner in graphics, especially interactive graphics. He’s written numerous research papers and a number of books on videogame development, consults for NVIDIA, teaches at Williams College, and has worked on games such as Titan Quest (recently named #65 in PC Gamer’s top 100 games of all time). From talking with him, the Graphics Codex is basically his reference notebook. It holds the compact nuggets of knowledge he wants to have instantly available at his fingertips (literally, since it’s an iPad/iPhone app; it also runs on iPods running iOS 5.x).

This Graphics Codex been available for a few weeks, but this new version, 1.2, has faster scrolling and display, among other features. Morgan felt this was an important improvement so I’ve been holding off blogging about the app. Upgrades are free and simple, as with most apps. Morgan says he’s working on version 1.3, which will focus on iOS 5.1 support, color theory, and diagrams useful for explaining computer graphics topics.

So, what is it? Well, let’s start with pictures:

We all have our own favorite pieces of information we like to see included. This codex fits me pretty well: I see the reflection and refraction formulas, and various matrix types described (perspective, rotation, scale, translation, skew, determinants, etc.). I see handy things like the formatting for printf, and the latex and HTML codes for Greek letters and for math symbols. I see pseudocode for object/object intersection and distance formulas, as well as various common sorting algorithms. I see raster and 3D file formats (nicely linking to original documents on the web, when available). That’s just for starters.

There are a lot of topics included, and you can see the whole list before purchasing. In the app topics are listed alphabetically, index-style, but that’s fine, as the normal way to access this work is to search the index. Some topics I don’t know a thing about, which is great – knowing what you don’t know is important. Seeing some of these concepts inspires me to learn about them (elsewhere – like I say, this app is a reference, not a textbook). Some topics I may rarely or never look at, such as the examples shown in the images above, but I like knowing they’re there. Given that the author is a professor and consultant, I understand why they exist: these are teaching aids, information you can easily pull up and show a student, client, or other developer to help explain a concept or algorithm.

That said, there are some minor gaps. Things that came to mind for me to test but that I didn’t find: compositing (“over”, etc.), sampling and filtering (e.g. sinc and Gaussian curves), dithering (but when did I last use that?), and regular expressions (which admittedly sometimes have variations between computer languages). There’s other stuff I wouldn’t mind having: all HTML letter codes, a decimal/hexadecimal table, etc., but these are trivial to find & bookmark from sites on the web. Some domain-specific things like the various architectural projections (e.g., the various axonometric projections) would be nice, but that’s very specific to me and Wikipedia mostly fills the gap. Someday I imagine there could be a framework for such codex apps to allow you to add your own index entries, similar to how you can make your own reference work on Wikipedia (update: Morgan notes that this feature exists for his app, it’s called “email him and ask for a topic to be added”). The difference is that this app gives you the core, relevant ideas and algorithms of computer graphics in a usable form, with a consistent style, and cross-referenced to only directly relevant articles. A single author and editor, focused on a single area, adds considerable value.

This is not the first time someone has collected such reference entries. The most direct “competitor” that comes to mind is Phil Dutre’s great Global Illumination Compendium. This is a free PDF, go get it. Its focus is indeed global illumination, and it’s quite an extensive reference in this area. I would say there’s about a 25% overlap with the Graphics Codex. Another resource that comes to mind is Steve Hollasch’s collection of USENET articles, free on the web. This collection is a bit ancient, but math and physical formulas don’t change quickly. It’s a pretty shotgun-scattered set of articles, more like Graphics Gemlets, but an interesting place to wander through and try for information.

Back to the Graphics Codex. Each index entry is nicely formatted and readable, and every page (except the Bibliography, which I have reported as a bug) can be made larger or smaller. This larger/smaller functionality works well, reformatting the entry to be fully visible side-to-side, vs. typical PDF zoom, where the page can become wider than the display.

All the entries are aimed to be for reference, such as hard information that you basically understand but want to get the precise formula or code. This is information you could eventually find on your bookshelf or on the web, but instead is quickly available for you by simply searching the index. You can’t actually search the entries themselves, and the bibliography doesn’t have back links, i.e., “which Codex entries reference this article?” These are minor niggles: entries use cross-references to other entries, and most entries have a reference to related books or papers, sometimes links directly to the reference, if online. Reference back-links are more useful in a textbook; for this reference, they’d probably mostly be clutter.

Summary

Negatives:

  • Can’t copy and paste, unlike a computer-viewable version. (There might be an app for that…?)
  • Doesn’t have everything I personally might need.
  • Entries themselves are not searchable.

Positives:

  • Searchable index makes finding things a snap.
  • Nicely formatted, color illustrations and pseudocode snippets.
  • Cross-referencing and original source references, with links.
  • Weighs much less than the related pile of books.
  • Has many to most things I like to have handy.

All in all, worth $3.99 to me.

The above are my own impressions, before reading the email Morgan sent me about the app. Here’s what Morgan said:

What I’m doing with the app is converting all of my course notes and the professional notes that I take with me consulting into easily searchable topics. This way I always have the reference material with me, without having to carry all of my graphics books between my home, office, lab, and remote sites. I usually cite not only the paper and book that material comes from, but the exact page, so that I can quickly find more information when I am in the same place as my books. DirectX, OpenGL, Unity, Mitsuba, G3D, and JOGL entry points link to their official documentation on the web. Unlike a PDF or Apple IBook, The Graphics Codex does all typesetting live so it reflows for the orientation and size of your mobile device, and zooming in recomputes the text rather than scrolling it off the side of the page.

I’m prioritizing topics that people e-mail me about and vote for on the website…and anything that I look up in my regular work immediately goes into the next version. Version 1.2 not only adds a bunch of new topics from convolution to quaternions but an all-new UI and the ability to show the types and units of subexpressions.

So, if you get the app and see something missing, email him and go vote!

Tags: , , ,

The book GPU Zen is out. Go get it. This is a book edited by Wolfgang Engel and is essentially the successor to the GPU Pro series. Github code is here.

Full disclosure: I edited one small section, on VR. I forget if I am getting paid in some way. I probably get a free copy if I ask nicely. But, the e-book version is $9.99! So I simply bought one. Not $89.99, as books of this type usually are (even for the electronic edition), but rather the price of two coffees.

It’s a Kindle book. Unlike the GPU Pro and ShaderX books, it’s self-published. It’s mostly meant as an e-book, though you can buy a paperback edition if you insist.

So what’s in the book? Seventeen articles on interactive rendering techniques, in good part by practitioners, and nine have associated code. The book’s 360 pages. As you probably know from similar books, for any given person, most of the articles will be of mild interest at best. There will be a few that are worth knowing about. Then there will be one or two that are gold, that help with something you didn’t know about, or didn’t know how to do, or heard of but didn’t want to reinvent.

For example, Graham Wihlidal’s article “Optimizing the Graphics Pipeline with Compute” is a much-expanded and in-depth explanation of work that was presented at GDC 2016. Trying to figure out his work from the slideset is, I guess, theoretically possible. Now you don’t have to, as Graham lays it all out, along with other insights since his presentation, in a 44 page article. At $89.99, I might want to read it but would think twice before getting it (and I have done so in the past – some books of this type I still haven’t bought, if only one article is of interest).

The detailed explanation of XPerf, ETW, and GPUView in the article by James Hughes et alia on VR performance tuning might instead be the one you find invaluable. Or the two articles on SSAO, or one on bokeh depth-of-field, or – well, you get the idea. Or possibly none of them, in which case you’re out a small bit of cash.

For the whole table of contents, just go to the book’s listing and click on the cover to “Look Inside.”

Me, I usually prefer books made of atoms. But for technical works, if I have to choose, I’m happier overall with electronic versions. For these “collections of articles” books in particular, the big advantage of the e-book is searchability. No more “I vaguely recalls it’s in this book somewhere, or maybe one of these three books…” and spending a half-hour flipping through them all. Just search for a term or some particular word and go. Oh, one other cute thing: you can loan the e-book to someone else for 14 days (just once, total, I think).

At $9.99, it’s a minimal-brainer. Order by midnight tomorrow and you’ll get the Ginzu knife set with it. I’ll try to avoid being too much of a huckster here, but honestly, so cheap – you’d have money left for Pete Shirley’s ray tracing e-books, along with Morgan McGuire’s Graphics Codex. I like low-cost and worthwhile. Addendum: if you do buy the paperback, the Kindle “Matchbook” price for the e-book is $2.99. Which is how I think reality should be: buy the expensive atoms one, get the e-book version for a little more, vs. paying full price for each.

Here are a few cool things I noticed and seem appropriate to post today.

First, this person is doing cool real-life procedural texturing. Or I should say, is really covering up, since we know the aliens are the ones who are really making these.

The Graphics Codex now has three sample PDFs available for free download, to give you a sense of what’s in the app/book. Find the links in the right-hand column.

The Christmas Experiments gives 24 little graphical presents, scroll down to make them appear. I haven’t opened them all up yet, as I was working backward and only got as far as this one, which is lovely and interactive.

Merry
xmas

Tags: ,

by Patrick Cozzi, who works on the Cesium WebGL engine.

With the new shader editor in Firefox 27 (available now in Aurora), WebGL tools are taking a big step in the right direction. This article reviews the current state of WebGL debugging and profiling tools with a focus on their use for real engines, not simple demos. In particular, our engine creates shaders dynamically; uses WebGL extensions like Vertex Array Objects; dynamically creates, updates, and deletes 100’s of MB of vertex buffers and textures; renders to different framebuffers; and uses web workers. We’re only interested in tools that provide useful results for our real-world needs.

Firefox WebGL Shader Editor

The Firefox WebGL Shader Editor allows us to view all shader programs in a WebGL app, edit them in real-time, and mouse over them to see what parts of the scene were drawn using them.

What I like most about it is it actually works. Scenes in our engine usually have 10-50 procedurally-generated shaders that can be up to ~1,000 lines. The shader editor handles this smoothly and automatically updates when new shaders are created.

skybox

The skybox shader is shown in the editor and the geometry is highlighted in red. (Click on any image for its full-screen version.)

I was very impressed to see the shader editor also work on the Epic Citadel demo, which has 249 shaders, some of which are ~2,000 lines.

citadel

Live editing is, of course, limited. For example, we can’t add new uniforms and attributes and provide data for them; however, we can add new varying variables to pass data between vertex and fragment shaders.

Given that the editor needs to recompile after our edits, attribute and uniform locations could change, e.g., if uniforms are optimized out, which would break most apps (unless the app is querying these every frame, which is a terrible performance idea). However, the editor seems to handle remapping under-the-hood since removing uniforms doesn’t break other uniforms.

Recompiling after typing stops works well even for our large shaders. However, every editor I see like this, including JavaScript ones we’ve built, tends to remove this feature in favor of an explicit run, as the lag can otherwise be painful.

There are some bugs, such as mousing over some shaders causes artifacts or parts of the scene to go away, which makes editing those shaders impossible.

artifacts

Even though this is in a pre-beta version of Firefox, I find it plenty usable. Other than spot testing, I use Chrome for development, but this tool really makes me want to use Firefox, at least for shader debugging.

We planned to write a tool like this for our engine, but I’m glad the Mozilla folks did it instead since it benefits the entire WebGL community. An engine-specific tool will still be useful for some. For example, this editor uses the shader source provided to WebGL. If a shader is procedurally-generated, an engine-specific editor can present the individual snippets, nodes in a shade tree, etc.

A few features that would make this editor even better include:

  • Make boldface any code in #ifdef blocks that evaluate to true. This is really useful for ubershaders.
  • Mouse over a pixel and show the shader used. Beyond debugging, this would be a great teaching aid and tool for understanding new apps. I keep pitching the idea of mousing over a pixel and then showing a profile of the fragment shader as a final project to my students, but no one ever bites. Easy, right?
  • An option to see only shaders actually used in a frame, instead of all shaders in the WebGL context, since many shaders can be for culled objects. Taking it a step further, the editor could show only shaders for non-occluded fragments.

For a full tutorial, see Live editing WebGL shaders with Firefox Developer Tools.

WebGL Inspector

The WebGL Inspector was perhaps the first WebGL debugging tool. It hasn’t been updated in a long time, but it is still useful.

WebGL Inspector can capture a frame and step through it, building the scene one draw call at a time; view textures, buffers, state, and shaders; etc.

The trace shows all the WebGL calls for a frame and nicely links to more info for function arguments that are WebGL objects. We can see the contents and filter state of textures, contents of vertex buffers, and shader source and current uniforms.

ducktrace

ducktexture

One of WebGL Inspector’s most useful features is highlighting redundant WebGL calls, which I use often when doing analysis before optimizing.

redundant

Like most engines, setting uniforms is a common bottleneck for us and we are guilty of setting some redundant uniforms for now.

WebGL Inspector may take some patience to get good results. For our engine, the scene either isn’t visible or is pushed to the bottom left. Also, given its age, this tool doesn’t know about extensions such as Vertex Array Objects. So, when we run our engine with WebGL Inspector, we don’t get the full set of extensions supported by the browser.

The WebGL Inspector page has a full walkthrough of its features.

Chrome Canvas Inspector

The Canvas Inspector in Chrome DevTools is like a trimmed-down WebGL Inspector built right into Chrome. It is an experimental feature but available in Chrome stable (Chrome 31). In chrome://flags/, “Enable Developer Tools experiments” needs to be checked and then the inspector needs to be explicitly enabled in the DevTools settings.

Although it doesn’t have nearly as many features as WebGL Inspector, Canvas Inspector is integrated into the browser and trivial to use once enabled.

canvasinspector

Draw calls are organized into groups that contain the WebGL state calls and the affected draw call. We can step one draw group or one WebGL call at a time (all WebGL tracing tools can do this). The scene is supposed to be shown one draw call at a time, but we currently need to turn off Vertex Array Objects for it to work with our engine. Canvas Inspector can also capture consecutive frames pretty well.

The inspector is nicely integrated into the DevTools so, for example, there are links from a WebGL call to the line in the JavaScript file that invoked it. We can also view the state of resources like textures and buffers, but not their contents or history.

Tools like WebGL Inspector and Canvas Inspector are also useful for code reviews. When we add a new rendering feature, I like to profile and step through the code as part of the review, not just read it. We have found culling bugs when stepping through draw calls and then asking why there are so many that aren’t contributing to any pixels.

For a full Canvas Inspector tutorial, see Canvas Inspection using Chrome DevTools.

Google Web Tracing Framework

The Google Web Tracing Framework (WTF) is a full tracing framework, including support for WebGL similar to WebGL Inspector and Canvas Inspector. It is under active development on github; they addressed an issue I submitted in less than a day! Even without manually instrumenting our code, we can get useful and reliable results.

Here we’re stepping through a frame one draw call at a time:

wtf

For WebGL, WTF has similar trace capability as the above inspectors, combined with all its general JavaScript tracing features. The WebGL trace integrates nicely with the tracks view.

tracks

Above, we see the tracks for frame #53. The four purple blocks are texture uploads using texSubImage2D to load new imagery tiles we received from a web worker. Each call is followed by several WebGL state calls and a drawElements call to reproject the tile on the GPU (see World-Scale Terrain Rendering from the Rendering Massive Virtual Worlds SIGGRAPH 2013 course). The right side of the frame shows all the state and draw calls for the actual scene.

Depending on how many frames the GPU is behind, a better practice would be to do all the texSubImage2D calls, followed by all the reprojection draw calls, or even move the reprojection draw calls to the end of the frame with the scene draw calls. The idea here is to ensure that the texture upload is complete by the time the reprojection draw call is executed. This trades the latency of completing any one for the throughput of computing many. I have not tried it in this case so I can’t say for certain if the driver lagging behind isn’t already enough time to cover the upload.

gc

The tracks view gets really interesting when we examine slow frames highlighted in yellow. Above, the frame takes 27ms! It looks similar to the previous frame with four texture uploads followed by drawing the scene, but it’s easy to see the garbage collector kicked in, taking up almost 12ms.

linkProgram

Above is our first frame, which takes an astounding 237ms because it compiles several shaders. The calls to compileShader are very fast because they don’t block, but the immediate call to linkProgram needs to block, taking ~7ms for the one shown above. A call to getShaderParameter or getShaderInfoLog would also need to block to compile the shader. It is a best practice to wait as long as possible to use a shader object after calling compileShader to take advantage of asynchronous driver implementations. However, testing on my MacBook Pro with an NVIDIA GeForce 650M did not show this. Putting a long delay before linkProgram did not decrease its latency.

For more details, see the WTF Getting Started page. You may want to clear a few hours.

More Tools

The WebGL Report is handy for seeing a system’s WebGL capabilities, including extensions, organized by pipeline stage. It’s not quite up-to-date with all the system-dependent values for the most recent extensions, but it’s close. Remember, to access draft extensions in Chrome, we need to explicitly enable them in the browser now. For enabling draft extensions in Firefox you need to go to “about:config” and set the “webgl.enable-draft-extensions” preference to true.

webglreport

The simple Chrome Task Manager (in the Window menu) is useful for quick and dirty memory usage. Make sure to consider both your app’s process and the GPU process.

taskmanager

Although I have not used it, webgl-debug.js wraps WebGL calls to include calls to getError. This is OK for now, but we really need KHR_debug in WebGL to get the debugging API desktop OpenGL has had for a few years. See ARB_debug_output: A Helping Hand for Desperate Developers in OpenGL Insights.

There are also WebGL extensions that provide debugging info to privileged clients (run Chrome with –enable-privileged-webgl-extensions). WEBGL_debug_renderer_info provides VENDOR and RENDERER strings. WEBGL_debug_shaders provides a shader’s source after it was translated to the host platform’s native language. This is most useful on Windows where ANGLE converts GLSL to HLSL. Also see The ANGLE Project: Implementing OpenGL ES 2.0 on Direct3D in OpenGL Insights.

The Future

The features expected in WebGL 2.0, such as multiple render targets and uniform buffers, will bring us closer to the feature-set OpenGL developers have enjoyed for years. However, API features alone are not enough; we need an ecosystem of tools to create an attractive platform.

Building WebGL tools, such as the Firefox Shader Editor and Chrome Canvas Inspector, directly into the browser developer tools is the right direction. It makes the barrier to entry low, especially for projects with limited time or developers. It helps more developers use the tools and encourages using them more often, for the same reason that unit tests that run in the blink of an eye are then used frequently.

The current segmentation of Google’s tools may appear confusing but I think it shows the evolution. WebGL Inspector was first out of the gate and proved very useful. Because of this, the next generation version is being built into Chrome Canvas Inspector for easy access and into the WTF for apps that need careful, precise profiling. For me, WTF is the tool of choice.

We still lack a tool for setting breakpoints and watch variables in shaders. We don’t have what NVIDIA Nsight is to CUDA, or what AMD CodeXL is to OpenCL. I doubt that browser vendors alone can build these tools. Instead, I’d like to see hardware vendors provide back-end support for a common front-end debugger built into the browser.

Tags: , , ,

I’m moving to the Boston area on Monday. One of the 258 tasks I’ve done in preparation is to deal with my bookshelves at work. I donated 13 boxes of books and journals to the Program of Computer Graphics at Cornell:

pile o' books

I’m glad they took them – who knows, maybe they’ll eventually toss most of the piles in the recycling bin (despite the sign), but at least I won’t know about it. Me, I kept my ShaderX/GPU Pro and GPU Gems series books along with a few others. I’ve enjoyed accumulating a large computer graphics library over 30 years. Raise your hand if you remember Newman & Sproull – wow, you’re old (I kept that one for nostalgia’s sake). However, once it came down to actually moving these heavy boxes and finding a spot for them all in a home office, well…

In my perfect world I pay for a book once and have it accessible to me forever, in digital form so it’s easily searchable (and weighs nothing and takes up no shelf space). Kindle’s system is getting there, but kind of a pain, you have to install an application on your PC to look at your book collection, then download each book in full if you want to examine it. Strangely, from your Amazon account you can look at the parts you highlighted in a Kindle book you own, but not the book itself. (As an aside, there are some interesting stories I see arising over the next decade, such as “Amazon proves Freddy Fredhead is deceased and so deletes his Kindle account; family mourns”.)

The Graphics Codex, which has been mentioned in this blog in the past, is pretty close to that perfect world…but it used to only be on iOS. At the time it came out only my wife had an iPad, so my copy of the Codex is tied to her device. This limitation has changed in the past week: the codex is now available as a separate web edition. Pay for it, log in from anywhere, and it’s at your fingertips. There are external links to many different resources and articles. About my only complaint is waiting 2-5 seconds for a section to first load – yes, Time Warner Cable, we consumers would like faster internet connections like they have in highly developed countries such as Latvia, and I hope Google buries you (or you wake up and do some things better and be less monopolistic).</rant> After a section’s loaded it appears to be cached and is more like a second delay to fade in.

This computer graphics reference looks great and has a bit about a large number of topics. What’s particularly nice is knowing that this resource is growing and improving over time. You can even make suggestions for new sections to Morgan McGuire, its author. He’s also made it clear that the material is “Subject to Fair Use” in the About section of the Codex. Of course, every printed work is subject to fair use, but I take this explicit wording to mean I could snip a diagram or equation and use it in a classroom lecture (and credit it), later put the lecture up on the web, and not be concerned about a Cease and Desist takedown letter coming my way. Fun fact: as of today, there are 911,708 C&D notices in Chilling Effect’s database (and that collection is mostly just those received by Google).

This is a nice feature of the web edition: you can snip from the pages. One downside is that all the lovely formatting comes at a cost: you can’t copy and paste the text characters themselves from the pages displayed. That’s mostly a quibble – I need this functionality only for code, which I probably won’t want in the same style as shown, anyway. All in all, I’m happy to buy this reference in this form, knowing I can access it at any time on any device.

And there are some nice things to snip; feast your squinties on these screenshots – click on an image for the full resolution version. The Graphics Codex is not a perfect final form of all that I’d like in a book (e.g., I can’t bookmark, highlight, write in the margins), but it’s definitely a step along the way, especially in terms of accessibility, quality, and price ($10).

Graphics Codex 1

Graphics Codex 3

Graphics Codex 2 Graphics Codex 4

 

 

 

 

 

 

 

 

 

 

 

Tags: