Yesterday night I went to ageHa club in Tokyo to listen to Ferry Corsten.
I'm a big fan of Trance music.. it was great.. if only I weren't thinking all the time that I wanted to go back home and code !!

As I pretty much still develop on Windows, I've been using my Vaio laptop at home (not laptop from the company, they promised it once, but then took it back 8( ).
At home I only have a small desk and that's for the iMac. So when I use the Vaio it's on the kotatsu, with it's limited monitor and keyboard... not the best environment for developing (it's important to have a full size keyboard to write code !).

So, yesterday I decided to try installing Visual Studio on the iMac under VMWare Fusion. It works surprisingly well (I have 3GB of RAM). DX9 support doesn't seem to be there, but it's probably a setting or an upgrade. In any case recently for me it's either DirectX 10 (ewww) or software rendering (slooww).

Speaking of software rendering, I started with the idea of implementing a RenderMan state machine and borrow from RenderMan Shading Language. But the tendency is more towards Mental Ray.. which interestingly implements shaders as DLLs compiled in C/C++ (I've heard that Pixar itself does use all sort of languages to write shaders).

Writing shaders in C++ is one of my goals. HLSL/Cg kind of shaders are rather limiting, but for a good reason, those limits make it easier to write compilers that can parallelize operations. Still those limits are becoming unbearable and if shaders are written in C++, they can potentially run at the same level of a 3D engine on the same platform without having to create all those silly contractual interfaces like it happens with HLSL for example.
There will always be a problem with optimizing the interface between engine and modular shaders or any kind of module, but still, not having to worry about heavy state changes, buffering hardware display lists, etc etc, is going to make it easier to solve certain problems in different ways.

I see HLSL/Cg shaders like the (Macromedia) Flash of real-time 3D graphics: an excellent platform that can bring to great results with minimal effort, but a very limiting platform, eventually forcing a whole mindset to down the throat of an entire generation of graphics programmers.

It's important to be nonconformist sometimes !

woooooooo

A quick note to express an opinion on Direct3D 10.
It seems very focussed on static mesh rendering, but has no support for direct primitive rendering like OpenGL. So, once again I have to write a layer to be able to draw lines and polys for debugging and quick prototyping.
Direct3D 10 has this "state objects" concept, so now changing states has to be done either selecting different predetermined effect's "techniques" (a technique can select different states) or one has to change states by creating state objects for every combination... what a pain !

I've moved form vertex/pixel shaders to "effects". I still have to see how effects handle render targets with annotations, but it seems like a not very well defined matter. For one thing, nVidia's FX Composer 2 seems to be the better tool to building effects, but at the same time it doesn't support Direct3D 10.. geezz

As GPU programmability is improving, it feels restrictive to use Direct3D 10. Interfacing C++ with shaders is a pain.. but at the same time shaders make it very easy to write highly parallel code.

ummmmmmmm

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 !

Today I was going to implement a basic shader with support for texture.
Shaders are separate programs for the graphic card that will execute specific code based by some parameters.
I was trying to keep the shaders interface system as simple and generic as possible and I got stuck.
Shaders do suck, but I'm not sure if they necessarily have to suck. What sucks is how one has to think..
For every 3D mesh there is one or more sections (primitive/display lists) with different materials. Each material involves different properties. Vertex data normally includes 3D coordinates, but also texture coordinates, color values, normal coordinates.

Some materials will need no texture coordinates, some will need more than one. Some will need no texture mapping, some will need one texture map per every texture coordinate, some will need a different number of texture maps and texture coordinates.

So each material brings different needs, but that means that there are potentially a different vertex and pixel shader programs, all of which need to be connected to the vertex and material data (a material can list one or more texture maps).  read more »

Just as I was going to move back to Gallery2, PicasaWeb extended the free space to 1GB (and counting). So, i could upload more pictures from GDC and San Francisco downtown around the GDC.

The second day was again about lectures. I started off with the Physics for Games Programmers tutorial, but quickly realized that it was going to be pretty basic, so I switched to Large-scale Engineering for Online and Offline Games. It was an interesting lecture, on how to distribute and organize workforces, in the same office or spread around branches.
What I didn't like much was some guy from Unreal, talking about pair programming as a way to get programmers to work with much less distractions. Nice.. for you !!!  read more »