Resources

You are currently browsing the archive for the Resources category.

My last post was all the free and easy ways to improve your written work. These get you only so far. Going from “free” to “a penny or more” in today’s friction-free Internet economy is a hard sell, but you should consider it. Would you pay $40 to have your submitted or completed article be more professional and readable? If you’re a researcher, I’d hope you’d answer “of course.” The trick is knowing how to do so.

My answer: hire a technical-oriented copy editor. Specifically, hire Charlotte Byrnes – contact email’s below. She did all the copy editing and typesetting for Real-Time Rendering, 4th edition, and all the copy editing for Ray Tracing Gems. Me, I’m not planning on writing another book for a decade or so – that’s about how long it takes for me to forget all the pain from these two previous times. Charlotte’s not part of that pain – just the opposite. I asked Ms. Byrnes if, with our book done, she was accepting article-editing work. She said she’s currently available, though may have to turn down work if the demand becomes unmanageable. Now that we’re not selfishly monopolizing her time, I asked if I could pass her name along – she agreed, and so, this post.

Of the four editions of Real-Time Rendering, she’s done by far the most clean-up work on our text. I recall a previous edition where the copy editing was nothing but thousands of commas getting added, page after page of little blue “add comma” marks, which (to meet the deadline) I had to type in. Ugh, and I knew there were sentences that could have been polished and improved, but simply weren’t. Charlotte improves sentences, makes equations look better, notes problems with notation, cleans up bibliography references, on and on. With Charlotte, we send her the .tex file, figures, and whatever else is needed to compile the article. She edits the .tex and .bib files, making corrections and adding a few notes about elements she wants the authors to check.

In fact, here’s a simple example, a diff showing her edits to the four-page chapter “What is a Ray?” from Ray Tracing Gems. There are not a huge number of changes, but she caught some grammatical errors, commented on figure notation problems (search on “CE QUERY”), and rewrote a phrase that frankly made no sense, “the surface $\pt{P}$ lies on may intersect” – a problem we four authors didn’t notice ourselves. Great stuff, and so worth it.

My advice: if you’re using .tex, don’t use “\import”, just send her one .tex file with all the text – it’s much easier on both her and you, as you can then do a “diff” with your one original file and see what’s changed. I also recommend putting hard line breaks at 80 characters (e.g., in TeXstudio use “Idefix | Hard Line Break…”), as then the “diff” will be easier to view. Or use WinMerge, which shows long-line diffs without scrolling.

Also, note with the rates below that there’s an assumption the article is in relatively reasonable shape. If you know your non-native-English is not that great, she’s willing to edit, but it’s more per page, negotiable.

Here’s the info she sent:

 

I have over 14 years experience in academic scientific publishing, both editorial and production, specializing in mathematics and computer science (particularly in computer graphics and game design).

Available Services

o   Copyediting
o   Developmental editing
o   Typesetting in LaTeX
o   Word-to-LaTeX conversion
o   LaTeX-to-Word conversion
o   Proofreading
o   Entering edits in Word or LaTeX files
o   Project management for collections with contributing authors

Base Rates

Copyediting: $2.50 per page/1200 characters
Typesetting: $3.50 per page
Conversion: $2.00 per page, plus $1.00 per significant mathematical expression
Minimum cost of $40.00

Negotiable rates for non-native-English-speaking authors, developmental editing, and additional services

Charlotte Byrnes
STM Manuscript Services
[email protected]

Takeaways from this article: Use Capitalize My Title to determine exactly which characters to capitalize. Use my free chex_latex Perl script to find common goofs in your .tex and text (just copy your .docx text to a text file) files. Also try pasting your .tex into Microsoft Word to see what it turns up. Jump to the end of this post for more info. And if you want a great technical copy editor or typesetter (she did both for Real-Time Rendering 4th edition and copy editing for Ray Tracing Gems), hire Charlotte Byrnes. No, really, do it; she copy edits papers, too.

Yesterday we finished putting together Ray Tracing Gems, turning the files over to our publisher. Tomas and I agree that we’re done with making books for a decade or so, at least. “Editing, it’ll be easier than writing,” said the naive editors. And, yes, we changed all “naïve” with the umlaut (a form that seems to be popular with authors from Germany) to “naive.”

There’s a lot we learned about process – basically, think through and establish good processes early on, for everything – but I want to focus on grammar and style-nerd stuff, since it’s SIGGRAPH paper-writing season. What follows are my fairly-well-informed-but-I-could-be-convinced-otherwise opinions. I think of myself as maybe a B+ English student, on a good day.

Gender-neutral: Instead of he/she, or alternating “he” and “she” in a passage, people can use “they” for the singular form. This concept dates back to 1375.

“Data is” is fine, according to The Guardian, which also notes that The Wall Street Journal is coming around. To quote: “It’s like agenda, a Latin plural that is now almost universally used as a singular. Technically the singular is datum/agendum, but we feel it sounds increasingly hyper-correct, old-fashioned and pompous to say ‘the data are’.”

Please spell out any acronym you use the first time you use it, e.g., “the bounding volume hierarchy (BVH) for the scene.”

Use the ACM Digital Library (DL) for references in your .bib files. On an article’s page on the upper right is “Export Formats: bibtex” – click it. Even then, the DL is sometimes not quite correct, e.g., “Proceedings of High Performance Graphics” should have a hyphen: “Proceedings of High-Performance Graphics,” as that’s truly the conference name. But they’re at least close. Here are some variants I spotted from authors:

High-Performance Graphics (nice and short, but a little hard to tell if this is a book or something else when reading the bibliographic entry in the paper)
High Performance Graphics
Proceedings of High Performance Graphics (ACM DL form, needs a hyphen)
Proceedings of the Conference on High Performance Graphics
High Performance Graphics 2009
Proceedings of the 5th High-Performance Graphics Conference
Proceedings of the ACM SIGGRAPH Symposium on High-Performance Graphics
Proceedings of the Fourth ACM SIGGRAPH / Eurographics Conference on High-Performance Graphics (wins for longest)

The DL bibtex entry sometimes puts the article title into lowercase when it is actually presented properly capitalized. I’m for using the capitalized version the authors intended. BTW, the Google Scholar Button is handy for finding references.

Hyphens are tricky. For a word where you could hyphenate it or leave out the hyphen, e.g., “non-planar”/”nonplanar,” we had a few rules of thumb:

  • Check Merriam-Webster. For example, “nonplanar” is an accepted spelling, so we left the hyphen out. So “nearfield,” “dataset,” and “retroreflection” are in the dictionary. You still must poke around, e.g., “retroreflect” is not.
  • If it’s not in the dictionary, consider the literature. So, “microfacet” and “framebuffer” are OK, since they are commonly used in computer graphics.
  • Otherwise, use a hyphen, e.g., “re-render,” “micro-detail.”

For phrases we used these hyphenation rules. For example, “world-space coordinates” vs. “world space” vs. “coordinates in world space” are all proper. Also, it’s never “Monte-Carlo” – you wouldn’t say “faster than a New-York minute.” Oh, and it’s never “physically-based,” as the rules note.

Our one exception to these sorts of rules was that we never hyphenated “ray-tracing” in Ray Tracing Gems. For starters, we’d have to considering changing the title to Ray-Tracing Gems, which takes emphasis off of ray tracing (“Hey, this book’s a rip-off, I thought it was about properly rendering gemstones”). It’s also the more popular adjective form in previous publications (though I found only a few articles to back up this claim). To confuse things a bit, Microsoft calls their DXR API “DirectX Raytracing” – one word for “ray tracing.” We use it this way whenever we spell it out for DXR. We also resisted using “any-hit shader” and “closest-hit shader,” as Microsoft does not hyphenate, no matter how much I wish they did. This quotidian stuff takes up a surprising amount of time, but luckily I’ve folded the various common hyphenation tests into chex_latex. If you disagree, it’s easy to change or remove the tests from the script (even if you don’t know Perl, you do know how to use the “delete” key).

I like to avoid too many uses of “this” without a noun after them. Some strict teachers never allow a “this” without a noun after each one, but I think that’s overkill. Still, it’s good to think about: If it’s not obvious what the noun should be after the “this”, then add it. I’ve also found that “This” at the start of a sentence can often be changed to “Doing so,” e.g., “We add up the probabilities. This simplifies the subsequent…” to “We add up the probabilities. Doing so simplifies the subsequent…” The second sentence is a bit more active and engaging.

Avoid “very” when you can, as it’s either fluff or is a lazy way to increase the impact. Mark Twain didn’t say (but it’s still a great quote): “substitute ‘damn’ every time you’re inclined to write ‘very’; your editor will delete it and the writing will be just as it should be.” There are lists out there, such as this one, giving synonyms, e.g., “massive” for “very big.” That said, I haven’t yet found good replacements for “very close” and “very time consuming.” Another word in this category of fluff is “really.” Please never use that in formal writing; even “very” is better.

At the start of a sentence, “In order to” can usually be replaced by “To.” Shorter is more concise and sounds more authoritative.

The word “only” can often get moved to the right. Placement matters: “I only cook hot dogs but don’t eat them” and “I cook only hot dogs, not hamburgers” have “only” modifying the proper words. So “We only render the opaque objects” is less precise than “We render only the opaque objects.” Both work – we’re used to mentally shoving the “only” to be with the objects in the first version – but why not say it right to begin with?

The abbreviations “i.e.” and “e.g.” always have commas after them in the U.S., e.g., such as what I just did in this sentence. Same thing with the phrases “for example” and “that is” – commas after. Also, this is my own hypersensitivity, but please reword to avoid “et al.’s” – it’s fine in some lawless parts of the world, but you drive a stake in my Latin teacher’s heart when you mix Latin and English in this way.

In the U.S., the Chicago Manual of Style says “toward” is preferred in the U.S. over “towards,” “forward” over “forwards,” and so on. I’ve also seen this in spell checkers, with “towards” being flagged. Most sites say either is fine for the U.S., though the English prefer “towards.” I decided on the “remove the ‘s'” versions for this U.S. book (and “color” not “colour,” etc.) in order to be consistent throughout and to avoid spell-checker catches.

OK, that’s way more than enough, and I haven’t started in on “that” vs. “which” or how semicolons get misused…

If I could change just one thing in U.S. English, it would be punctuation placement with quotes and double-quotes. In the U.S. we put commas and periods inside the double-quotes, “like this.” In the U.K. it’s “like this”. Note that all other punctuation – colon, question mark, semicolon – for the U.S. is outside the quotes, unless you’re quoting a phrase with these in it, e.g., “Quis custodiet ipsos custodes?” I wish we’d all switch to the U.K. model, it’s more consistent and puts my computer science heart at ease. Oh well. That said, it’s legal to keep the punctuation out if you’re trying to explain syntax itself, e.g., “To declare floating-point numbers you can use ‘double’ or ‘float’.”

To conclude, I’ll explain more what I said at the start, about free tools you should consider using:

  • Use Capitalize My Title to determine exactly which characters to capitalize in titles and section headers. There seems to be a tendency in Europe to not capitalize the hyphenated word. For example, the often-cited (and good!) paper “An Inexpensive BRDF Model for Physically-based Rendering” has a lowercase “b” in “based” (there also should not be a hyphen). It’s also visible in such things as the First-tier Tribunal. For U.S. publications the rule is to capitalize the hyphenated word, unless the word would normally be lowercase, e.g., “Texture Level-of-Detail Strategies for Real-Time Ray Tracing.”
  • Microsoft Word or other spell and style checker is worth your while. Copy the contents of your PDF or .tex file, paste into Word, and see what it turns up. If you do this simple trick as a reviewer, you look like some copy-editing genius by catching obscure errors. Beat reviewers to the punch by doing this to your own submissions. I did so with this article and it turned up six suggestions, four of which I used.
  • Give chex_latex.pl a run on your .tex or text file (e.g., copy your text from your Word document to a .txt file). Yes, you must install Perl, how old-school, but ten minutes of messing with this program will likely turn up a few things in your paper that are wrong or at least worth contemplating changing. It has hundreds of little tests, but my favorite is the one I stole from here, that finds accidentally doubled words, e.g., “the the” or “a a” – these occur surprisingly often. Perl scripts are trivial to edit, so if you don’t like a test, just delete or modify it. Or you can put “% chex_latex” at the end of any line to have the tool ignore it completely. I ran this tool on this article and it found two little goofs.
  • For longer works I find an interactive spell checker to lead to madness, as you hit author after author after author when you check, along with variable and procedure names. I finally wrote a tiny back-end program, aspell_sorter.pl, for the standalone command-line spell checker “aspell.” Now with three commands I concatenate all .tex files together, spell-check them all, and then sort by word and get a count for each “misspell.” For example, on my latest run, in 23,083 lines of .tex in Ray Tracing Gems, “aspell” found 7744 questionable terms. That’s like one spell check per 3 lines – insane. The “aspell_sorter” turns this into a list of 1599 questionable terms – almost 5x less. You can also set “$spellcount = 1;” to show only unique misspellings, things “misspelled” only once. Doing so will miss consistently misspelled words, but the list to skim over is now down to just 696 entries – a more than 11x culling of potential problems. Of these, I found three true misspellings: ROUGNESS, vextex, and identifer (though these were found after three editors had already read each of the chapters and I had similarly spell checked most of the text a month earlier). I had to wade through a lot of false positives, 693 of them, but it’s better than wading through 7741.
  • I’ve heard good things about Grammarly and Hemingway, but haven’t gotten into them myself.

Bonus info: it’s not about grammar, more about English in general, but I’m enjoying Bill Bryson’s The Mother Tongue – it’s a great bathroom read. The amount of useless knowledge per page is impressive. For example, I now know where the “r” sound in the word “colonel” comes from.

No I’m not kidding; yes it’s the 3rd edition. See the announcement (an interesting read – I loved the first cover proposal), or the front page, or jump right to the table of contents. HTML only for now, though there is an ancient first draft available, but free is pretty great.

Just can’t get enough about real-time ray-traced Sphereflakes? I wrote an official-looking NVIDIA blog post that’s an extended-play version of my previous blog post.

The code’s here, but can only be run if you have a Titan V or new RTX card, and if you haven’t installed the Windows 1809 October update.

[I was told “evar” looked like a misspell, so I’m fixing it this time.]

It clearly takes a village to write the book Real-Time Rendering. Ola Olsson pointed out this entertaining bit on Google Scholar:

The fourth edition appears to be Volume 19 Issue 2. The article mentioned does exist, but is the very last reference in the book (#1978). The number of authors on the paper is impressive, quite an increase from the original three for this article. Ansel Adams, among others, gets listed three times as an author – excellent CV padding. My favorite, though, is the description of the article, a quote by Billy Zelsnack used at the beginning of our chapter “The Future.”

I poked around a bit more and found some alternate reality listings, such as this:

In both 4th editions our new three authors don’t show up. More disturbing is that in one universe’s edition Tomas Akenine-Möller also no longer exists (sad, since he’s listed six times as an author in the first image). And a strange universe it is, where the book has 40 citations, despite being out for less than 6 weeks. The prescience of some authors citing it is impressive, with one article published in the year 2000 referencing this fourth edition. Research must be wonderfully accelerated there, with developers being able to read about future breakthroughs that they can then write up.

 

I enjoyed the previous ray tracing monday two weeks ago, so let’s do it again.

Since it’s been two weeks, two resources:

  • “Real-Time Ray Tracing” – this is a free chapter (number 26) of Real-Time Rendering that we just finished and is free for download. 46 pages with a focus on DXR, but also including a detour through everyone’s favorite topic, spatial data structures for efficient ray tracing. Tomas, Angelo, and Seb did the heavy lifting on this one over the past 3 months, I helped edit and added bits where I could.
  • Ray Tracing Resources Page – along the way we ran across lots of resources. With the chapter finished as of today, I was inspired to make a page of links, mostly things I don’t want to lose track of myself or found of historical interest. Please do feel free to send me awesome resources to add, etc.

One entertaining thing I ran across was an image in the gallery for Chunky, a quite-good custom path tracer for Minecraft worlds:

Cornell blox

Cornell blox

Steve Hollasch mentioned that there’s a “new” (well, new to me – it’s 9 years old) Creative Commons instrument, CC0. Their website has an explanation of the problem with trying to put something you made into the public domain, and how CC0 solves this. Open Knowledge International (no, I never heard of them, either) recommends it, which I’ll take as a good sign. I didn’t know of this CC0 beast, and suspect readers here don’t, either, so now you do. It’s mostly not a license, it’s a “dedication,” a way to ensure that something you created is considered unowned and free to reuse in every country.

If you want to make sure your code is properly credited to you, use something such as the MIT license instead, or some other (often more restrictive) choice. Creative Commons recommends not using their other licenses for code, but rather some common source code license. I’m assuming (it’s not super-clear) that CC0 is also fine for code you’re putting into the public domain. Update: aha, Steve Hollasch sent this follow-up link – CC0 can be applied to code, and that link shows you how to do it.

Update: I received a number of interesting responses from my tweet of this post. David Williams points out that CC0 is approved by the Free Software Foundation for putting code in the public domain, as it has a fallback license for countries where public domain is not recognized. Arvid Gerstmann notes that dual-licensing with CC0 and the MIT license may be an even better option, for those companies where the lawyers haven’t approved the lesser-known CC0 but have approved use of code with the MIT license.

I know this all sounds like “it doesn’t matter, I’m never going to enforce this,” but it does, sadly. With Graphics Gems we made up a license long ago (basically, “don’t be a jerk”) because someone was trying to sell his company to a larger firm, which had some software testing firm test the smaller company’s code for copyright infringements, and various bits of Graphics Gems code popped up. If CC0 had existed, or maybe even the questionable (and rude) WTFPL, we would have gone with that. Happily, there is now the CC0. (tweet)

Now that I’m back from SIGGRAPH, I can catch up on all the things. So here’s one: win a free copy of Real-Time Rendering, 4th Edition. Our publisher is giving away three copies, deadline to enter is August 31.

As far as actually receiving a copy of the book, well, if it’s any consolation, none of us authors have a physical copy at this point, either. Our publisher wrote on August 8th:

This reprint should be in the warehouse within the next 3 weeks.  I assume the fulfillment dept will give customer orders priority over author copies.

So it’s a case of the shoemaker’s children go barefoot. Amazon says the book’s back in stock on August 27th.

I do like that the first three chapters are free on Amazon, for Kindle, and Google Play, so I hope that will tide people over until these ship. That this much content was made free was unexpected, a happy decision on the publisher’s part. If you’re done with those chapters and still waiting, don’t forget to read Pete’s now-free books on ray tracing.

I got to see a physical copy of our book at SIGGRAPH, so know such things exist. I also bought the book on Kindle (which at first had some download problem on my iPhone and PC, but downloaded fine the next day) and Google Play (surprised to find it there; same price as Kindle, by some amazing coincidence), as I wanted to see if a layout problem in my local copy was present in the book (happily, it wasn’t – ahhh, the mysteries of LaTeX).

One of the best parts of SIGGRAPH was actually meeting my coauthors. The wild party on the yacht that night in Vancouver Harbor was really something, too, but then I realized I made that up.

Eric, Angelo, Naty, Seb, Tomas, and Michal; photo courtesy of Mauricio Vives

OK, everything happened today, so I am believing the concept of time is no longer meaningful.

First, NVIDIA announced its consumer versions of their RTX ray tracing GPUs, which should come as a shock to no one after last week’s Ray Tracing Monday at SIGGRAPH. My favorite “show off the ray tracing” demo was for Battlefield V.

Then, this:

I love free. To get up to speed on ray tracing, go get the books here (just in case you can’t click on Pete’s link above), or here (our site, which shows related links, reviews, etc.). Then go to the SIGGRAPH DXR ray tracing course site – there’s even an implementation of the example that’s the cover of Pete’s first book.

Up to speed already? Start writing an article for Ray Tracing Gems. At SIGGRAPH we found that a few people thought they had missed the proposals deadline. There is no proposals deadline. The first real deadline is October 15th, for completed articles. We will judge submissions, and may reject some, but our goal is to try to work with any interested authors before then, to make sure they’re writing something we’ll accept. So, you can informally write and bounce ideas off of us. We avoided the “proposals” step in order to give people more time to write and submit their ideas, large and small.

BTW, as far as free goes, we’re aiming to make the e-book version of Ray Tracing Gems free, and also having the authors maintain reprint rights for their works.

All for now. Day’s not over yet.

Considering our bibliography as a training set, you can save yourself the cost of our book by just reading all the references.

Better yet, learn the stochastic, Monte Carlo way, thanks to . Let me know what century you converge on a solution.

« Older entries