rebb

Hmm, interesting - it seems that having multiple map-stages in the light material causes Doom3 to draw the light for each of those stages. This seems to be the cause for your problem as well. It looks like the game ends up drawing the light once with your first map-stage ( ignoring the maskColor ), then draws again using the 2nd stage ( this time ignoring the maskAlpha ). So you end up having an ambient-light and a standard light drawn on top of it. The idea to reuse the alpha from another image is good, but apparently the game handles things differently for lights in some way. Try commenting out either of the stages and do "reloadDecls", to see how the game treats that. Btw an image for a full ambient without falloff would be "textures/lights/ambientlightnfo_amb". Edit : For some reason the multiple maps don't bump up what's displayed by "r_showlightCount" - maybe because the game doesn't count map stages in light-materials ?

Could you supply a test-map package where this x/y problem happens ? Ambient and Standard Light are using the same texture-lookups so this does sound strange. The "black alpha" requirement is explained in the test.vfp file, its a way to "detect" ambient-light that was used due to compatibility problems with earlier detection-algorithms. It's possible that this requirement will be dropped in the future if other detection algorithms turn out to be compatible enough, in that case already adjusted ambient-light textures will still work though.

It does look very nice and atmospheric. The only problem i would see atm is that he only seems to do lethal takedowns. One thing that annoys me quite a bit about games that are supposed to be about sublety ( ok, Deus Ex is more about options, not only sneaking etc ), is if they always make you kill everyone without an option to do something less-than-lethal. But maybe i just missed it in the trailer, or they didn't think it's cool enough to show. We'll see anyway

As i said, its not inverting the Z-Component, it's setting it to -1.0 ( because the Blue Channel will be 0, the interaction file decodes it to -1.0 ), which pretty much means that the normal is pointing "opposite" to the surface. As far as i know, the image-functions actually create texture-copies in memory, which are then used by the game - you can see this when using the listImages console-command. I did a local test and it actually looks like it inverts the normal-map, might post some images later. Edit: Why ? Do you mean that the whole normal needs to be of unit-length ? It's true that setting the Z-Component ( Blue Channel ) to fully -1.0 will likely denormalize the data some, which can give some visual error - altho the extent of the error will largely depend on the base normal-map itself.

Theoretically, it should be enough to simply do a "scale( normalMap, 1, 1, 0, 1 )" to get an inverted NormalMap. Because the XYZ components in a normal-map are -1.0 to 1.0 encoded in 0-255, a "0" in the blue channel would mean that the Z-Component is set to -1.0 . Of course this is pretty hacky because it doesn't directly invert the true Z component of the base NormalMap, so there could be some visual error.

I love the Hitman Games, played all of them, even replayed 1 and 2 recently. The franchise for me feels very true to the idea behind the Thief Games, as in you're not actually meant to go into every mission guns ( or bows ) blazing, and it's much more interesting to finish missions with the least amount of "collateral damage" done. Regarding Blood-Money, gotta love the "Last Level"

Did you try Orbweaver's suggestion using the scale() function ? According to iddevnet, it does scale the RGBA Values of an image. There is also another keyword called "scale" which does UV Scaling, but it is not the same as the scale() image function.

Cool stuff, is the amount of tranclucency controllable in some way ? Possibly using the RGB Keyword on the "backfacing" diffusemap ?

Thanks It seems like simply making sure that the bumpmap-stage comes before the diffusemap-stage fixes this. Try this material : textures/darkmod/stone/brick/bricks_dirty_yellow_vertblend { stone qer_editorimage textures/darkmod/stone/brick/bricks_dirty_yellow_ed { blend bumpmap map textures/darkmod/stone/brick/bricks_dirty_yellow_local vertexColor } { blend diffusemap map textures/darkmod/stone/brick/bricks_dirty_yellow vertexColor } { blend bumpmap map textures/darkmod/nature/dirt/dry_earth_stones02_local inverseVertexColor } { blend diffusemap map textures/darkmod/nature/dirt/dry_earth_stones02 inverseVertexColor } } I vaguely remember reading something about the "proper" order of stages on iddevnet.com at some point, most id materials seem to adhere to the order of "bumpstage, diffusestage, specstage".

@Sneaksie : Could you attach the files again please ? ( map, model, material )

White should fully show the "vertexColour" part and black should fully show the "inverseVertexColour" part, yes. With in-between grey values mixing the two depending on the value.

If the vertex-colour of a vertex is not fully white or not fully black, but some in-between grey value, then essentially both textures will show on this vertex. You can display vertex-colours ingame using "r_showVertexColor 1". Having a fully white or fully black value on a vertex makes sure that the respective material will fully "own" the area around this vertex, so to say.

Hm, when doing a "r_showNormals 10" it seems like the vertex-normals of the model are all over the place, which can cause this very strange shading. A quick and ugly fix is going into the .ase file and deleting the whole "MESH_NORMALS" chunk, then doing a "reloadModels" ingame. It seems as if something went wrong on exporting the .ASE file. Is it possible that the mesh is also accidentally cloned multiple times ? Because deleting the MESH_NORMALS chunk still shows multiple normals for some reason. Edit : Or maybe its not cloned multiple times, it seems the engine just draws the normal for every adjacent face of a vertex, unless it's an MD5 Model. Can anyone confirm this ? Edit2 : Actually it seems that deleting the MESH_NORMALS chunk causes the engine to treat all triangles of the mesh as "hard edged" instead of calculating a smoothed vertex-normal transition, thats probably why it shows multiple normals per vertex. I only know that MD5Mesh models get automatically smoothed vertex-normals, because the format doesn't support explicit vertex-normals. Apparently thats not the case for .ASE.

Most strange. Is this map and model on SVN ? If not, could you put it there into the testmaps directory or similar ?

Does the problem happen with all types of .vfp interaction files ( default Doom3, current, HDR ) ? Your material looks like it should work, actually. Maybe the HDR color-encoding is done in the wrong place, it seems to convert the color-range after applying vertex-color, while it should do color-range adjustment first and then apply vertex-color. But i could be wrong on this.

It could work if an .ASE exporter would use the information in some way. ASE supports Vertex-Colours. Altho it would mean having to reimport the geometry in .ASE form and deleting the BSP one. But anyway, it was fairly clunky ( although useful ) back then, it's even more clunky now . Doing vertex coloring in a 3D Package is really the standard nowadays, and has been for a long while. Altho i somewhat agree that Blender can be intimidating ( i couldn't get my head around it's interface at least, so i stayed with other packages ), it's probably the best option for most people. Unless someone wants to code an extra tool that loads up .obj/.ase files exported from the editor and lets people paint vertex colors in it, then export to .ASE. But thats again not a small undertaking.

I remember the Q3Map2 Tool for Quake3 had the option to apply vertex-colour to things, or at least something similar. It was based on placing small brushes that encompass the "vertices" of other brushes, which would then apply vertex blending information. Here's a mapping tutorial using it : http://www.simonoc.com/pages/articles/terrain2_1.htm . Maybe an export script might be able to extract blending information the same way. It's a very clunky way to work with vertex color though, just applying it to a mesh in a 3D Package is probably the least hassle option for everyone involved.

That probably is all triangles, altho not sure if he also uses parallax in some materials. The textures are generally very high res in those pictures. UE3 is built to support lots and lots of Static Meshes instead of BSP Geometry and the characters are using quite some more polygons than what the original Doom3 characters had, that helps the overall silhouettes a lot. The link you posted is a portfolio project so he might be putting a lot more polygons in and doesn't have to think much about the range of systems a game would have to be able to run on with these assets. DirectX11 Tesselation will probably do all the other silhouette magic you were hoping for with "real" displacement.

From what i've seen in the UDK and read, the "Virtual Displacement Mapping" in the UE3 Engine is just standard Parallax Mapping, not even POM - and few materials actually use it.

When in doubt about material keywords, consult http://www.iddevnet.com/doom3/materials.php . Those keywords you mentioned are all stage-specific, so they can't go in the "root" of a material, only inside a stage.

Does TDM really use that many Doom3 assets ? Apart from light-textures ( which are fairly easy to make ) and some fonts i didn't notice many. Are there more obvious ones ?

Neat, going to give it a try. If you are interested in time-bendy games you should have a look at "Braid" and "The Misadventures of PB Winterbottom", but those 2 aren't free. Prometheus is free tho, as far as i remember. You can get it here somewhere : http://www.moddb.com/mods/prometheus/news/prometheus-available-now-as-free-downloadable-game .

If they indeed tried to simulate ambient occlusion, then they invented horrible-occlusion in the process - just look at what character models look like in standard Doom3 ambient lights, it's nowhere near what AO should be ( sometimes referred to as the "coalmine look" ). It's much more likely that id played around with ambient light implementations, but ended up not using any in the final game, so they left their implementation as crude and simple as possible ( also to keep performance up on the hardware of the time ). Which mod authors are you talking about who are "trying to put it back in" btw ? You make it sound like i magically put this fix into every shader in existence. The core of the fix doesn't even have anything to do with how the ambient light looks, it's just "detecting" if there is ambient-light shading to be done instead of standard-light shading. Controlling the actual "look" of the ambient lighting is then up to whatever instructions you want to use inside the vfp. From what i can see, this page is pretty much describing what is now commonly called "normal-mapping". The page being from 2003 is probably a reason for the different naming of this, since the whole concept was just gaining momentum back then, largely driven by Doom3 itself ( which came out in 2004 ). The pixel-shader of this page contains a phong shader algorithm based on a normal-map, and the vertex-shader does nothing related to silhouettes, it just passes the light-vector and camera-vector and transforms the vertex position using the ModelViewProjection Matrix.

Hm, iddevnet says this : I think the engine can only ever treat one "side" of a polygon as shadow-casting, which is why most meshes should be fully closed and not have any holes in them. You could duplicate the patch, flip it's matrix and apply a "textures/common/shadow2" material on it, that way it would be invisible and give you proper shadows from lights behind the curtain. Edit : Argh, Orb was faster

Good idea, reminds me a bit of Q3ASE from Quake3 Times, it's actually kinda strange that something similar doesn't exist for Doom3 yet.