Jump to content
The Dark Mod Forums

Texture Creation Suggestion: The Generation Leap


J.C.Denton

Recommended Posts

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:

 

  1. Ambient Occlusion coming from the real Geometry.
  2. 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):

 

  1. 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.

Link to comment
Share on other sites

Hehe we seem to have the right man on board!! :) I am always pro AO, however there are a couple of issues we are facing here:

-Very many models share generic (non dedicated) diffuse textures, so baking AO into the diffusemap is no option in these cases.

-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.

 

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...

 

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.

Link to comment
Share on other sites

-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.

30239272.th.jpg

 

 

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:

shot00043c.th.jpg shot00043aotext.th.jpg

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.

Link to comment
Share on other sites

Sure, geometry based AO can be baked into every dedicated diffuse texture. That's no problem. I was just referring to the models that share generic textures, to whom only surface perturbation based AO can be applied, which would still be an improvement though. We'd still have to manually identify textures that already have AO baked in -> Big amount of work, but maybe worth it!! :)

 

Very few diffusemaps are shipped with various normalmaps, but since those normalmaps only differ slightly in most cases, we'd just have to decide which normalmap to use for the AO calculation. In the following example the decision would be hard though:

redbrickbeforeu.th.jpgredbrickaftermatlab.th.jpg

 

The remaining question now is where to store geometry based AO (generally preferable) efficiently for models sharing generic textures, without bloating up download size. Apparently there is no format I know of that is capable of compressing greyscale properly, besides generic image coders like jpeg etc.

 

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.

Hmn, would automated subdividing of surfaces be realistic here? We'd probably have to store some metainformation in the map-files in that case, so that the brush still is a single solid object within the editor, but multiple brushes to the map compiler. A configurable maximum edge-length should be used then to generate the subdivisions, so that the mapper has a little control over performance.

 

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.

I don't quite understand why it doesn't matter if a light is extinguishable or not, because if it is and the AO is precomputed for it, turning it of would result in unrealistic lighting ingame. Same problem goes for moveable lightsources, e.g. candles and torchguards.

Link to comment
Share on other sites

Example of per vertex AO in training mission:

shot00043c.th.jpg shot00043aotext.th.jpg

 

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://forums.thedarkmod.com/topic/9674-corner-edge-decals

And here is the original thread with example pictures:

 

http://forums.thedarkmod.com/topic/9321-edge-and-corner-grime-decal

 

Edit: Ha, I was right, the training map has hand-painted geometry AO:

 

http://forums.thedarkmod.com/index.php?app=core&module=attach&section=attach&attach_rel_module=post&attach_id=3464

 

Nice ob, Fidcal! :)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

I don't quite understand why it doesn't matter if a light is extinguishable or not, because if it is and the AO is precomputed for it, turning it of would result in unrealistic lighting ingame. Same problem goes for moveable lightsources, e.g. candles and torchguards.

 

I thought it doesn't matter because the AO is for _ambient_ lights only, and not for other lights. If you extinguish a torch, our automatic ambient light would fade to a slightly darker color, and that would affact the entire room, but that is ok, thats supposed to be so. However, AO doesn't change with the directional light at all. (IIUC ;)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Ah I forgot about the pure geometry based AO. How is that calculated anyway? I only know implementations of AO that take present lightsources (or rather light-faces) into account, similar to Global Illumination in 3d rendering programs.

Link to comment
Share on other sites

The basic idea is that you detect corners/crevices and make those darker. As the name "Ambient Occlusion" suggests, it's meant to emulate the idea that scattered ambient light (ambient = comes from all directions) is occluded (blocked) by nearby surfaces from falling into such crevices.

 

http://en.wikipedia.org/wiki/Ambient_Occlusion

 

If you were taking positioned light sources into account, I guess that would count as global illumination, not AO.

My games | Public Service Announcement: TDM is not set in the Thief universe. The city in which it takes place is not the City from Thief. The player character is not called Garrett. Any person who contradicts these facts will be subjected to disapproving stares.
Link to comment
Share on other sites

Finally!!! :D I always thought ambient occlusion was the same as radiosity, which is why I said light-faces were taken into account. The actual AO calculation seems somewhat comparable to the Radiosity-form-factor, which makes sense. I also understand now why the lightgem won't be affected by this. Thanks for clearing up my confusion...

 

But now I gotta say that I'd prefer lightmap support combined with radiosity or even global illumination rendering!! :)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

I just took the liberty of translating your post to bbcode (Check out my attachment)... To achieve such a hierarchy, you simply use nested list-statements. If you use list=a or list=1 you'll get ranked lists with numbers or letters. You might want to consider to add the text to your initial post in this thread as well.

AO-list.txt

Link to comment
Share on other sites

Interesting summary there JC. Although I'm not sure about half the stuff your talking about, I'm getting the gist of it.

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).

Someone correct me if I'm wrong.

Awesome work nontheless!

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

No doubt.

If AO works out, combined with your HDR work, D3 would look totally "next gen".

I'm salivating at the thought.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

Isn't that basically an additive blend effect? It just lightens whatever is behind it, and is still visible with no light at all?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 )



}

Link to comment
Share on other sites

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.

post-684-12683918758_thumb.jpgpost-684-126839186771_thumb.jpg

 

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

post-684-126839214242_thumb.jpgpost-684-126839186771_thumb.jpgpost-684-126839190446_thumb.jpg

 

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.

Link to comment
Share on other sites

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.

post-684-12683918758_thumb.jpgpost-684-126839186771_thumb.jpg

 

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

post-684-126839214242_thumb.jpgpost-684-126839186771_thumb.jpgpost-684-126839190446_thumb.jpg

 

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.

Link to comment
Share on other sites

Thanks for your help JC, however the translucent keyword still makes even fullbright places on the texture transparent. And when I use blend modulate to multiply the color with my "alphamap" the alpha blending at the borders doesn't work anymore. The screenshot visualizes both this and the fact that the texture is transparent everywhere.

post-684-126847450399_thumb.jpg

 

And here is the material definition I use:

   translucent

   diffusemap     textures/darkmod/decals/dirt/crumb_alpha_edge01

   {
 maskalpha
 blend modulate
 map textures/darkmod/nature/dirt/ash01
   }

   bumpmap       textures/darkmod/nature/dirt/dry_earth_stones_local

 

But let's assume for a second I am right about the fact that what I want to achieve is currently impossible with Id Tech 4. Would it be possible to implement it?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...