Tag Archives: blog

Why submit when you can blog?

I was cleaning up the RTR portal page today. Of all the links on this page, I often use those linked in the first three items. I used to have about 30 blogs listed. Trying them all today, 5 have disappeared forever (being replaced by junk like this and this), and 10 more are essentially dead (no postings in more than a year). Understandable: blogs usually don’t live that long. One survey gives 126 days for the average lifetime of a typical blog. Another notes even the top 100 blogs last an average of less than 3 years.

Seeing good blogs disappear forever is sad for me. If I’m desperate, I can try finding them using the Wayback Machine, but sometimes will find only bits and pieces, if that. This goes for websites, too. If I see some article I like, I try to save a copy locally. Even then, such pages are hard to find later – I’m not that organized. Other people are entirely out of luck, of course.

My takeaway: feel free to start a blog, sure. But if you have some useful programming technique you’ve explained, and you want people to know about it for some time to come, then also submit it to a journal. One blog I mentioned last post, Morten Mikkelsen’s, shows one way to mix the two: he shows new results and experiments on his blog, and submits solid ideas to a journal. I of course strongly suggest the (new, yet old) Journal of Computer Graphics Techniques (JCGT), the spiritual successor to the journal of graphics tools (as noted earlier, all the editors have left the old journal). Papers on concise, practical techniques and ideas are what it’s for, just the sorts of thing I see on many graphics blogs. Now that is journal is able to quickly publish ideas, I dearly want to see more short, Graphics Gems-like papers. If and when you decide to quit blogging/get hit by an asteroid/have a kid, if prior to this you also submitted your work to a journal and had it accepted, you then have something permanent to show for it all, something that others can benefit from years later. It’s not that hard, honestly – just do it. JCGT prides itself on working with authors to help polish their work and bring out the best, but there are plenty of other venues, ranging from SIGGRAPH talks, Gamasutra articles, and GPU Pro submissions to full-blown ACM TOG papers.

Oh, I should also note that JCGT is fine with work that is not necessarily new, but fills a gap in the literature, explains an improved way of performing an algorithm, gives implementation advice, etc. Citing sources is important – don’t claim work that isn’t your own – but otherwise the goal is simple: present techniques useful for computer graphics programmers.

By the way, if you do run a website of any sort, here are my three top pet peeves, so please don’t do them:

  • Moving page locations and leaving no forwarding page at the old page’s location (I’m looking at you, NVIDIA and AMD) – you don’t care if someone directs traffic to your site?
  • Giving no contact email address or other feedback mechanism on your web pages – you don’t want to know when something’s broken?
  • Giving no “last updated on” date on your web pages – you don’t want people to know how fresh the info is?

NVIRT, a mini-blog, and “Creating Games”

I’m at I3D 2009; tonight at the dinner Austin Robison at NVIDIA announced NVIRT, which is NVIDIA’s ray-casting engine. I say “casting” as the idea is that you feed it objects, hand it a ray generator and it gives you back the ray intersections desired. Certainly it can be used for ray traced rendering, and the constructs presented make it clear they have thought through this aspect: rays can terminate on the first intersection found (useful for shadow rays), or can return the closest intersection point (eye/reflection/refraction rays). Rays can continue on when a fully transparent object is hit. Objects can be put in any efficiency structure you wish, and structures could be contained by other structures (Jim Arvo’s metahierachies idea). For example, you could put static geometry in a k-d tree, which is highly efficient but expensive to update, while placing dynamic objects in a bounding volume hierarchy, which usually can be updated more easily (though losing efficiency over time) by growing bounds. You have control over what efficiency methods are used.

They’re thinking of this SDK in more general ray-casting terms: collision detection, AI queries, and baking illumination or other characteristics onto surfaces. I can certainly imagine uses for engineering simulation. It runs on CUDA, but hides CUDA programming from the user. By the way, the switching time between CUDA and the graphics API will someday soon be a lot less that it is now.

This SDK will be released sometime this Spring (it will also be incorporated with NVIDIA’s NVSG scene graph SDK, as a separate release). The SDK will come with lots of samples, including source fo a basic ray-tracing renderer. All in all, an interesting development. The catch is, of course, that CUDA does not run on anything but NVIDIA hardware. Nonetheless, this is a fascinating first step. Austin says this effort is a serious attempt by NVIDIA to put this sort of engine in the hands of developers, not some “let’s see if this research sticks” half-baked release. Hearing him talk about the bits of inside information their group learnt about the operation of the GPU, and the corresponding boosts in performance, makes me wonder if other GPU-based ray tracers out there will be able to get near their performance.

I have a bunch of links saved up, which I’ll dump here someday soon, as well as more about I3D 2009 (see Jeremy Schopf’s blog in the meantime). For now I’ll just mention one quick link: Morgan McGuire’s twitter blog. No, it’s not a “I’m drinking a latte and using my iPhone” twitter blog. I like the idea a lot: it’s where he simply puts any great links he’s run across, with a quick description for each. Low maintenance, minimal effort, and useful & interesting, at least to me. It’s about game design and related topics (and unrelated ones) as much as graphics. This is one of those “everyone who finds cool stuff on the internet should do this” concepts, as far as I’m concerned. Sure, there’s del.icio.us and similar social bookmarking sites, but a blog lets me know when there’s something new from someone I respect.

Morgan is one of those uncommon people who has considerable industry experience (e.g. “Titan Quest”) while also being in the academic world. He’s a coauthor of the new book Creating Games, which I had been jumping around inside and sampling snippets, and am now sitting down and reading for real. It is aimed at being a book for teaching a college course on making games, both board- and video-, giving a number of schedules for 3 to 4 week projects and worksheets for these. However, these are appendices; the focus of the book is well-informed surveys of a wide range of game design and creation practices. The first chapter has a great startup project for small groups in a class: “here are some dice and pieces of different colors, some paper – go, make a game in 7 minutes.” Anyway, not graphics related per se, but there’s certainly a lot about the computer games industry inside, much of it technical and practical. My favorite illustration so far is the dependence graph amongst the art assets for Spiderman 3, Figure 3.8 – daunting. You can look inside at Amazon. Me, I’m an avid boardgamer (I was up too late last night playing Dominion with Morgan and Naty Hoffman – consider me entirely biased), so I’m enjoying reading it and thinking maybe I should try to design a game…