GDC 2008

Today is the last day of GDC. In the past two days food quality has slightly improved. Though after the 1st day, the less expensive pass holders started coming: a lot more people !
There are very long lines to get the lunch boxes, but luckily they go pretty smooth.

A combination of jet-lag and night coding sessions brought me to a completely screwed schedule, with the advantage of not having problems waking up in the morning.. because by 4 am I'm already up (whether I slept 10 or 3 hours 8).

Some lectures were pretty interesting. I've been going to multi-core programming lectures (lots of them, sponsored by Intel) rather than more traditional lectures.. and completely avoided most non-technical lectures.

I bought a RenderMan book and I started writing a simple RenderMan interface !
There is a lot of talk about off-line rendering going real-time, but I don't think that OpenGL and Direct3D 10, 11, 12 are the right way to go about it. There are a lot of things that we 3D programmers on the real-time side have to learn from the pre-rendered world if we don't want to be always lagging behind the pre-rendered movies.

Of course pre-rendered will always win in terms of quality, but it's important to embrace the off-line rendering systems build pipeline and then go on about tricks to scale quality down without having to rebuild models, textures and shaders from scratch.

I see RenderMan the way I saw OpenGL 10 years ago. OpenGL was considered overkill for games, until Carmack started using it with the support of 3Dfx.
If Carmack today said we should be using RenderMan, I bet everyone would rush to it.. but it's me the one that is saying it.. 8)

Today I hit a wall.. a performance issue that I was expecting sometime, but not quite as bad.

Currently I'm working with nVidia's Cg for shaders on OpenGL. One ugly thing about shaders is that one often ends up with a lot of permutations, depending on the number of inputs a shader deals with.
For example a shader may get vertex color in input while another may get texture coordinates in input.. it grows exponentially !

Each combination has traditionally been converted into a separate shader-program.. which is not nice, especially if there is no simple way to have all these programs instead share values that should be common to all of them.
For example any vertex shader will normally get one (or two) transformation matrix per-object, while an object is often built of different materials, thus different shaders.

In Direct3D 9 with HLSL one can set some virtual global registers, which is a bit ugly (there is a more high level system on PC but not on XBox 360) but does a nice job of sharing those values across programs. In Cg however, one has to explicitly connect shaders parameters.. which, as it turns out, can be pretty bad for performance.

My current shaders base is composed of 16 total shaders which all share 2 matrix transformations (to screen space and to world space). So, every time I set those two matrices for a 3D object, it really sets 32 matrices and it possibly even stalls somewhere.. because my frame rate will drop drastically for 1000 objects !!!
Basically I'm there not rendering anything and seeing FPS rate going from 90 to 15 just by setting up the transformation matrices for 1000 objects.

Supposedly Cg 2.0 (if combined with the latest nVidia cards ?) allows to have a common buffer that all shaders can share.
I'm curious to see how Direct3D 10 deals with those shaders params and state changes in general... however D3D 10 requires Vista, an OS that isn't quite as approved yet in my company.
Given the situation, I will be getting a new computer to be used to run Vista. As I picked the hardware I felt a bit guilty asking for relatively high end stuff.. but it's for work.. really !

wooooooo

P.S. Let's see if I can go to sleep before 4 AM tonight !

I guess I'm a fan of id Software. Steve Jobs used to snob games but now he invites John Carmack at the Worldwide Developers Conference 2007 ! It's nice to know that id Software keeps supporting the underdogs (the Mac in this case, but also OpenGL from a while ago).  read more »