Sunday, January 31, 2016

I've decided to go ahead with a part-2 on the mini-book

The mini-book Ray Tracing in One Weekend got more interest than I expected.   Apparently ray tracing really is hot.   The book just gets a brute force path tracer with spheres up, so I decided it would be worth making a part 2 (to be written!).   I am seeking comments on what is missing from the list.   Here is my first cut:

Chapter 1: Motion Blur
Chapter 2: A Bounding Volume Hierarchy (BVH) Chapter 3: Solid Texture Mapping Chapter 4: Image Texture Mapping
Chapter 5: Volumes Chapter 6: A Polished Material Chapter 7: Environment Maps Chapter 8: Shadow Rays Chapter 9: Triangle Meshes

I would consider that a full-featured ray tracer.   That is not to say having all features!  

Friday, January 29, 2016

Some of Andrew Glassner's thoughts on publishing

Andrew Glassner left a reply on an earlier post that seemed too interesting to let sit in a comments section.   So here it is in its entirety.   I didn't ask Andrew, so keep in mind that he wrote this as a comment (not that I would change anything in an edit!).

Andrew's comment:

I like what you're doing here. To me, the interesting thing is that you're trying to avoid extra work that's been pushed on authors with the decline of the traditional publication model. That decline has been hailed as "democratizing" publication, which is true in some ways, but mostly not.

Here's what I mean. In the 1960's (as I understand it), to publish a book with math and figures, you'd type the book on your typewriter (or have someone do it for you from your longhand notes). You'd leave blank spaces for equations and figures, which you'd draw in by hand. The publisher would then often hire someone to redo your figures, and they'd lay out and typeset your book to make it look great.

Then TeX and LaTeX came along, and authors realized they could make their own pages. And they did. Before long, publishers required this, because why should they pay someone when they can get the author to do it for free? So now the author had to learn LaTeX and go through the sweat of typesetting math. But the publisher would still often hire an artist to redraw the figures. My first few books were developed this way.

Then drawing tools got better, and more authors started using them, and again the publishers chose to make that all but mandatory (if you swore you couldn't make figures, they would hire an artist, but I know that at least sometimes you gave up some royalties in return).

Then indexing packages became more widespread. And so, rather than hire a professional indexer (and this is a much harder job than you might imagine, if you haven't done it yourself), that too became the author's job.

And so it went, with authors now essentially required to produce beautiful, camera-ready works, with headers and footers and footnotes and properly formatted bibliographies and on and on.

The author's job went from "write a manuscript, indicate the math, provide sketches for the figures, and let the publisher take it from there," to the far more demanding "produce the entire book in every detail."

Since most people can get the tools required, this is indeed democratizing, in that most anyone can make a professional-looking book. On the other hand, it means the author must have enough leisure (or paid) time to learn the tools, and then devote significant more time to produce all the content to a professional standard. This is pretty much the opposite of democratizing - it says only people who have a lot of available time can afford to produce a book with equations and figures that holds up to modern standards.

You've found some great ways to reduce this burden. Well done! I've taken a similar attitude in my own works, when I can. I'm now very happy to illustrate my work with hand-drawn pictures, as long as they're clear and do the job. I wish I could get away from fiddling with LaTeX, but programs like the one at are a big help.

It's interesting to me that we've gone from the author's job being almost completely about writing words and merely indicating the rest, to the author becoming a self-contained and fully staffed publishing house (with typesetter, artist, indexer, etc.), to now where you're shedding some of those tasks (e.g., pagination) and automating others (e.g., screenshots of code with automatic coloring).

What you're doing really does make it easier to write a book (not merely cheaper for a publisher to print it), and I say "Hooray!" The easier it becomes to produce quality materials, the better off we all become.

Thursday, January 28, 2016

Figures in my new mini-book

In my new mini-book I used a new (to me) fun process.  The process I am referring to as agile writing, is based on the best low-pain tools I could find.   It would not be unfair to say I wrote a minimum viable book (MVB).   The tools are mainly google docs, limnu drawings, and screen captures of vim with auto-coloring.   The code was super-easy because vim auto-coloring works really well IMO:

Note that google docs has a nice crop interface so you don't need to screen capture precisely.

The white-boarding in limnu took me a little getting used to, but works very well.   Here's an example of a screenshot from limnu pasted into google docs:

I asked Dave Hart and Grue Debry for tips on how to do figures, and what is funny is that their advice mainly boiled down to "do what you do on a real whiteboard".   That advice may seem content-free but it's not; I did change my mentality that it was "fast and loose" and I needed to not be too uptight.    I know this from using real white boards, but somehow I wasn't in that mode with a tablet.   But once I just pretended it was a whiteboard and not a traditional computer drawing program I got much better results.   They wrote up the advice at their site.

Wednesday, January 27, 2016

Process for speed-writing a book

I recently speed-wrote a mini-book  Ray Tracing in One Weekend available on the kindle store.

I loved doing it.   This post is about the mentality and tools for this sort of endeavor.

Over the course of my career in computer science there have been many trends that I think are good signs of maturation of our discipline.  One, for example, is the rise of programming environments with heavy GUIs like xcode and visual studio.   The one I like the most is the rise of “agile” approaches (this would be a counter-trend to the GUI programming environments).   The most obvious example is agile programming methodologies.    In line with that is the YAGNI (you aint gonna need it) to feature evaluation.   The lean startup and MVP is the software business manifestation of agile.

Something that in my experience is the opposite of agile is writing a technical book.   I think this is one reason most people don’t write one.   The book I have the most knowledge of is the one I wrote with Steve Marschner on Computer Graphics.   Everything about making that book was not agile. That is ok from the point of view of “is the book good?”.   Yes, it is a very good book.   And I know from working with Steve Marschner I would like to read any book he was involved in.   But I would be surprised if he writes more.   Not because Steve doesn’t like explaining things-- he is in his element in front of a white board.   But writing a traditional book is as much about wrangling LaTeX and Adobe Illustrator as it is about explaining things.   I would call the process “epic”.
Last year I taught a graphics class at Westminster College in Utah.   One thing about the class is that half the majors were taking it so I decided to gear it toward making it a fun class that gives a feel for what graphics is all about.   This is as opposed to a class the punishes the students with the “spinach they should eat” if they are going to make a career in graphics.  I think the class was really fun.   It occurred to me that maybe I should write a mini-book on ray tracing based on the class assignments. Then I thought about the epic book writing process and said “no way”.

Over the next six months as I occasionally posted things on my blog, I realized how un-epic blogging was.   First, you can’t control the exact visual format-- different browsers and size setting make that impossible.   Second, there is no cultural expectation that the graphics design elements or the language be perfect so you can just concentrate on the information.   This is an example of an agile process.   Then it occurred to me-- why not write an “agile book”.   And what is that?

First because it is a graphics book, it needs diagrams and equations.   What is the easiest way to do those?  I considered drawing them on paper or a white board and photographing them.   Instead I used a white boarding program, limnu, to make the process more fluid.

For the code, I didn’t want people cut and pasting any code.   I am a big believer in typing it in.   But I also think seeing code is often the best way to communicate something.   So I put in screenshots of code. For the writing, google docs seemed like the path of least resistance and something very fluid.  That is the entire tool chain.

Writing the book this way was fast and fun.   And since 100% of my brain was focused on generating the information rather than fighting layout tools and getting uptight about look, I don’t think the book is any worse than if I had spent five times as long and make it a traditional book.
All in all, I think this is a good way to write some books.   Write it fast, make sure the information is right (for CS writing code as you go ensures this), and stick to a narrow subject with a well-defined goal for the reader.   After the experience I definitely encourage others to write books this way, and I would like to read them.

New mini-book: Ray Tracing in One Weekend

Ray Tracing in One Weekend is a $2.99 Kindle book with an associated blog where I will outline some other one weekend projects (or promote yours-- this is a fun thing to do).  It is very much book for novices to get to a cool picture ASAP.  

Here's the image it ends with:
And interesting aspect of that image is the glass balls seem to float because they may focus light but with a diffuse field that mostly cancels out.  That was news to me and it took me a while to confirm it is no bug.     Try it with a real glass sphere next time it is cloudy :)

Sunday, January 17, 2016

Book project by Eric Lengyel

Eric Lengyel is taking an interesting approach to publishing a technical book-- crowd fund it and self-publish.    I really like Eric's work so getting a nice physical book that will not go out-of-date in my lifetime (math!) shipped to me for $30 is a no-brainer.    Here's the link.

Wednesday, January 13, 2016

Which Perlin noise is the best?

When one says "Perlin Noise" it's not clear which version of the noise function you mean.   Even using it inthe strict sense of which noise Ken Perlin described is not enough-- he has modified it in a later siggraph paper!

I asked Andrew Kensler at Pixar what noise I should use because he knows the most about noise of anybody in my extended ecosystem.   It turns out Andrew has an awesome tool for looking at the Perlin variants and a pointer to other work to help decide for yourself, as well as the best description of noise I am aware of.   It's part of his newwish blog I hope we will see a lot of.   Here's a screen shot of the setting for the original Perlin noise so you can visually compare as you play with variants:

Friday, January 8, 2016

Infrastructure for a mini ray tracing book

I taught a graphics (mainly ray tracing) course at Westminster College here in Utah a year ago and have been meaning to turn my course notes into a mini-book.   There is a very good and extensive book that introduces ray tracing by Kevin Suffern called Ray Tracing from the Ground Up.   I am not doing a book like that-- Kevin's is excellent and I recommend it to anybody learning ray tracing.   My notes are going to be a lot more narrow.    One thing that has delayed me a year is that I don't want to get sucked down the "graphics design rat hole".   I like pretty books and papers, but that "look"  component of a project can really suck the energy out and make a lot of your work concerned with latex and illustrator and delay things indefinitely.   Here is my mental image for the graphics design rat hole (image by Menard from here):

At the left in brown is an author's energy at the beginning.   The big contractions are various fights with latex, illustrator, whatever.

But courses are often not that way.   Almost all of the time is actually communicating.   And in the time one "perfect" diagram is constructed, you instead fill 10 white boards.    I think this is one reason youtube lectures/notes are often so good-- the energy goes into content.

Another force is that if you want an e-book that works for low-vision people as well as all devices, you really DO NOT have control over appearance.   The path of least resistance is essentially a text file plus images.   And really, what's actually wrong with that?   It avoids the graphics design rat hole!

What finally pushed me over the edge was seeing some of my class notes from my undergraduate physics classes by Richard Crandall and Nic Wheeler.   They were typed or hand-written with hand drawings.   Like old SIGGRAPH papers!    And they suffered 0% from this.   In fact they had an artisan quality that was appealing to me.

So I ask myself the extreme programming kind of question: what is the simplest way I could make an e-book?   

For images I could hand draw on paper, hand draw on a white board, or do the virtual of each.   Ever since I used limnu on an iPad Pro I have been making that my first choice.   Scrollable and editable and easier to get a digital image file.   For the text Pages or Word or google docs would all be fine.   The the first question is what hardware/software infrastructure for a "writing pipeline"?   Limnu runs everywhere so it is really a question of stylus.   First in class appears to be iPad Pro.    But if I am typing a windows10 box with a touch screen is attractive, and the workflow might be smoother.   I decided to go with an iPad Pro, but to my dismay the styluses are back-orders for over a month.   So I walked over to the Microsoft Store and ALMOST bought a SufaceBook.   It was super-attractive.   What did me in was cost-- once you add in Word and the GPU and enough memory it is pricey.   So I retreated and again asked "what is the simplest thing I could do?"   Answer for that is a children's wacom tablet (under $100) hooked to my laptop.    I just did a quick test and it is definitely NOT as fun as an iPad Pro but plenty good enough;  here's my test:
Quick test of limnu with a kid's wacom tablet
Next I will test Pages versus google docs for workflow and get rolling!

PS-- I checked the web and Nic Wheeler's hand-written physics notes are discussed and one of them is online.   He also did move to latex later it appears which does have the big advantage of being editable.    Nic gave me a 2D computer ray tracing assignment in 1984 and I was hooked and I often refer to his hand-written optics notes.

Tuesday, January 5, 2016

Photo layout issue on modern phones

In our Subjective iPhone app (please go buy it and rate it-- the "instant" filters have hit a sweet spot IMO) we've had many discussions on a layout issue I will share here.

Almost all mobile cameras now produce 4x3 images (since the optical system has a round lens, I do wonder why it is not 1x1.   Any ideas?), and almost all mobile screens are now 16x9, how do you display the images on a phone?   Here are the "natural" ways to put 1, 2, 3, 4, 6  4x3 images on the  16x9 screen (5 there is no "pretty" way).   After 6, things get too small IMO.

1,2,3,4,6 4x3 rectangles on a 16x9 screen
In our app, we wanted to do the "pick your favorite" UI inspired by A/B testing, subjective refraction at the optometrist, and Photoshop variations.   So 1 is great but doesn't cut it.   6 in a circle like Photoshop uses in the natural choice for big screens and 2D color spaces, but our screen is small and we often are not just navigating a 2D space.   If we want the long axis of the rectangles to match up (so you'll be holding the phone in portrait orientation for editing a portrait mode pictures, then 4 and 6 are really the only options.   We found 6 to be both too many choices, and too small pictures.   And like most engineers, we like it when there is exactly one good design choice :)