My Latest Hallucination

Ok, this is probably wrong, not only wrong, maybe even laughable, ridiculous, absurd. But then again I can't think of another solution.

http://www.doomworld.com/insanity/images/theory.jpg

Of course I exaggerated the effect in this sample. You're supposed to do this for little detail like wrinkles, not those big ripples.

What's so laughable about it?

but plausible..

I have absolute no knowledge on these kind of topics.. and your theory consists of no thesis you want to support. and your theory consists of 10 words and some pictures.

But still.. plausible..

What's so laughable about it?

Because I'm not sure if that's faster than drawing the hi-poly version on the world.

Correct me if I'm wrong here. You take a high-poly mesh, apply the shader and lighting effects to it in memory, then map the resulting image onto a low-poly version ? You're right, that would probably be pretty slow to do on every frame. Although throwing around a couple million polygons on every frame would be damn slow as well.

The Carmack works in mysterious ways...

Well in graphics the longest part is always the blitting. So yeah, displaying 10.000 polys is easier than 250.000

I wish there was a rendereable UWV Unwrapping in MAX, so I could make a better looking example with an actual character.

Well, thats the basic idea... However, I think theres a better way to do it. Instead of precomputing the whole skin every frame, why not make use of dot3 bump mapping? Just calc the error between the reference mesh and the ingame mesh and render it into a texture using gourad shading. Bump map it onto the simple surface to achieve a pretty good approximation of the ref mesh.
I think thats a pretty good way to do it, and of course much faster. Its quite better to render gourad shaded tris than multi-tex-mapped, bump-mapped and lit surface, isnt it?
Of course, thats just an idea; so dont take it too seriosly :))

Or, pre-render the whole game from all possible positions, in all possible angles, in all possible states of the world. Put rendered images on a floppy and release. Ta-da.

Yeah that sounds a lot better, PainElemental :)

However I wonder what really happens with the shadows. I suppose this extra detail cannot modify the casted shadows. Otherwise Carmack wouldn't have mentioned the deal about relatively low polycounts on Doom.

http://www.zaldron.f2s.com/theory.jpg

HEY, WHERE'D YOU GET THOSE AWESOME TEXTURES!?

You're so funny, Lut...

heh, you should've seen the conversation they had about TEXTURES.

I did.

No you didn't. It was on AIM.

It's an interesting idea, I don't think it's practical on todays machines for use in a real-time game "across the board". And you would have to discount Carmacks priciple that lighting should be done "at the pixel", and not using vertex lighting algorithms. The method you outlines would demand that lighting was done at vertex resolution (even though those vertices were quite dense :) ), transformed into a texture map, and then applied. And of course, you would have to discount the 3 to 5 passes in graphics hardware that he claimed will be required per light. The advantage of your method, while killer on the CPU, is that all the lighitng can be rendered into a single texture map, thus eliminating the need for multiple passes-- just one texture needs to be applied per frame per model instance.

The interpretation I made was that the modelers went nuts with polys OFFLINE in the modeller. Then, using typical Carmackian preprocessing, the models are "decimated", or reduced in terms of polygon density, to an acceptable level of 1500 or so polys. (This would be reasonable in terms of memory, polygon proccessing, and shadow volume generation). The genius of the work, is that the bump maps aren't drawn by the artists (by the most part), but calculated from the high-resolution model (much the way you outlined would be done). But this is only done in pre-proccessing, not in real time. Those high-res 500,000 models will never even see their way onto the CD-ROM we'll get, probably. The lighting work will be done in the 3 to 5 passes that is making all of the GeForece1/2 people cringe. The CPU will be occupied doing the shadow volumes-- not to mention the fact that there is an actual game code that has be run through the proccessor, as well...

It's a wonderful idea, though-- maybe in the next few years when CPU's get much faster, that will be a good way to do the graphics in games so the graphics card can really just conccentrate on effects proccessing like shader materials and stuff.

Actually I was using a Blinn material, and that demands per-pixel lighting. However you're right, specially if you take in mind Carmack's latest post on Slashdot, where he mentions (for completely unrelated reasons) the presence of "normal maps" based from the hi-poly versions.

Altough I still have a doubt : there is no good way to animate a mesh without deforming the triangles. Now there's no problem in conventional skinning, the UV parameters are modified accordingly. But what happens in this case? If you want to succesfully illuminate a model in a specific frame wouldn't that require a normal map from the hi-poly version in the same conditions? Skeletal-based animation on +500.000 polys characters can get very, VERY slow.

Altough I still have a doubt : there is no good way to animate a mesh without deforming the triangles. Now there's no problem in conventional skinning, the UV parameters are modified accordingly. But what happens in this case? If you want to succesfully illuminate a model in a specific frame wouldn't that require a normal map from the hi-poly version in the same conditions?

That's a very good point. There are two things that could resolve this problem-- one technical, one "practical".

On the technical front, the way normal maps are shoved through the rendering proccess is by using "texel-space" transformations (as far as I understand it from some documents I've (tried) to read ) . This means that, through some nifty trickery, the normal maps aren't in "world space", but interpolated across the "vertex normal-spaces" that define a polygon. In effect, animating the vertex normals has the effect of "animating" the normal map. It's a simple linear interpolation animation, but for the most part, so is traditional interpolation between vertices in weighted skeletal animation. And that brings to the second point--

Even though Carmack protests that it isn't a "high-polyon" engine, 1500 polys for a character is still a great deal. Seen from even a short distance away, with the thing moving and shooting at you, it's unlikely any but the most hard-core player will notice the slight variation an un-animated normal map vs. an animated normal map would show in the small region of each polygon, much less a linearly animated normal map vs. a hypothetically "full-geometry" animated normal map (at least head on).

And lastly, you have to remember-- though Doom3 will be amazing beyong anything we mortals should dare to hope for, it isn't the absolute final step in real-time graphics. There will probably be anomalies, and little hints that it isn't "real". Quake1 was extremely impressive when it came out, but you could tell it wasn't real. With Doom3, Carmack has simply narrowed the gap an awe inspiring amount...

And lastly, you have to remember-- though Doom3 will be amazing beyong anything we mortals should dare to hope for, it isn't the absolute final step in real-time graphics. There will probably be anomalies, and little hints that it isn't "real".

Well, I think it'll be obviously, but a lot of it will depends on character animations. I thought from the RtCW screenshots that it looked spectacular. Then I played the game, and laughed. The animations in the MacWorld video acted very cartoony, but I'm sure they'll be a lot better when the final game is done.

It seems as though the better the technology is, the more holes there are in the game. For instance:

Doom: Runs smooth. The enemies always act like they are supposed to, the elevators usualy go off without a hitch, and there are rarely any places where the walls dissapear.

Half-Life: Enemies sometimes do something really weird (i.e. aliens not teleporting back out from the test chamber), you can get stuck in elevators, crushed by small objects, walls dissapear when it is running slow.

I guess thats the price of progress.

It seems as though the better the technology is, the more holes there are in the game. For instance:

Not really. Doom had a lot of stupid errors too, even in later versions. Enemies got caught on doortracks, there was the fact you couldn't even jump over them, you could get clawed by imps who were in a pit 10000 pixels below you if you stood by the edge, etc.

There's always gonna be quirks and stuff as long as people don't take the time to fine-tune their new technologies. I think some of the developers can get stuck in the mindset of previous technology, i.e. they take care of problems from earlier games (like some of Doom's blatant mistakes), and are happy those are out of the way, but still don't take in the possibilities for bugs the new aspects of the game technology present.

.......

I DON'T SAY ANYTHING APPLICABLE TO THE CURRENT SITUATION GUY

Ok, this is probably wrong, not only wrong, maybe even laughable, ridiculous, absurd. But then again I can't think of another solution.

http://www.zaldron.f2s.com/theory.jpg

Wtf is this?

No you didn't. It was on AIM.

was it the chat room where i idled the entire way through it?

Heh, all this made me realize. There's quite some limitations about how much you can optimize the model before screwing the calculations. In a normal map, a black pixel next to a white one means a 90° angle. That's the maximum angle for micro detail that can be displayed correctly, altough is a bit too drastic IMO.

You can make a 500.000 poly sphere and optimize that for the game, ending up with a simple 100 faces model. But if your model has a lot of concave areas (for example an Alien model) its gonna end up as a lot more than just 1500 polys.

Doom: Runs smooth. The enemies always act like they are supposed to, the elevators usualy go off without a hitch, and there are rarely any places where the walls dissapear.

Half-Life: Enemies sometimes do something really weird (i.e. aliens not teleporting back out from the test chamber), you can get stuck in elevators, crushed by small objects, walls dissapear when it is running slow.

Doom runs smooth because it's minimal CPU hit. The enemies always act like retards, and the elevators always work because hell, if they can't even code that right...

In Half-Life those errors you mentioned are human errors. The errors in the monsters behavior is due to lame scripting. Getting stuck in elevators, well, there's a difference between coding a collision system in a 2.5D engine and in a 3D one. "Crushed by small objects" is the mappers fault, who for some odd reason activated the flag that kills you when you block the object's path. And the dissappearing wall is a method to fight the "leftover" overdraw product of non-perfect VIS calculations.

I have a question about procedural textures, or the capability of an engine to create textures on the fly, I was thinking, is it possible with bump-mapping and the afore-mentioned procedural textures.. to create realistic impacts against a wall? For example, most weapons leave a "decal" against the wall to signify an impact.. now a game that has this "procedural texturing" could the engine blend the texture and decal, and the wall textures bump map and the decal's bump map then redraw the resulting textures? So instead of leaving a black mark against the wall, it actually looked like an indentation? Is it possible?

Also while I'm at it, I dunno how many have seen this..but regardless, have a look anyway
http://www.theproduct.de

[edit] aww shit, I knew I missed something in that link, it should be correct(working)now [/edit]

Yes, they can make decals using bumpmaps, and that's gonna look superb. In fact, if they're making specular maps for the textures then they can even make multi-material textures. The parts in wood will show the proper decals, and splinters will came out flying, hit a screw and it will behave like metal.