OpenGL 4.3

I just got the news about the OpenGL 4.3 spec, which was released today, and is avail­able at http://www.opengl.org/registry/. The spec doc­u­ment has been reor­ga­nized and cleared up con­sid­er­ably and is a lot eas­i­er to fol­low than the pre­vi­ous spec­i­fi­ca­tions. New fea­tures include (ordered by impor­tance for my projects):

  • Queries for inter­nal tex­ture for­mat para­me­ters
  • Debug out­put call­backs
  • Com­pute shaders
  • Tex­ture views
  • and oth­ers

I’m cur­rent­ly on a project where com­pat­i­bil­i­ty and scaleabil­i­ty is prime, so the first two fea­tures are very wel­come as devel­op­ment aids to make the code run robust­ly on a vari­ety of plat­forms. Com­pute shaders and tex­ture views are of course cool, but require the newest hard­ware, so they are low­er in my list.

A nice touch by Nvidia to make to expose the new func­tion­al­i­ty as exten­sions on old­er hard­ware.

Cloud rendering and the relativity of whiteness

Here are some philo­soph­i­cal and ren­der­ing-relat­ed ques­tions that I took home from the last vaca­tion. What’s the col­or of clouds? The stan­dard answer would be, white.
What’s the col­or of snow? Again, white. Ok, then look at the fol­low­ing pic­ture, where the snow seems con­sid­er­ably whiter. This is the case in almost all pho­tos that I took.

There is an image on Wikipedia from the same gen­er­al area on which the bright­ness dif­fer­ence between clouds vs snow is even more pro­nounced. If you look at the direct­ly lit parts of the snow and con­sid­er it white (#ffffff), then the direct­ly lit parts of the clouds are at most 50% grey (#bbbbbb). Is that an evi­dence of air pol­lu­tion? Unlike­ly! (At least not in Tyrol).

Con­tin­ue read­ing

GPU Pro 3 has arrived

I found my copy of the book in the mail today. I was a lit­tle sur­prised by the mod­er­ate size—other vol­umes of this series were just that: vol­umes! I think this one is about half the size than the pre­vi­ous tomes. By the way, this post is a shame­less plug because there is an arti­cle writ­ten by me in it. Thanks go to Wolf­gang Engel, the series edi­tor, and Christo­pher Oat, my sec­tion edi­tor, and CRC press for mak­ing it pos­si­ble! I will post some com­ments on the oth­er arti­cles when I read them through.

Edit:
I found one very good and com­pre­hen­sive arti­cle on data dri­ven engine design by Don­ald Revie. The ideas pre­sent­ed in there res­onate very well with the designs that I found worked well in the past, so this part gets a sol­id +1 from me.

(I end­ed up with a tri­ad of IRen­der­Ob­ject, IRen­der­Ge­om­e­try and IRen­der­Pro­gram, where the ren­der object would AddBatch­es() to a draw list, each of which refers to one geom­e­try con­tain­ing the mesh and one pro­gram for set­ting the ren­der state. For instance, a SpeedTree™ ren­der object would typ­i­cal­ly add three batch­es, one for each of the branch­es, fronds and leaves, where each batch would pair the spe­cif­ic geom­e­try with an appro­pri­ate pro­gram. The draw list is then sort­ed in one go via a gen­er­al 128 bit sort key, and the batch­es ren­dered in order. This sys­tem is gen­er­al enough that the UI sys­tem also can just AddBatch­es() to this list (so the UI sys­tem, as a whole, is just one instance of a ren­der object). In this case, the indi­vid­ual UI geom­e­try objects just rep­re­sent views into one big dynam­ic ver­tex buffer. I prob­a­bly want to explain this sys­tem in detail in anoth­er post.)

Anoth­er two very inspir­ing arti­cles so far are the one about geo­met­ric post­process antialias­ing, by Emil “Humus” Pers­son, and the piece about glob­al illu­mi­na­tion using a vox­el grid, from the teams at the Unis Koblenz/Magdeburg. I already read their ACM paper before and I think it is a viable method.

Various Mac tricks

This is my per­son­al col­lec­tion of com­mand line tricks on Mac OS X that I found indis­pens­able. The list is far from com­plete, and may be added to in the future.

Show hidden files in Finder

> defaults write com.apple.finder AppleShowAllFiles true
> killall Finder

The first line sets the pref­er­ence for the Find­er to show hid­den files, while the sec­ond line restarts the Find­er so the set­ting comes in effect. As an alter­na­tive for the last line, select the Find­er in the Cmd-Alt-Escape pop­up and select “Relaunch”. I found this one on the Mozil­la knowl­edge base [2].

Delete all .DS_Store files

> sudo find / -name ".DS_Store" -print -delete

If hid­den files are enabled in the find­er, you will soon make con­tact with the infa­mous “.DS_Store” files that the desk­top ser­vice lit­ters around as you browse the filesys­tem. This is annoy­ing. Use the above com­mand to delete those suck­ers. The “-print” is in there just so you can mon­i­tor the progress.

Prevent .DS_Store files on network mounts

> defaults write com.apple.desktopservices DSDontWriteNetworkStores true

Although there is no method to gen­er­al­ly stop “.DS_Store” files, at least you can pre­vent desk­top ser­vices from pol­lut­ing net­work mounts. Win­dows users on the same net­work will be glad! This trick is pub­lished in the Apple knowl­edge base [3].

Disable Spotlight indexing for a given volume

> sudo mdutil -i off /mountpoint

This com­mand will dis­able index­ing for the vol­ume under /mountpoint (for instance /Volumes/MyExternalHarddisk). Under MacOS X 10.5 and lat­er, it also deletes any par­tial index cre­at­ed up to this point. There is one caveat: The enable/disable infor­ma­tion is itself stored inside the “.Spot­light-V100” direc­to­ry, so do not delete that, and be care­ful when back­ing up to anoth­er dri­ve. More infor­ma­tion is found in [1].


[1] The X-Lab, “Spot­light tips”,
http://www.thexlab.com/faqs/stopspotlightindex.html

[2] Mozil­laZine, “Show hid­den files and fold­ers”,
http://kb.mozillazine.org/Show_hidden_files_and_folders

[3] Apple Sup­port, “Mac OS X v10.4 and lat­er: How to pre­vent .DS_Store file cre­ation over net­work con­nec­tions”,
http://support.apple.com/kb/HT1629

ShaderX is searched by EPO

While googling the net, I found this remark­able piece. This is a patent appli­ca­tion from 2010, and from the draw­ings, it seems that the inven­tor had the ‘rev­o­lu­tion­ary’ idea of cal­cu­lat­ing some adap­tive depth bias based on the depth map to improve shad­ow map­ping.

The note­wor­thy part of the sto­ry is, that the offi­cial research, the patent clerk appar­ent­ly turned up my ShaderX4 arti­cle from 2006, as can be seen here fur­ther down on the page. The page also states that the appli­ca­tion has been aban­doned. So, maybe the exis­tence of this arti­cle has pre­vent­ed a patent on shad­ow maps, or at least dis­cour­aged the issuer to pur­sue the appli­ca­tion. In either case, let’s hope it stays that way!

We can draw two con­clu­sions from this.

  • Con­clu­sion 1: ShaderX seems to be rec­og­nized by the EPO as a source of state of the art.
  • Con­clu­sion 2: If you have an idea, write about and pub­lish it! It doesn’t mat­ter if it is just a blog post. If it can be tracked down, this can pre­vent a patent on the same idea in the future!

Comments on Advances in Real Time Rendering 2011

I final­ly got around to write some com­ments on this years Advances in Real Time Ren­der­ing held at SIGGRAPH 2011. Thanks to the RTR-team for mak­ing the notes avail­able. The talk about phys­i­cal­ly-based shad­ing in Call Of Duty has already been men­tioned in my pre­vi­ous post. So, in no par­tic­u­lar order:

Rendering in Cars 2
Christopher Hall, Robert Hall, David Edwards (AVALANCHE Software)

At one point, the talk about ren­der­ing in Cars 2 describes how they use pre-exposed col­ors as shad­er inputs to avoid pre­ci­sion issues when doing the expo­sure after the image has been ren­dered. I have employed pre-exposed col­ors with dynam­ic expo­sure in the past, and I found them tricky to use. Since there is a delay in the expo­sure feed­back (you must know the expo­sure of the pre­vi­ous frame to feed the col­ors for the next frame) you can even get expo­sure oscil­la­tion!

Con­tin­ue read­ing

The Blinn-Phong Normalization Zoo

It is good to see how phys­i­cal­ly based shad­ing is final­ly gain­ing momen­tum in real time graph­ics and games. This is some­thing I have been advo­cat­ing for a long time. Devel­op­ers are spread­ing the word. I was espe­cial­ly sur­prised to learn about Call of Duty: Black Ops join­ing the club [1]. Even a slick 60Hz-shoot­er with no cycles to spare can afford to do PBS today!

This leads me to the top­ic of this post, the nor­mal­iza­tion of the Blinn-Phong spec­u­lar high­light. Why am I writ­ing about it? It came to my mind recent­ly with the cur­rent batch of pub­li­ca­tions from peo­ple adopt­ing phys­i­cal­ly based shad­ing mod­els. This got me check­ing the maths again and I com­piled a list with nor­mal­iza­tion fac­tors for dif­fer­ent shad­ing mod­els, giv­en here in this post. I would also like to elab­o­rate a lit­tle on the mod­el that I wrote about in ShaderX7 [2]. Be aware this post is a large brain dump.

Continue reading