J.C.Denton

This looks amazing! It does work with HDR but doesn't work with the new ambient nor with the texture brightness method. I haven't gone through all the posts made here. So I don't have any grasp over this. I'd appreciate if someone points me to few informative posts or even wiki that explains how this works. Doom 3 amazes me all the time with the stuff like this. Judging from the old materials similar to the one used in the map above, there seems to be some tests id made back when they were working on D3. It'd be cool if it can be combined with some image space lighting, so that the static geometry and characters can have environment's reflection, similar to the new ambient lighting (see this image for example).

Good point. But the part where the ash heap starts fading, it will start fading to darker shade until it reaches black and not the transparent background. Edit: But that also means we can try mapping _currentRender with the inverseVertexColor part. This approach, if worked, might cause particles to not draw over blended part since stages referring to _currentRender are always drawn in the end and thus any particles or other alpha blended stuff which is overlapping this portion will be overwritten by the vertexblend.

nodraw as the name suggests won't draw anything. It's used to toggle the display of some things like, flashlight-beam particle on off.

The renderer code is not at all exposed in SDK. Making lit alpha blended surfaces would require a complete re-arrange of current rendering order. There needs to be a lot of feasibility study done (might take a man-month or two) to evaluate whether we can have our custom render path with what's exposed. I think that there's a fair chance of this being possible. We can do a lot of things faster and good looking in addition to feature you wanted.

Tried a lot of different combination and even wrote a shader to do the blending, but to no avail. Doom 3 does provide a rather crude lit alpha blended surfaces, wherein the opacity of the surface is determined by the lighting itself. I mean, full bright is fully opaque, completely dark is totally transparent. However, the problem that you are facing does necessarily requires alpha blending on lit surfaces. You can use vertex blending to achieve the kind of surface blending you want. Make the floor and the elevated geometry the same mesh in any third party software (3dsMax for instance). paint the vertices of floor as black and the elevated surfaces as white. Export your geometry and the vertex color will be used by doom 3. Then write a material for this surface based on following format : shaderDemos/vertexBlend { { blend bumpmap map addnormals( textures/base_wall/bluetex3e_local.tga, heightmap( textures/base_wall/bluetex3ebmp.tga, 6 ) ) } { blend diffusemap map textures/base_wall/dlongwall_d.tga vertexColor } { blend diffusemap map textures/base_wall/redtex1dif.tga inverseVertexColor } } OR haderDemos/blendBumpMap { // blended part { blend bumpmap map heightmap (textures/rock/skysand1_bmp.tga, 4) // note that you do NOT put vertexColor on the bumpmap } { blend diffusemap map textures/rock/skysand1_d.tga vertexColor } { blend specularmap map textures/rock/skysand1_s.tga vertexColor } // inverse blended part { blend bumpmap map models/seneca/textures/factoutwall1_local.tga } { blend diffusemap map models/seneca/textures/factoutwall1_d.tga inverseVertexColor } } You'll get a surface that blends textures between the border where vertices are black on one side and white on the other. Sorry, I couldn't do it myself. I am not good at modeling at all.

Oh, now I've got a clear idea of what you wanted to do. The blend modulate works if you want a decal to blend with destination surface and to match with it's lighting. I'll like to try to get the desired result if you could provide me with your test map, materials, textures etc, before writing the engine off on this.

Sorry mate, I dont have the SVN assets at home. I have a limited download connection here. The assets are on my office laptop, which I left back in office. So I 'll help you but I can't actually look at the material. The decal texture should have a color painted on the borders as you wanted it, and should have white color where you want it to be fully transparent. Don't put any alpha channel in the texture. Now, in your material, you'll have to use blend modulate. This way the colored decal would be multiplied with the destination color (which should be your dynamically lit suface, such as floor for instance). The white colored part will multiply with destination and won't change it's color, since anything multiplied with one is itself. the colored part of your decal will modulate the destination surface. You may have to tweak the colored part to get a desired result.

No, the light does interact with it. Stand in front of a web and set r_lightscale to 0 and you wont see it. You can see things like light-bulb textures, lava etc when r_lightscale is 0 but not the web. It's only visible when lit. Additionally, You can find the spider web material being used in business as usual map, in the basement of your apartment. No. Alpha testing has to be used if you want to cast and receive shadows from the material, e.g. hellmaggot particle effect in the first hell level. It uses alpha which is treated as binary, on or off, and it cast and receives shadows. Alpha testing is necessary to generate depth information of solid geomety, which is used for shadows among other things. I quick checked the web texture and even to my surprise it doesn't have an alpha map. The translucency is achieved by the color gradient itself. Have a look at the material of this web, as you can see there's absolutely no alpha testing enabled on this material. models/mapobjects/webs/corner { qer_editorimage models/mapobjects/webs/corner.tga noSelfShadow noshadows nonsolid twosided translucent diffusemap models/mapobjects/webs/corner.tga //specularmap models/mapobjects/webs/corner.tga //bumpmap heightmap(models/mapobjects/webs/corner.tga , 1 ) }

It's already supported by the engine. Look for the material of Hellkinight's gobber, or even better, the spider webs. Ever pointed flashlight at them? they react to light.

This is usually due to wrong use of renderSystem->CropRenderSize function in the code itself. If in your code, you are using a renderSystem->CropRenderSize then there must be one renderSystem->uncrop called for every CropRenderSize used. It's like nesting brackets, e.g. for every opening bracket you need a closing bracket. Have you compiled code on your own? If so, make sure the code is in complete sync with SVN.

Thanks guys. When I first implemented the HDR, I also spent quite a while in that room just looking at the fireplace and stuff. btw, Bikerdude did get to try it the lighting out yet?

AO maps can be really small in size. They'll look blurry due to bi-linear filtering but that goes well with AO. So texture size won't be much of problem. UV unwrap could definitely be an issue. To work around the problem of having to make entire level one object, level can be broken into different objects, but again that's cumbersome task. As it seems, there has to be a built in AO generator in the editor itself. You don't need a light to compute AO.

Aah, I was thinking along the same line. Why not bake ambient occlusion this way? Visuals would definitely drastically improve. I had also started a thread that talked about baking AO in textures: http://forums.thedarkmod.com/topic/10720-texture-creation-suggestion-the-generation-leap/page__view__getnewpost__fromsearch__1 Right now AO like effect on map geometry is achieved by painting grime decals which is very cumbersome and time consuming. We can follow above approach to obtain AO for map geometry.

Very true. I haven't said that's easy, I have said that's what can be done without any code changes. However, process of extracting AO from textures and baking AO to textures can be batched with a script or macro. Also, computing AO for characters and static objects shouldn't be a problem. In fact, that'd give the game an instant visual improvement.

Thanks STiFU! I have updated the first post as you suggested. I tried putting the nested list but it didn't work for me. I tried it with the icon button in the post editor and not with actual hand written tags. Oh well.

I think what I said here is kind of scattered in pieces and it's about time that I should make short points so that there's no confusion. PS:- I am having a hard time trying to get multiple-hierarchy bullet points to work. So attaching my post as an HTML document. Please suggest better way of doing this, if there's one. Ambient Occlusion For Darkmod.htm

Thanks to Crispy and Tels for explaining what's AO to Stifu! That should save some of my time. If it wasn't for time, I'd love to go in detail on this. Nice job indeed Fidcal. Thanks for the update. I was wondering how this AO was generated. It turned out that it's a hand painted AO, based on observation and not math.

Instanced models such as boxes and haystacks, barrels etc, can have AO baked in diffuse, for surfaces with tiled textures we can use alpha blended decals to put AO on. There are two types of AO shading that'd improve the look, one is from heightmap, which again can be obtained from phototextures, just like normal map and second, from the geometry itself. E.g. The roundedness of a barrel or a wall meeting floor would make for a nice radiosity shading with AO. If we are to store AO into a separate channel, then we can store it in Blue channel of normalmap. E.g. we can apply decals (as mentioned above) for geometric, per vertex AO and have normal maps store AO that came only from surface perturbation owing to the fact that normal map is tiled on many surfaces. Now storing AO in Blue channel would require Z of a normal to be calculated from X & Y in the shader, which I can do quickly. However, since we are talking about AO from surface perturbation only (and not from the geometry itself) it can be simply baked in diffuse. Just like AI, you can find many objects in the world that has dedicated textures, e.g. boxes, the cart, hay stacks etc, that can have AO baked in. I can identify baked AO when I see objects getting lit. Characters definitely do not have AO baked in. Otherwise you'd see nice soft shading on eye sockets, under the nose, under the arms and on overall body giving it a nice rounded look. Example: the Image on right, is from NVIDIA human head demo for skin rendering that uses entire memory on a Geforce 8800 and does many rendering passes to draw skin, but doesn't have AO. The image on left is offline rendered, probably uses less resources and similar skin rendering method, but has an ambient occlusion pass, which adds soft shading. If we have high polygon models of characters then the AO maps generated from them would yield soft shadows from there skin pores and from chainmail armor etc. We can achieve the same effect if we combine heightmaps based AO with per vertex AO. Some of the wood textures on doors and on tables used in training mission, have AO(that comes from surface perturbation) baked in diffuse. Also, in the same level per vertex AO is applied on map geometry as decals, it seems. Example of per vertex AO in training mission: That's true. That wall would have to have four extra vertices to account for AO attenuation. But extra vertices is a trade we'd have to make to save us from the requirement of a texture to store AO in. The best thing about AO is, the amount of AO in the world is always constant, regardless of light placements, number of lights etc. So it makes sense to precompute it. So lightsources, extinguished or not, there's no need to worry. Also, there's no need to worry about lightgem calculations.

Old post (22 Feb'10): I don't know what process we follow to create textures, such as normal maps, but I did find some heightmap textures in the assets folder. Now, as we all know the surface perturbation is very well simulated by normal maps, but if we start extracting the Ambient Occlusion maps from the high polygon models or from heightmaps, then we can either have the interaction shader modified to add the Ambeint occlusion shadow based on light's direction or we can simply bake it on top of diffuse map so that entire lighting result gets modulated by AO with no extra shading cost. Now, for stuff like instanced geometry (such as boxes, hey stacks and a lot of such stuff), AO can be calculated 1. either from high polygon models that we generate normal maps from that use with their in game counterparts, or 2. from hightmaps using third party tools and then combining this heightmap based AO with AO generated from the geometry of low polygonal (in game) model. You can compute per vertex AO and AO from normal maps and from heightmaps using many third party softwares. For characters, I'd suggest to generate AO from the high poly counterparts and that would add the game a definitive visual improvement even if we choose to combine AO with diffusemap. Now, as per the map geometry (non-instanced) is concerned, we can generate AO from heightmaps that would account for accurate soft shading from surface perturbation and then to account for AO from actual geometry, we can either use AO maps the way they were used in training mission (but strictly for everything this time), or I can attempt to build a per vertex Ambient Occlusion generator that integrates into Dark Radiant and stores the AO result in alpha channel of vertex colors. This alpha channel can easily be accessed from within interaction shader and can be combined with heightmap based AO. We'll have to finalize free tools that would let us do all this and then a way of batching some these processes (e.g. generation of heightmap based AO), so old assets can be processed in one go. If we have all this done, then visuals will be at least at par with current gen games. Even if we are planning on shifting to id tech 5 engine, this asset creation method would have us prepared, since rage, like many other games, uses diffuse maps with baked AO. A note on an integrated Per Vertex Ambient Occlusion Generation tool: It's going to be fairly time consuming on my part to attempt to create such a tool. I haven't started looking into how the map data is stored, but I know it's stored in text format, so it should be theoretically interpretable. I also can use some help from the dark radiant veterans here to get a nice head start, in case we decide for it. -------------------------------------------------------------------------- Update 27 Feb'10. -------------------------------------------------------------------------- I think what I said in this thread so far, is kind of scattered in pieces and it's about time that I should make short points so that there's no confusion. Many thanks to STiFU for his time and for helping me get over the multi-hierarchy bulletpoint problem I got while posting this. Ambient Occlusion shading for Static and Dynamic(animated) geometry What's AO? The illumination at each point is a function of other geometry in the scene (Courtesy - AO on Wikipedia). So please don't confuse dynamic lighting with this. Types of Ambient Occlusion we can have in Dark Mod: Ambient Occlusion coming from the real Geometry. Texture space Ambient Occlusion Coming from a simulated Geometry, i.e. normal maps. E.g. Soft shadows between the cracks of a wall. Ways of obtaining Ambient Occlusion Generating Texture space AO: This can be generated from the height maps. These height maps can be generated from source images used to generate the normal maps. [*]Generating AO From Actual Geometry: Either, hand painted maps. Or, with the help of an Ambient Occlusion Generator integrated in Dark Radiant. For characters, AO maps should be obtained from the high polygonal models of the characters to get AO from pores of skin, cloth grains, chainmail armour etc. How to apply the Ambient Occlusion to scene (Alternate approaches): Based on direction and distance of each light. A pixel facing away from light should retain maximum AO a pixel facing directly the light should have AO wiped out. E.g. a torch held close to a dark corner (due to AO) should wipe out 80-90 of AO shadow whereas areas away from torch should retain 100% AO. Requirement: In order to achieve above, we need to store texture-space AO and geometric AO to a memory that can be made available to interaction shader at runtime. Texture space AO can be stored to blue channel of a normal map. This way, to store texture space AO, no extra texture memory required at the cost only a couple of extra shader instruction. Geometry based AO can be stored to the alpha channel of vertex-colours of the geometry with no texture memory cost. Also, vertex-colours are already accessible in the interaction shader. With AO generator this process can be automated. Making an AO generator would require a lot of R&D and work on my part. Manual method, e.g. hand painted AO is difficult in this case. I don't know how hard (if at all possible) it is to paint vertices in dark radiant. [*]Constant AO regardless of light's direction and distance. This should look like the grime decals, except for the fact that, we'd have texture space AO as well this time. This approach would require no change to interaction shader whatsoever. Texture space AO has to be baked into diffuse map. Geometry based AO can be stored to separate textures that can be applied as decals. Hand painted AO is already being used this way, e.g. grime decals. In an automated approach, AO generator can generate AO maps from geometry and can store them to disk. It should also automatically prepare/change materials accordingly. Requires feasibility study of this on my part. The least we can do to improve the look of the Game with the help of AO: Regardless of whether an automated approach for generating ambient occlusion is feasible, we can at least do following things to improve the look of the game, without having to change a single line of code and/or shader: Bake Texture-Space AO into diffuse-maps. Obtain AO from, preferably, high polygonal models of characters and bake it into their diffuse-maps. Grime decals as we are already using. Bake AO into static objects' diffuse-maps such as crates, hay-stacks, cart etc. AO would look a lot better if we have high poly counterparts of these to generate the AO maps from.

Well, if that's how your dynamic ambient light works then I see no reason for it to compete with automatic eye exposure, subtle or not. It should work just fine.

If the ambient light switcher worked with Rebb's interaction then it should work with this implementation, since I am using the same way to detect whether the light being passed to the interaction is an ambient light or not. I have uploaded the changes on SVN repository and started a new thread here: http://modetwo.net/d...w-hdr-lighting/ You can find there, a list of new CVARs and short description accompanying each. Thank you very much for appreciation.

Sure thing, but let me warn you: The current implementation is not optimized and it might cause a slow down. I have plans to optimize it to an extent where I don't have loose precision and further if, need be, to approximate few things, sacrificing precisions. I'll open thread as well I am done with the SVN update. Here goes some screens: Some might complain about the overall darkness. But it can be changed from console and also I can increase the default middlegray value (for which there's a console variable) a little for slightly brighter results.

Apologies. Been busy as hell with office work. I have integrated the HDR + lighting quite a while ago with the source code I got from the download section and not from SVN repository. I have been playing Dark mod a lot these days and I tweaked the lighting quite a bit to, what I thought, would be more suitable for Dark Mod. I am in the process of updating the source code I got from SVN repository and you'll get to try out the lighting very soon. I'll start a new thread about this once I put everything on SVN probably today or tomorrow. I had run out of space on my home PC and I just bought a new HDD yesterday that I am going to put all the SVN downloaded content of Darkmod on. I'll post a couple of screens here if it's OK.

Thanks! Windows vista ultimate 32 bit, SP 2 AMD Phenom II X4 940 processor 3.0 Ghz. 4 GB RAM, DDR2 800 MHz. NVIDIA Geforce GTX 275, 896 MB. It's quite a decent system. However, do not go by the FPS shown in the images. First because, the framerate goes up and down while taking screenshots and second, as I said earlier, there is still room for optimization.

Apologies for late reply. Was really busy at workplace. I sometimes dont get time on weedays. Thanks for the link. I had checked that out at least a year and half ago. Those guys are generating normal map in their own way. I was making a second run through episode two the last weekend and those underground caves really look awesome. I understand that generating AO is quite a huge task, given the number of different textures being used. I'll talk about what I have in mind for AO soon, probably in another & more specific topic discussion. Thanks for the clarification. Appreciate it. Almost every aspect of lighting is tweakable. The strong specular on the leather, although can be hand tuned from shader to be more subtle, is something you'll notice on a lot of real world materials. See this screenshot for example. The bright specular on the left side of the temple (and the left edge of the nose) is not because the specular map has an intense value in that area, but because of the way specular lighting works due to subsurface scattering and the phenomenon is known as the Fresnel effect. The leather has it and the effect only shows up when viewed at grazing angles and when the light is at grazing angles. See these screenshots to see what I mean. The arrow looks a bit too shiny. This can be either fixed by tweaking the shader or adding more grainy pattern to specular map. Or by doing bit of both. I can tweak shader as much as possible to avoid recreation/modification of existing asset base. However, It'd really great if we could store specular exponent or what is know as "glossiness" to one of the specular map's channel. Rest assured of the fact that the HDR can be be tweaked to get past any issues. I don't think of HDR as a fancy feature. In fact, it's part of the lighting model, as in, the way lighting model's designed, the shading requires broader color range to work on. In addition to automatic eye adjustment, I am also going to write an alternative, cheap bloom for HDR (w/o auto exposure). TDM as I see it, is one of the greatest mods I have ever seen coming to life. So I consider it an honor to contribute to it. Off the topic, just voted for TDM on ModDB. An accurate underwater depth based murk while matching the the surface murk to the underwater one, is very much achievable. I'll have to write depth of the scene to a separate texture, that can be used for various purposes such as underwater murk, shore blending/soft water edges and also for effects like DOF. On the other hand, you can do a fairly accurate underwater murk yourself by placing a foglight under water, matching it's volume with water's. The foglight is nothing but a simple fog volume that internally uses Doom 3's own scene-depth (the one you can see by setting r_showdepth 1) that you dont get access for. Ideally, if we could access that scene-depth then depth based effects can be done at very low performance cost. To find out which texture hold this depth, we can either mail id Software or can find it out on our own using third party tools such as gDebugger (Its license's very expensive though).