Gildoran

Yeah, it really bugged me that everybody decided to switch to mitten hands when there were plenty of less noticeable things that were wasting far more triangles... For example, why the heck was this belt-buckle fully modelled? Altogether, including the center part and both sides, the belt buckle should have taken 2, maybe even 6 triangles (by having the belt-buckle drawn with an alpha-test material - the design philosophy of D3 is to put the detail in textures, NOT model them!), but instead it looks like it takes 100. The models are full of things like this and everything is subdivided more than necessary... such wasteful use of triangles is why a single guard entails a 20 fps hit! Don't get me wrong, oDDity is an artistic genius and I wish I were even half as skilled as him, but I consider his judgment for low-poly modelling to be ... exceptionally lacking. Edit: Sorry... this has been building up and I just felt like venting.

If I were to implement save restrictions (don't worry everybody, TDM isn't going to have them ), I'd do it by having two map script functions: float canSave(); // returns non-zero if the player can save void saved(); I think using these two functions a mapper could implement most save policies, such limited but global saves, only being able to save when outside of a restricted area, etc.

While I understand that the depth-buffer doesn't help to depth-sort translucent triangles... it would have been nice if there was some way to partially sort them by depth before sending them to the renderer. (with the caveat that pathological cases might not appear correct) I've seen other games that appear to do that pretty well (at least for simple cases)... any ideas what's going on in them?

I'm a bit skeptical of that since using Z-ordering to cull triangles sounds like it would take more work than it would save... especially since it's far more work to calculate an animated mesh's triangles than it is to render them. (in D3 I've seen areas with few lights and 100K triangles render at 30 fps because they were having to animate those triangles, and highly lit areas with 300K triangles run at 60 fps because all the meshes were static) But I guess I should go read some articles on culling using Z-sorting... The whole purpose of a depth buffer is so that you don't need to sort triangles. You can draw them in any order and the image will look the same.Edit: I think I may have misunderstood what you meant by that statement... If you're suggesting that the Z-fighting of distant objects would be because of limited precision of the depth buffer, I don't know anything about how many bits it usually has, so I can't say if I agree or disagree. By rendering the sides of the shadow to the stencil-buffer you can calculate shadows far more quickly than if you were to raytrace each pixel one at a time. With what I've described, yes... D3 somehow accounts for this, but I don't know how.

As far as I can imagine, Z-ordering from front to back would only be useful for minimizing fill-rate used by pixel-shaders... However, D3 starts by rendering opaque surfaces to the depth buffer and only uses the expensive pixel shaders once the depth-buffer is already filled, which I'm pretty sure is just as effective at minimizing fill-rate used by lighting, and doesn't require sorting all the triangles (which could be expensive). In short, I don't think Z-ordering would improve D3's performance, and it could degrade it. Translucent surfaces ARE tagged as such, and are rendered only after all opaque surfaces have been drawn. I don't know why there's no option to depth-sort them. Edit: Projected shadow textures work entirely differently from stencil shadows. The way D3 figures out how bright a light is at a given point works similarly to projected shadow textures. (they project the light texture onto the triangles like how you would normally project a shadow) The way stencil shadows work is more or less the same principle as the point-in-polygon crossing test, except 3D instead of 2D... (you're testing if a pixel is in a shadow polyhedron) Conceptually, you start at the opaque surface, and trace back towards the viewer, counting how many times you enter/exiting a shadow volume... If you exit more shadow volumes than you entered, the point was originally in shadow. (assuming the viewer isn't in shadow too) Fortunately, this can be done very fast on a graphics card using the following method: Start out the stencil buffer at 0. For each triangle of a shadow volume, draw the triangle (taking into account the depth buffer). If the triangle faces towards the viewer, add 1 to the stencil buffer, otherwise subtract 1. Once all shadow triangles are rendered, all positive pixels in the stencil buffer are in shadow and everything else is hit by the light. Again, this doesn't take into account whether the viewer is in shadow, and I haven't yet figured out how to deal with that. It ends up having the advantage of pixel-perfect shadows but the disadvantage that you can't do image processing on the shadow to blur it. (also, pixels are either entirely in shadow or entirely lit)

As far as I know, doom 3 does not depth-sort ANY triangles, including partially transparent ones. The closest thing it has is sorting by category (eg, fully opaque triangles are drawn first, then decals, then glass, etc), but lighting is all drawn before anything else. The reason I say it would either lead to graphical errors or horrific performance is primarily due to shadows.

Ok, the changes are committed... hopefully it'll work.

According to the header files, it looks like you can find out the volume of a sound shader with: shader->GetParms()->volume If it would save you some time, I can go ahead and change SetSoundVolume( GetMovementVolMod() ); StartSoundShader( declManager->FindSound( sound.c_str() ), SND_CHANNEL_BODY, 0, false, NULL ); to idSoundShader* sndshd = declManager->FindSound( sound.c_str() ); SetSoundVolume( sndshd->GetParms()->volume + GetMovementVolMod() ); StartSoundShader( sndshd, SND_CHANNEL_BODY, 0, false, NULL );

I just wanted to show off the latest set of textures I added, by posting a couple of screenshots of the fireplace/oven that I've been working on... (it's made entirely out of patches and brushes) In front, it's a fireplace: From behind the bar, things can be heated over the fire: A couple of notes: In a production-quality map, the 4th mortar on the pillars wouldn't have the harsh transition. (for prototyping reasons, the pillars are made in stacks of 4 instead of being fit to the area, so every 4th mortar isn't smooth-shaded) Also, the shadows casted are much lower poly than the fireplace. (the pillar shadows are zig-zags instead of rounded bulges)

No, that's not what I meant... I'm probably not doing a good job of conveying the idea. Let me put it another way: Normally a pixel has a color that has 3 components (red, green and blue)... However, when drawing such a pixel, you have no idea how opaque it should be. So somebody got the idea to also store the opacity of a pixel in a fourth color component called "alpha". Such pixels have 4 color components (red, green, blue and alpha). You use image editing programs to make the images. (or in the case of models, you may want to use D3 to render the normalmap) For regular textures you can just use an image editing program to create them all. I highly recommend GIMP, since it's powerful and free. I like to use the GIMP normalmap plugin to generate normalmaps for textures. For information on what diffuse/specular/normal maps are, I recommend looking at the D3 Mod Wiki texturing page. To omit a specularmap, simply omit the specularmap line in the material declaration. Any text-editor will work, though it's a good idea to use one suitable for programming such as notepad (click on the start menu, click "run..." and type "notepad") or Notepad++. I would avoid using Microsoft Word. Doom 3 can only render triangles. However, I'm under the impression that quads (four-sided polygons) are often useful for subdivision (high-poly) modelling.

Actually, we're already working with them.

If that's what you've been waiting to hear, you could have jumped on what I said a couple of pages earlier... Anyway, what it boils down to is that I play under the rules of the vanilla version of a game and currently those rules aren't balanced.

No argument here. Though in my (partial) defense, I've greatly enjoyed Hitman and Far Cry, which don't feature quicksaving. ...which is exactly my point. Unlimited quicksaves are cheating and should require a cheat cvar to be turned on. Actually, I always pretend I'm a thief who has psychic visions.

Ok, I'll try to be comprehensive then... (if there's any part that needs better explaning, feel free to ask) The Alpha Channel In most pictures, each pixel's color is composed of 3 numbers: red, green and blue. Another way to think of a color picture is as composed of 3 greyscale images. For example the following color picture is composed of: (red) (green) (blue) Each of these separate greyscale images is called a "channel". Notice how the bluish sections are bright on the blue channel, and the orangish sections are bright on the red and green channels. (since yellow/orange is a mixture of red and green) For transparency, another channel is added to the picture, called the "alpha" channel. A pixel with a high alpha value is more opaque, and a pixel with a low alpha value is more transparent. In truth, the alpha channel doesn't need to be used to store transparency information - it's just an invisible extra channel that can be used for whatever you want to use it for - but typically it's interpreted as opacity. Materials To make a regular material that interacts with lighting, you need to create 3 pictures... the diffuse-map, the specular-map (optional) and the normal-map. (actually all of them are optional, but almost all textures have a diffuse and normal map) Then, inside a file named materials/anything_you_want_to_name_the_file.mtr, you add a material declaration. An example material declaration would be: textures/mymaterial { // Uses "textures/mymaterial_local.tga" as the normal-map. bumpmap textures/mymaterial_local // Uses "textures/mymaterial.tga" as the diffuse-map. diffusemap textures/mymaterial // Uses "textures/mymaterial_s.tga" as the specular-map. specularmap textures/mymaterial_local_s } Note that "bumpmap textures/mymaterial_local" is a shortcut for: { blend bumpmap map textures/mymaterial_local } The same goes for the other keywords. Alpha-testing One of Doom 3's biggest weaknesses is its handling of translucent textures... Doom 3 does no depth-sorting of translucent triangles, and it's not possible to efficiently render shadows on them either. So allowing regular materials to have a full range of transparencies is out of the question and would lead to graphical errors or horrific performance. But it is possible for D3 to efficiently and correctly draw a triangle that consists only of fully opaque and fully translucent areas. This is the purpose of "alpha-testing"... You specify a threshold level of alpha above which a pixel is considered fully opaque, and anything under that level of alpha is considered fully transparent. (it's called alpha-testing, because the alpha channel is tested before deciding whether or not to draw a pixel) To construct an alpha-tested material, you first construct a diffusemap image with an alpha channel, then you create material in which the alphatest keyword is specified in the diffusemap stage. For example: textures/mymap/leafs { bumpmap textures/mymap/leafs_local { blend diffusemap map textures/mymap/leafs // parts of the image with an alpha of more than 0.5 are opaque alphatest 0.5 } specularmap textures/mymap/leafs_s } I think it may be possible to use the alphatest keyword in other stages as well, but I haven't done much experimenting with it, so I don't know for sure.

Had it been me, I would have just quicksaved, then opened the door and possibly reloaded. Not scary at all. That's what I use regular saves for - when I'm safe. I use quicksaves in the heat of the moment to get from safe spot to safe spot. And if I save myself into a corner, I just reload the regular save, which is at most a minute back. Autosaves usually don't overwrite your other saves but create a new one, so at worst it'll just provide a new, useless save. Often autosaves are useful for saving the player's progress before they walk into a trap, so if they don't notice the trap they aren't set back far back enough to be annoying. You could also do what Hitman 2 does, and make it so that when the player acheives key objectives or gets to key places, they earn a new save that they can use at any time, which negates the problem of involuntarily saving at a bad moment. No matter how scary the game experience is, I find it hard to be afraid when I have the safety-net of quicksaves.

That doesn't fly in the face of the "saving and reloading is too easy" argument, because D3 is VERY efficient when it comes to reloading... Although loading a level for the first time can take a while, reloading it is usually quite fast. In vanilla D3, the hell level (which I believe was one of the largest levels in D3) takes my computer 25 seconds to load the first time, but only 3 seconds to reload.

Unfortunately, I know very little about 3D modelling, so I can't help you there. But if you have any questions about how to create an alpha-tested material or how D3 renders things...

It looks like you're modelling the leaves with a low number of polygons rather than an alphatest map... Is there a reason why?

Thank goodness bookmark saves allowed me to quit at any time and pick up right where I left off!

Saving is a meta-theme mechanic (hence we you never hear guards talking about saving), but it is most certainly not a meta-game mechanic. Where and when you can save is an integral part to gameplay and has a direct effect on the experience. Would Nethack be near as interesting with non-bookmark saving? ("Gee, what does this amulet, do...? Let's find out by wearing it! *gasp* *choke* [RELOAD!]") Could you imagine anybody implementing quicksaving in Tetris? Some games like Pikmin are designed under the assumption that the player will reload numerous times in order to complete the game in time. Others, like The Longest Journey, take a more story based approach where the player cannot lose, so saving could not have negative consequences and does not need to be restricted. On the other hand saving/restoring would be unthinkable for an MMORPG - you could save, give your best item to a friend, then restore to obtain another copy - a serious abuse. Likewise, the Thief game-type is vulnerable to cheating via quick-saving. In particular, with quicksaving, risk analysis goes right out the window. If it were an issue of control, I wouldn't suggest adding a cvar to bypass it. I don't even care whether or not the mission stats window records if cheats were used. I just think there should be a way for level designers to potentially offer a restricted save system that people can use when playing their maps. From the perspective of a level designer, I want to be able to offer restricted saves primarily as a tool to heighten tension. Quicksaving is a psychological safety-net that puts a maximum cap on how scary an area can be... From the perspective of a player, I want restricted saves because I'm the world's biggest quicksave junkie, and I want scary levels! (...I didn't find the cradle the least bit scary)

@Orbweaver: I have a dentist appointment to go to right now, but when I get back I'll post some counter-arguments to the notion that saving is a meta-game feature.

So you're suggesting that a mechanism that allows you to control fate and win every poker hand in A Guard Named Benny (and play with matrix-like perfection in general) isn't cheating? Occasional autosaves take care of this. Bookmark saves take care of this. It's one thing to expect people not to hack the game, but if the vanilla version of the game allows a tactic without requiring cheats to be turned on, it's giving tacit approval for it as a valid way of playing the game. Abusing autosaves is not a valid way to play the game, but if the vanilla executable supports it, you cannot expect players to do otherwise. I think those two cases he points out fall outside of standard gameplay, and it's not unreasonable to expect somebody to temporarily turn on a cheat (which is very easy to do) to fulfill those desires.

@OrbWeaver: And if you also insert occasional auto-saves lest the power go out? Then you simply turn on the cheat_anysave cvar and save/restore to your heart's content. (this also works if you REALLY hate save restrictions) But for those who want to play through a map as it was intended, without cheating, they wouldn't be able to abuse quicksaving if the map wasn't designed for it.

As I keep on having to point out, this isn't true - any good restricted save system will implement bookmark saves (save-on-quit and delete-on-load) negating your argument.

Hopefully even better?