JavaKazRace - Playable Java racing game demo
PSEmu Pro GPU plug-in
DOSX Utils
SHLight 2004
JavaKazRace DSharingu PSEmuGPU DOSX Utils SHLight 2004

Office

Getting ready for Siggraph 2008

Davide's picture

I'll be in Los Angeles in two weeks for Siggraph 2008.
Because of that, I've been coding a bit less and spending more time with Excel and Power Point, preparing for some meetings that I'll have there..
Using MS Office depresses me. I used to pride myself of not understanding what possible use for Office I would have.
Now, I think it's important to make Power Point presentations for all those people that aren't talking with you daily and that can't or won't understand code. One must learn to communicate and perhaps to inject some hype, too (MegaTexture, Geospatial, real-time Ray Tracing ;) ..but when time is scarce, then it's depressing to think that I could be effectively writing code and solving interesting problems rather than picking a nice font or resizing a picture in a corner of a presentation slide.
This reminds me a Dilbert strip that to me is now more real than ever: at an external site there is Wally's head coming out through a hole in table, inside a glass bell. Wally's face looks tired and unshaved. A spectator is looking at it while Dilbert explains: "this is what our 3D product would look like if we didn't have to waste time preparing demos". ...my feeling exactly 8)

Anyhow, I did write some code too. For one thing I'm at a good point with this "geometry processing framework". Basically a 3D engine tailored for geometry manipulation rather than rendering.
I once wrote something that was mixing both geometry processing and rendering, but it was a bit of a pain to maintain.
Personally, I think that it's more difficult and more important to put down those kind of frameworks rather than getting Direct3D/OpenGL to spin an object. Making API calls to a spoon-fed rendering interface is not the same as manipulating, optimizing, organizing data.

On the texture side, I've started writing some Power Point (indeed) and the goal there is to push the system rather than the format. The idea is that a JPEG-like format is being built but it's important to see how the eventual engine behind will handle it best, unpacking at selected texture resolutions on the fly depending on the VRAM and bandwidth budget.

Very important is also the build process. I've been asking artists not to optimize textures. Current assets are good enough to make high quality pre-rendered movies.. one character uses about 1GB of texture memory. However, many times these textures include an alpha channel that is not used and that can safely be removed. Bump maps, which only need one value can also be converted from RGB to grayscale (can't do it for color textures because in DX10 there are red-channel-only textures instead of luminosity textures (bha !)).
Anyway, the idea really is to make things as scalable as possible.. this is exciting because it gives authoring freedom.
One could ask an artist to make a model at a specific resolution or even to make one highres and then manually convert it to lower res with normal maps.. but that's all time wasted doing manual labor. Manual work is what should be avoided.. artists shouldn't worry about simplifying geometry unless they want to.

Time to sleep.. the Melatonin is finally making it's effect 8)
zzzzzzzzzzzzzzzzzzzzzzzz

Syndicate content