J.C.Denton
-
Posts
197 -
Joined
-
Last visited
-
Days Won
1
Posts posted by J.C.Denton
-
-
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.
-
Dumb question I guess but what happens if you use nodraw for one of those textures?
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.
-
Ok. What a shame. Stuff like this would be useful in many places. We've already setup a few materials with the aplhatest keyword, because alphablending does not work properly...
I was just thinking, maybe we could do something about it. And doing vertex blending for every small ash-heap we put in a fireplace is just tedious.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.
-
Yeah, but the problem with the translucent keyword is that it makes everything transparent. Have a look at this screenshot, which is based on the alpha-map on the right.
We have a general purpose diffuse map and would like to add alpha blending via a separate texture to it, while maintaining proper reaction to light. From left to right: Diffusemap, alphamap, desired result
Even if we can't get it to work with a separate alphamap, it'd still be good if we at least could do it in a single texture with an alpha channel.
The material in question is "textures/darkmod/decals/dirt/ash01_crumb_edge" , which is defined in tdm_decals_dirt.mtr, in case you want to have a look at it. From what I have heard, Fidcal and the team spent quite some time to get this working without success. I had a look at it too recently and came to the conclusion that the engine is simply missing this feature.
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.
-
Isn't that basically an additive blend effect? It just lightens whatever is behind it, and is still visible with no light at all?
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.
Yeah, I think so too. I looked a bit into it yesterday, because I noticed a texture where the alpha gradient have been dithered and the alpha blending was only of binary sort, opaque or invisible. I wondered why one would do that and I found that (according to modwiki) with simple diffuse maps you can only add alpha using the alphatest keyword. Everything else uses some blend combo other than blend diffusemap to achieve the alpha blending.
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 ) } -
JC, there's also another issue we might want to tackle regarding textures. Do you think you could implement proper alpha blending for diffusemaps? I don't know how openly we can access the code in this area, but currently we can only use alpha blending with full bright shader stages, e.g. blend blend. It'd be much cooler if we could use alpha blending on textures that actually react to the present lights.
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.
-
Anyone know what the following means (it has been preventing me from testing my maps despite me deleting almost everything within the map):
ERROR: IdRenderSystemLocal ::UnCrop: current RenderCrop <1
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.
-
Hi JC
I like looking at the screen shot of my map -
Yep, the HDR really comes out in that shot. Really nice stuff
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.
What we truly need is coding bult in to the compiler/renderer that pre bakes AO using the ambient world light.
You don't need a light to compute AO.
-
The procedure is basically
1. Export map geometry to OBJ
2. Import the OBJ into a 3D app, merge into a single object, position lights and render to texture in the 3D app.
3. Export the rendered mesh with its baked material, and import it back into your map.
It would work, but wouldn't do the performance any good, since whole sections of your level would have duplicate geometry.
I did think of a similar idea of pre-baking lighting into the vertex colours for terrain meshes, which I haven't yet tried but might be successful at making outdoor areas look better. I wouldn't do it for buildings or indoor scenes however.
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:
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.
-
Apply it as grime decals, however, would be near impossible and limiting - not to mention incredibly time consuming. I don't think you would be able to apply it to any complex geometry (flat surfaces only).
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.
-
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.
Are these really AO, or are these just the "grime decals" we put on walls. We have such decals that are basically a "rounder" brighter spot in the center, if you apply them to an entire wall, the corners of the wall get darker, and that looks way better than if you just have a flatly lit wall.
However, applying these decals is very tedious and uses a lot of mapper time, not to mention it uses extra rendering for the decals. And it is hard to make them fit around door holes etc.
When done right, they greatly enhance the scene, tho. If (somehow) AO can do this without manually placing decals, I am all for it
Here is an example picture where Fidcal (the "inventor" of the grime corner decal
applied it on a room:http://modetwo.net/d...ner-edge-decals
And here is the original thread with example pictures:
http://modetwo.net/d...ner-grime-decal
Edit: Ha, I was right, the training map has hand-painted geometry AO:
http://modetwo.net/d...&attach_id=3464
Nice ob, Fidcal!
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.
-
-Very many models share generic (non dedicated) diffuse textures, so baking AO into the diffusemap is no option in these cases.
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.
-Hence AO would have to be stored separately, e.g. in the alpha channel of the specularmap.
-Many models/textures don't have specularmaps, so we'd have to add new ones. This would bloat up the downloadsize pretty much.
-Most textures in Dark Mod are phototextures, so the normalmaps have been generated automatically and enhanced in a 2d editing environment.
Heightmaps aren't avaiable for that reason.
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.
The only place I can think of where we could apply AO without any problems are the AI textures, as those are dedicated ones. Maybe they even already have AO baked in. I don't know...
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 Per Vertex Ambient Occlusion Technique is an interesting thought, but it would probably only look good if the brush has enough subdivisions. Imagine a 50m long wall consisting of just one brush and one edge of the wall is lighted strongly. It'd result in a greyscale gradient over the whole wall (if I understand your proposal correctly). I for one am still hoping for someone to implement lightmap support, once Doom 3 has finally gone open source.
Scene-AO is generally a critical topic though, since we'd need to alter the lightgem-calculations, as far as I know or use it only very subtly. It also must not be calculated for extinguishable lightsources.
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.
- This can be generated from the height maps. These height maps can be generated from source images used to generate the normal maps.
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.
- With AO generator this process can be automated. Making an AO generator would require a lot of R&D and work on my part.
- 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.
[*]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.
- Hand painted AO is already being used this way, e.g. grime decals.
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.
- Ambient Occlusion coming from the real Geometry.
-
Hm, yeah, all what the ambient light switcher does is:
* the mapper only places on ambient light named "ambient_world" that covers the entire map
* the script checks 3 times a second the location the player is in, and takes from that a "minimum default ambient light" (can be colored for effects), it then adds all the current lights in the current location (scaled down quite a lot) as "dynamic ambient light", then over the next 1/3 (or so) second fades the "ambient_world" light to the new value.
So basically the ambient light is always adjusting to what location you are in (blue moonlit outside, red lava cave etc) and also reacts to torches going off etc.
I guess it will compete a bit with your automatic eye exposure etc, but if you effect is as subtle as the dynamic ambient light, they should go well together.
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.
-
Looking good so far, I am still curious to see this integrated into our "ambient light switcher" that provides different base ambient light depending on the zone you are in. Would be interesting to see if the HDR copes with the light fading or if we can skip it entirely and just use a single default very low grey for it. (I am unclear on wether the HDR computes an "overall" lighting color from all lights in the current zone, or just the overall color from the lights hitting each surface. If it is the latter, the ambient fade would greatly enhance it I believe.
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.
Looks very nice. Please don't hold back on the amount of console-cvars. I always like a high customizabilty, including a toggle-switch so that you can actually see the difference.
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.
Wow, wow, wow. It eliminates the "deadness" from the original D3 engine. The shadows almost look soft!
Those are some impressive shots, and I agree with Goldchocobo that it increases the "liveliness" of the engine. Well done, and keep going.
Thank you very much for appreciation.
-
Hehe ok. It's no big deal, I was just a little confused because I saw no thread about this in the private forums.
And screenshots are always welcome, but I'd rather check out the SVN and see it myself...
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.
-
So is this still going anywhere? Didn't see any posts... What is planed right now?
I am really looking forward to this feature!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.
-
Welcome, J.C., it is an honour to have you on board.
Thanks!
@J.C
Just out of curiosity, what system/hardware did you use when making those screenshots ?
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.
Your work is very interesting - I dont think anyone here would turn away your help!
Just about the AO, what I was getting at with the comment of 'theres pretty much no AO' was that it would be a huge effort to render and check the textures, there are quuuuite a few of them!
As well as should rage come out in Oct/Nov, we might have access to the render and while it would take quite a while to convert the mod into a full release - which I think is the direction things seem to be heading, wouldnt it make senses to just take a newer approach? I'm all for AO, dont get me wrong but I think simplifying the number of files and such would be of benefit to both players and content developers Valves SSBumps are quite interesting, I was very interested to see them in Episode 2, most of the benefits of paralax etc without the massive performance hit on lower end hardware. If you havent played around with them you might be interested by this abstract
I will still try produce a map with AO sometime in the next week, moving back to uni at the end of the week, so will let you know how that goes.
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.
Yes, we certainly won't turn away any help but please don't be offended if the team chooses not to implement your full mod in TDM.
There are areas, both in the main mod and in Dark Radiant, where we could certainly use your expertise.
Just to be clear JC, I didn't mean to come across as speaking in any 'official' capacity on behalf of the team. I was merely speaking in generalities.
As I said, I do like the look of this and am personally interested in seeing if we could use some of it.
Thanks for the clarification. Appreciate it.
1 & 2: I really like the way your HDR brings out the edges of things. In the default shot of #1 the wagon is nearly invisible. The way the light picks up edges really makes things more 3d, and that's an effect I think is quite desirable.
3: The peaked roof seems really overbright in spots, especially the bright blue seams. Also, the entire building seems REALLY brightly lit, compared to the original shot, where it is almost in darkness.
4: The leather on the arm seems too highlighted, IMO, as if it's been given a strong specular. That and the arrow both seem to have the "plasticky" look that D3 is infamous for.
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).
I do believe we're all interested in seeing this in action. So lets get the ball rolling. I guess we'll need to get some SVN access rolling for this?
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.
Oh man, if you can improve water and underwater murk you will be my hero - not forgetting making the surface murk match the underwater.
And any ideas you might have for fog volume boundaries would be welcome. Also, rain without the performance lag we get with excessive particles.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).
Light baking
in TDM Editors Guild
Posted
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).