Getting ready for Siggraph 2008
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
- Davide's blog
- Login or register to post comments


hhmm in my experience
hhmm in my experience whenever you add some automated element to the build/authoring pipeline, artists are usually the 1st to complain, because it doesnt come out looking exactly like they wanted.
a very simplified (and outdated) example are palletized textures. you can easily automate the palletization process since this topic has been around for a while and there are some very good palletization algorithms. But many artists would rather tweak the pallete values themselves.
In the end it is impossible to make a palletized image look exactly like the original, but they still always prefer their version.
Basically artists always want more control.
I agree with Rince. There
I agree with Rince. There should be some provision for the artists to have direct control over their data (if the case should arise). I'm a complete fan of automation, but sometimes that fails to meet the goals as it can't (yet) determine what subjective quality the artists are seeking visually.
Removing unneeded color
Removing unneeded color channels isn't going to affect the final result. Also compressing lossy but at very high quality shouldn't make a difference.
When it comes to polygon reduction and in general to degrading decompression depending on target's performance then it becomes a problem I guess.. ..but those are two separate things.
Anyway I'm working all the way together with technical artists. I'm aware of issues stemming from thinking things without the artists overseeing it all along.
Omniview
Kaz-omniview sees all the issues ... except the hidden ones. 8P
Actually, one thing I've always noticed at wondered about are asset sizes. More power seems to lead towards large data-sets, which in turn leads towards it taking longer to process the data. I wonder what are the upper limits to this kind of thing.
I've also been recently learning Python mainly to facilitate the R&D I'd like to do at home. Once "nice" thing about not having a large number of people to do work is that it forces you to start to look for ways to automate as much as possible ... or at least find ways to reduce the amount of time doing auxiliary coding work. Dive Into Python is a nice free way to get into the language.
Actually in R&D we have a
Actually in R&D we have a system to distribute computation across multiple computers. We have dedicated computers for processing but also use our own development machines can contribute. Ideally everyone would contribute to a build.
Python is great for scripting but for the heavy stuff C/C++ is necessary.
Storage Medium Issues
Check this out: QuakeCon: Carmack Talks Blu-ray Advantage Over Xbox
My posting it isn't so much because Carmack said so, but that's one of the many issues I've heard about storage. So basically, if one has an asset pipeline that can generate asset sizes in hundreds of megabytes, then definitely having some kind of control on how things are processed automatically is important. I think there will always been issues of "not enough space" ... at least when it comes to consoles anyways. But who really knows what the future will bring. 8P
OpenCL
Fascinating: OpenCL. The future is going to be interesting. :)