Friday I got to test a new model that I'll have to use for my current project.
The unoptimized model had over 1M polys (it's a small one 8). I went on to display it with the DX10-based engine and it crashed the (NVidia) driver.
The model is actually composed of many smaller models, so it's not like there is a huge vertex buffer. It also had no textures and I was using a simple common shader.
The only issue I can think of is the range of coordinates which it's relatively very large. It's a laughable supposition, but everything points to that. I'll have to debug to find a workaround.. but it's not easy considering that those driver crashes force me to reboot almost every time ! (Vista stays up, but I can't do 3D anymore).
This is a really bad setback. For the test I eventually displayed the model with my ultra-basic software renderer... no crashes there ;) ..and if there were, I could have fixed them myself.

Another thing that bothers me about DX10 and drivers in general, is how one has to guess performance, because the internals are obscure.
For example, using an NVidia 8800, I noticed that performance is a lot worse when using buffers flagged as "dynamic".
This whole "static" vs "dynamic" thing is apparently part of DX10 and Vista's driver model. Somebody, somewhere, probably decides to put the buffer in system memory (as opposed to GPU memory) under the assumption that the buffer needs to be touched frequently. Only, I may want to change it rarely, and also I was sort of expecting for the buffer to be allocated directly in the GPU memory and only be mirrored in system memory if I ever tried to read from the buffer (which I wouldn't dare to).

So, I have to be really careful and only use the "dynamic" flag for things that change frequently.. and possibly forget about building a flexible system that uploads textures and geometry on-demand.. which is otherwise theoretically very possible with no (not much ?) performance degradation.
As it stands, it seems almost that dynamic buffers are being uploaded per-frame, regardless of the fact that they aren't being modified per-frame.
..this is all speculation of course.. but that's what I really don't like about this: having to spend time trying to guess what those drivers do behind my back.. and hope that different drivers on different card will behave similarly (crashes aside ;).

For this reason I hope that the time will come when game companies can write complete graphics pipelines again. Either in-house or licensing code, but staying away from closed-source drivers, so that one won't have to debug and profile in the dark.

Some are worried that they couldn't possibly do much better than what card manufacturers already do with those drivers.. I think that there is plenty to improve by just getting rid of those fat drivers that have been plaguing PCs ever since 3D cards came out.

ole'

I'm glad that Carmack spoke out on ray-tracing for real-time. More precisely against the approach that Intel as been semi-officially following.
Shooting at triangle soups with cosmic rays is hardly efficient.
Predictably, Carmack has mentioned a possible evolution from 3D worlds made of very many unique texels to 3D worlds made of very many unique texels in 3D space.. basically voxels in sparse matrices (using run length compression for hollow spaces inside objects (assuming that one doesn't want to render actual solids 8)).

Using voxels (in sparse matrices) is definitely attractive, but the transition from 2D textures isn't so straightforward. Good resolution textures are only efficient because of mip-mapping. Mip-mapping is largely based on a static pre-process (creating smaller resolution copies of a texture).
When animating a model, one easily moves vertices that define polygons, while the heavy details are in textures that are based on static mip-maps.
If polygons go away, and there are only voxels (fat points) available, one would still need to do subsampling somehow, depending on the size of an object.. or else aliasing artifacts and terrible cache trashing would become major problems.

Anyway, today (Saturday) I went to work and I started writing a software renderer.. nothing new, and very very basic so far (one point per vertex !), but it's a good time to start, especially now with that I have a better understanding of hardware shaders.

..I think I agree on software renderers having a future, but I'll write more on that later.

zzzzzzzzzzz

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)

Portland_2008_01 (public)

I arrived in Portland (OR) a couple of days ago and I'm going back to Tokyo tomorrow !
It was my first time here, though I've been in Oregon before.
Compared to San Francisco, Portland looks a lot more safe. But also deadly cold. It seems that most people wear hats, and I can see why. One day I had my ears freezing from the cold wind.. so hats after all aren't just a fashion thing !!

I'm here for business, but I can't really talk about it. Exciting things, but I still think I'd be more excited if I got a substantial pay raise ;) ..cough cough !
I'll be back on Sunday and Monday already to work. I want to get busy with code, but instead there will be some management/business/financial things to talk about.

Talking about code. Just before leaving, I made some sensible changes to the engine I'm currently working on.
There really isn't a proper way to do anything. One can throw random polygons at a rasterizer and get terrible performance or group geometry (and textures) in a certain hardware-friendly fashion.
Depending on the file format and on the average organization of mesh data, one has to come up with the best compromise. So, for example, in most cases having every polygon listing a different material is a bad idea.
Then one can group polygon lists using the same material, but do those polygon lists all share a common vertex pool or should every polygon list have a separate vertex pool ?
If lists are few and made of many polygons, then it may be wiser to have separate vertex pools, this is also because if every list has a different material, different materials could imply different vertex attributes (if there is no texture, then there is no need for texture coordinates, etc).
This also reminds me of the pain of using uber-shaders (long shaders) with DX10. Sometimes long shaders will ignore some input vertex data, but feeding null buffers gets DX10 debug mode to spit out thousands of warning messages in the output console.
I dunno.. DX10 doesn't really seem like the ultimate solution. It shifts the weight of state changes towards the application program, which is nice and not so nice at the same time.

And finally, some great news ! I'm leaving in 5 hours and I still haven't lost my digital camera 8)

woooooo  read more »

Getting sleepy here.. I had a Melatonin pill of those bought in the USA, made to put asleep bull-sized individuals.

Someone mentioned about posting about graphics, so here is my thoughts about the coming future. Not sure when but it's coming.

First let's think about texture mapping. I remember when Deluxe Paint on the Amiga first implemented perspective projection of images was rather slow and the quality wasn't so good.
The problem was that it would take every single pixel of the source image and try to put it in perspective. This works OK if the perspective image is relatively big respect to the source image, but it's a big waste of calculations if the perspective image is actually using few of the source pixels.

Texture mapping is the same thing. Aside from a few crazy attempts (Sega Saturn and nVidia NV1), texture mapping is done by selecting a texel for each pixel that needs to be drawn (more in case of filtering, but still a fixed number related to the number of pixels).

This works in the assumption that polygons are probably going to be smaller than textures which are big enough to cope with a few bigger polygons.
The real issue is really with perspective projection, where things can get very big or very small and one must take into account this scalability.

Texture mapping is now well optimized and, in combination with mip-mapping, can handle all polygon sizes efficiently.

Enter the geometry: as we put more and more details into geometrical definitions of 3D objects the same problem of not wasting time hitting the same pixels comes up.
A very detailed model with 100,000 quads only really needs about 20,000 quads if it covers 100x200 pixels, for example.
This model will still look pretty ugly when we zoom in into some area that is supposed to be round but that doesn't look so round anymore at that distance.

So basically, we need geometric level of detail (LOD). This is something that was being pursued 10 years ago but that hasn't quite made it yet.
To scale geometry properly one probably needs filtering as it happens with texture mapping. The simplest implementation to understand this is displacement mapping, where one has a texture that can "lift" pixels by crating triangles on the fly.
This is not so easy to implement efficiently in current hardware, but I think it only makes sense... though actually calculating how many triangles one should generate (tessellate) is not trivial to do efficiently.

Still, for the time being it would be good enough if one could use texture samplers to store geometry that would scale nicely without any artifacts.

Another nice solution for geometry LOD is "texture images" from Hoppe which was pushing progressive LOD at Siggraph 97.
Geometry images imply a dense sampling around a whole genus-0 (without any holes) mesh but at the same time it doesn't require explicit primitives definition, no vertex indices, as every triangle/quad is implicit by the grid-like distribution of the texture that makes the geometry image.

mumble mumble

I checked-in in some sort of Golf Resort & SPA in Phoenix (Arizona) yesterday.
Actual business started today with some Welcome event. I publicly can't talk about the event itself but I can definitely say that it was quite interesting.
It was mostly about 3D graphics, under different aspects. Very interesting talks with lots of intelligent people.. well men mostly 8(

I took a few pictures, but I need to find the time to get them on the laptop ahhhhhh........

zzzzzzzzzzzzzzzzzzzzz

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 »

A few days ago I was talking about real-time 3D moving towards programmability and now Intel comes out with a more detailed report of their upcoming Larrabee technology. Basically Intel extending CPUs towards the GPU domain.

This is all very cool, but I don't see any mention on actual software technology. We know that Intel has been doing research on Ray Tracing, but the real issue for 3D in games is productivity. Not an easy problem because it involves tools and artists and programmers together.

With all this quality, productivity, predictions, etc, kind of topics floating around, recently, I've been using wikis, PowerPoint and Excel a lot more than compilers 8(

My employer has been involving me more and more with 3D technology development for the company. Very nice indeed !!
From time to time, I get involved with very interesting technology previews. What I see is not what I can report of. Also early preview of things don't normally tell the whole story. However, it seems that programmability is coming back in a big way.
This is somewhat obvious, considering how programmable shaders are getting constantly more powerful and pervasive. Also, with the PS3 almost going Cell-only, with nVidia releasing CUDA and with the academical world wishing for more GPGPU.

With great programmability comes great uncertainty: what's next ?  read more »