Search the Community

TDM Modpack v4.6 This update makes the TDM Modpack compatible with the development version of TDM 2.13, in case you want to test or use 2.13 now or during the upcoming beta phase and miss some mods... This new version of the Modpack remains, of course, compatible with 2.12. Let's take this opportunity to introduce a new mod: FORWARD LANTERN MOD I think this image explains very well what this mod is about: The implementation of the player lantern light has always bothered me. And while I understand the idea behind it, and despite its long radius, it feels annoying and frustrating for some reason. I started thinking about it and I realized the problem had to do with how light is distributed on screen: most of the times all I want is to focus on what's right ahead of me but the light forces me to focus on the sides. These two images should make my point very clear: ~ CURRENT ~ ~ NEW ~ On the technical side it is worth noting I moved the origin of the light from the hip to the bottom of the spine. I did this because in some situations the light would clip through objects and disappear but now that the light is well buried into the body clipping is impossible. Let us know your opinion about this mod and the player lantern in general! This mod is available for all missions except Flakebridge Monastery, Hazard pay, Moongate Ruckus, Snowed Inn, Vota 1, 2 & 3., which come with their own tweaks to the lantern. --------------------------------------------------- THE LOOP SKILL GET ITS FIRST UPDATE In the initial release I explained I was very conservative with the approach and in order to avoid potential issues you shouldn't be too close to walls or objects when using the Loop. Well, you will be glad to know a workaround has been found and the Loop is as responsive as it gets now and you can use it almost anywhere. Almost? I still haven't figured out how to force the player to crouch and the exception remains when there isn't enough vertical space. I hope someday the developers allow mappers and modders to force the player to crouch so that this mod can be fully realized and mappers can start their missions in vents or tight spaces. - Whoops, I'm outta here! You will probably notice that the Loop feels like it takes a little longer now: I detected that when jumping to some locations the engine needs some lead time to render the new environment. The jump essentially takes the same time as before but I added an extra second right after the jump to allow the engine to render everything properly. --------------------------------------------------- FINAL REORGANIZATION Starting now each skill is presented in its own slot and the Shadowmark Tool has been removed from Core Essentials and it is presented separately as well: Such a nice set of Mods we have! I hope you have fun with this new version of the TDM Modpack! The download can be found in the opening post. Here is the full changelog: • v4.6 New release - Minor changes to make it compatible with the upcoming TDM 2.13. - FORWARD LANTERN: Initial release. - SHADOW MARK: Now in its own mod slot. - SKILL UPGRADE: Skills now presented in their own mod slots. - SKILL LOOP: More responsive. Update to allow the engine render the world timely. - SHOCK MINE: Description added to the shop. - CORE ESSENTIALS - MISC: Decreased brightness of the Objectives and the Inventory. - CORE ESSENTIALS - MISC: Decreased brightness of stock newspapers. - CORE ESSENTIALS - MISC: Removed two anticlimactic player dying sounds. Cheers!

Oh never knew Doom 3 editor lacked prefab ability, one reason DR got so popular then, prefabs are awesome. I never used inhouse Doom3 editor, besides trying it for a few minutes but DR felt better to me, so I used that. Custom DR prefabs, do work in Doom 3, obviously TDM ones will not. I did used prefabs in Doom 3 for some things, like wall lamps and such, where I connected a model, a light and a particle effect for example. Never looked at the DR source code, but behind the scenes I bet the entities are just being bound to each other and that Doom 3 supports fine. About the topic, I would love to help the person but like i said, I never used inhouse Doom3 editor, so I can't really compare behaviors between the editors. And what you said sounds totally reasonable.

Myself and Baal have extensively used BounceLights in our WIP, the problem is that while they create superior lighting mood they effect the LG when we would rather they didn't. So my question is: Is there an arg or a script that can be applied to these BL's to stop them effecting the lightgem..?

Did some more testing just to figure out what's actually going on with the offset. I moved the gem further from the player to have a sort of "3rd person" view of what it's doing. The first part of the clip (0-7sec)has the lightGem rendered in VID_PLAYER_VIEW so I can see where it's actually going. The second part (7sec and onward) is with the lightGem rendered in VID_LIGHTGEM, where it belongs. My interpretation is that it shows that the light calculation appears to be incorrect when the gem is offset from the player. As to why... Hopefully, it's only a matter of time. EDIT: I went back through the game versions one by one. 2.06 works perfectly (I'm not exaggerating, at least for the test case I use). 2.07 is the first that starts exhibiting issues, and they seem to remain consistent for the rest of releases up to 2.12. EDIT2: I'm having trouble building 2.06 and 2.07 (in VS2013 - toolset v120) due to their dependencies on curl and other external libraries. If anyone has info on how to build these ancient projects, it would be much appreciated. Otherwise, I might just try it on Linux to see if it goes easier.

I did a bit of digging through the forum settings and I could not find any configuration for this. Looking at the underlying code, the comment count per page is hardcoded to 3. I could update the code, but I'm reluctant to do so as this would need to be re-applied after each update. That being said, it looks like we should start to brace for status updates being removed as Invision Forums v5 no longer supports status updates (we're still on v4.x): https://invisioncommunity.com/deprecation-tracker/status-updates-r19/ https://invisioncommunity.com/forums/topic/480551-status-updates-have-been-removed-in-v5/

Hello, everyone! In this multi-part, comprehensive tutorial I will introduce you to a new light type that has been available in The Dark Mod since version 2.06, what it does, why you would want to use it and how to implement it in your Fan Missions. This tutorial is aimed at the intermediate mapper. Explanations of how to use DarkRadiant, write material files, etc. are outside of its scope. I will, however, aim to be thorough and explain the relevant concepts comprehensively. Let us begin by delineating the sections of the tutorial: Part 1 will walk you through four, distinct ways to add ambient light to a scene, the last way using irradiance environment maps (or IEMs). Lighting a scene with an IEM is considered image-based lighting. Explaining this concept is not in the scope of this tutorial; rather, we will compare and contrast our currently available methods with this new one. If you already understand the benefits IBL confers, you may consider this introductory section superfluous. Part 2 will review the current state of cubemap lights in TDM, brief you on capturing an environment cubemap inside TDM and note limitations you may run into. Three cubemap filtering applications will be introduced and reviewed. Part 3 will go into further detail of the types of inputs and outputs required by each program and give a walkthrough of the simplest way to get an irradiance map working in-game. Part 4 will guide you through two additional, different workflows of how to convert your cubemap to an irradiance map and unstitch it back to the six separate image files that the engine needs. Part 5 will conclude the tutorial with some considerations as to the scalability of the methods hitherto explained and will enumerate some good practices in creating IEMs. Typical scenes will be considered. Essential links and resources will be posted here and a succinct list of the steps and tools needed for each workflow will be summarized, for quick reference. Without further ado, let us begin. Part 1 Imagine the scene. You’ve just made a great environment for your map, you’ve got your geometry exactly how you want it… but there’s a problem. Nobody can appreciate your efforts if they can’t see anything! [Fig. 1] This will be the test scene for the rest of our tutorial — I would tell you to “get acquainted with it” but it’s rather hard to, at the moment. The Dark Mod is a game where the interplay between light and shadow is of great importance. Placing lights is designing gameplay. In this example scene, a corridor with two windows, I have decided to place 3 lights for the player to stealth his way around. Two lights from the windows streak down across the floor and a third, placeholder light for a fixture later to be added, is shining behind me, at one end of the corridor. Strictly speaking, this is sufficient for gameplay in my case. It is plainly obvious, however, that the scene looks bad, incomplete. “Gameplay” lights aside, the rest of the environment is pitch black. This is undesirable for two reasons. It looks wrong. In real life, lights bounce off surfaces and diffuse in all directions. This diffused, omni-directional lighting is called ambient lighting and its emitment can be termed irradiance. You may contrast this with directional lighting radiating from a point, which is called point lighting and its emitment — radiance. One can argue that ambient lighting sells the realism of a scene. Be that as it may, suppose we disregard scary, real-life optics and set concerns of “realism” aside… It’s bad gameplay. Being in darkness is a positive for the player avatar, but looking at darkness is a negative for the player, themselves. They need to differentiate obstacles and objects in the environment to move their avatar. Our current light level makes the scene illegible. The eye strain involved in reading the environment in these light conditions may well give your player a headache, figurative and literal, and greatly distract them from enjoying your level. This tutorial assumes you use DarkRadiant or are at least aware of idtech4’s light types. From my earlier explanation, you can see the parallels between the real life point/ambient light dichotomy and the aptly named “point” and “ambient” light types that you can use in the editor. For further review, you can consult our wiki. Seeing as how there is a danger in confusing the terms here, I will hereafter refer to real life ambient light as “irradiant light”, to differentiate it from the TDM ambient lights, which are our engine’s practical implementation of the optical phenomenon. A similar distinction between “radiant light” and point lights will be made for the same reason. Back to our problem. Knowing, now, that most all your scenes should have irradiant light in addition to radiant light, let’s try (and fail, instructionally) to fix up our gloomy corridor. [Fig. 2] The easiest and ugliest solution: ambient lights. Atdm:ambient_world is a game entity that is basically an ambient light with no falloff, modifiable by the location system. One of the first things we all do when starting a new map is putting an ambient_world in it. In the above image, the darkness problem is solved by raising the ambient light level using ambient_world (or via an info_location entity). Practically every Dark Mod mission solves its darkness problem1 like this. Entirely relying on the global ambient light, however, is far from ideal and I argue that it solves neither of our two, aforementioned problems. Ambient_world provides irradiant light and you may further modulate its color and brightness per location. However, said color and brightness are constant across the entire scene. This is neither realistic, nor does it reduce eye strain. It only makes the scene marginally more legible. Let’s abandon this uniform lighting approach and try a different solution that’s more scene-specific. [Fig. 3] Non-uniform, but has unintended consequences. Our global ambient now down to a negligible level, the next logical approach would be hand-placed ambient lights with falloff, like ambient_biground. Two are placed here, supplementing our window point lights. Combining ambient and point lights may not be standard TDM practice, but multiple idtech4 tutorials extol the virtues of this method. I, myself, have used it in King of Diamonds. For instance, in the Parkins residence, the red room with the fireplace has ambient lights coupled to both the electric light and the fire flame. They color the shadows and enrich the scene, and they get toggled alongside their parent (point) lights, whenever they change state (extinguished/relit). This is markedly better than before, but to be honest anything is, and you may notice some unintended side-effects. The AI I’ve placed in the middle of the ambient light’s volume gets omnidirectionally illuminated far more than any of the walls, by virtue of how light projection in the engine works. Moving the ambient lights’ centers closer to the windows would alleviate this, but would introduce another issue — the wall would get lit on the other side as well. Ambient lights don’t cast shadows, meaning they go through walls. You could solve this by creating custom ambient light projection textures, but at this point we are three ad hocs in and this is getting needlessly complicated. I concede that this method has limited use cases but illuminating big spaces that AI can move through, like our corridor, isn’t one of them. Let’s move on. [Fig. 4] More directional, but looks off. I have personally been using this method in my WIP maps a lot. For development (vs. release), I even recommend it. A point light instead of an ambient light is used here. The texture is either “biground1” or “defaultpointlight” (the latter here). The light does not cast shadows, and its light origin is set at one side of the corridor, illuminating it at an angle. This solves the problem of omnidirectional illumination for props or AI in the middle of the light volume, you can now see that the AI is lit from the back rather than from all sides. In addition, the point light provides that which the ambient one cannot, namely specular and normal interaction, two very important features that help our players read the environment better. This is about as good as you can get but there are still some niggling problems. The scene still looks too monochromatic and dark. From experience, I can tell you that this method looks good in certain scenes, but this is clearly not one of them. Sure, we can use two, non-shadowcasting point lights instead of one, aligned to our windows like in the previous example, we can even artfully combine local and global ambient lights to furnish the scene further, but by this point we will have multiple light entities placed, which is unwieldy to work with and possibly detrimental to performance. Another problem is that a point light’s movable light origin helps combat ambient omnidirectionality, but its projection texture still illuminates things the strongest in the middle of its volume. I have made multiple experiments with editing the Z-projection falloff texture of these lights and the results have all left me unsatisfied. It just does not look right. A final, more intellectual criticism against this method is that this does not, in a technical sense, supply irradiant light. Nothing here is diffuse, this is just radiant light pretending the best it can. [Fig. 5] The irradiance map method provides the best looking solution to imbuing your scene with an ambient glow. This is the corridor lit with irradiance map lights, a new lighting method introduced in The Dark Mod 2.06. Note the subtle gradients on the left wall and the bounced, orange light on the right column. Note the agreeable light on the AI. Comparing the previous methods and this, it is plainly obvious that an irradiance environment map looks the most realistic and defines the environment far better than any of the other solutions. Why exactly does this image look better than the others? You can inform yourself on image-based lighting and the nature of diffuse irradiance, but images speak louder than words. As you can see, the fact of the matter is that the effect, subtle as it may be, substantially improves the realism of the scene, at least compared to the methods previously available to us. Procuring irradiance environment maps for use in lighting your level will hereafter be the chief subject of this tutorial. The next part will review environment cubemap capture in TDM, the makeIrradiance keyword and three external applications that you can use to convert a TDM cubemap into an irradiance map. 1 “ Note that the color buffer is cleared to black: Doom3 world is naturally pitch black since there is no "ambient" light: In order to be visible a surface/polygon must interact. with a light. This explains why Doom3 was so dark ! “ [source] Part 2 Cubemaps are not new to The Dark Mod. The skybox materials in some of our prefabs are cubemaps, some glass and polished tile materials use cubemaps to fake reflections for cheap. Cubemap lights, however, are comparatively new. The wiki page linked earlier describes these two, new light types that were added in TDM 2.05. cubicLight is a shadow-casting light with true spherical falloff. An example of such a light can be found in the core files, “lights/cubic/tdm_lampshade_cubic”. ambientCubicLight is the light type we will be focusing on. Prior to TDM 2.06, it acted as a movable, on-demand reflection dispenser, making surfaces in its radius reflect a pre-set cubemap, much like glass. After 2.06, the old behavior was discarded and ambientCubicLight was converted to accept industry standard irradiance environment maps. Irradiance environment maps (IEMs) are what we want to make, so perhaps the first thing to make clear is that they aren’t really “handmade”. An IEM is the output of a filtering process (convolution) which requires an input in the form of a regular environment cubemap. In other words, if we want to make an IEM, we need a regular cubemap, ideally one depicting our environment — in this case, the corridor. I say a snapshot of the environment is ideal for lighting it because this emulates how irradiant light in the real world works. All radiating surfaces are recorded in our cubemap, our ambient optic array as it were, then blurred, or convoluted, to approximate light scatter and diffusion, then the in-game light “shines” this approximation of irradiant light back to the surfaces. There is a bit of a “chicken and the egg” situation here, if your scene is dark to begin with, wouldn’t you just get a dark irradiance map and accomplish nothing? In the captured cubemap faces in Fig. 6, you may notice that the environment looks different than what I’ve shown so far. I used two ambient lights to brighten up the windows for a better final irradiance result. I’ve “primed the pump”, so to speak. You can ignore this conundrum for the moment, ways to set up your scenes for better results, or priming the pump correctly, will be discussed at the end of the tutorial. Capturing the Environment The wiki has a tutorial on capturing cubemaps by angua, but it is woefully out of date. Let me run you through the process for 2.07 really briefly. To start with, I fly to approx. the center of the corridor with noclip. I then type “envshot t 256” in the console. This outputs six .tga images in the <root>/env folder, simply named “t”, sized 256x256 px and constituting the six sides of a cube and depicting the entire environment. This is how they look in the folder: [Fig. 6] The six cube faces in the folder. Of note here is that I do not need to switch to a 640x480 resolution, neither do I need to rename these files, they can already be used in an ambientCubicLight. Setting Up the Lights For brevity’s sake, I’ll skip explaining material definitions, if you’ve ever added a custom texture to your map, you know how to do this. Suffice it to say, it is much the same with custom lights. In your <root>/materials/my_cool_cubemaps.mtr file, you should have something like this: lights/ambientcube/my_test_IEM_light { ambientCubicLight { forceHighQuality //cameraCubeMap makeIrradiance(env/t) cameraCubeMap env/t colored zeroClamp } } We’ll play with the commented out line in just a bit. Firstly, let’s place the actual light in DarkRadiant. It’s as simple as creating a new light or two and setting them up in much the same way you would a regular ambient light. I select the appropriate light texture from the list, “my_test_IEM_light” in the “ambientcube” subfolder and I leave the light colored pure white. [Fig. 7] The corridor in DR, top view, with the ambient cubic lights highlighted. I can place one that fills the volume or two that stagger the effect somewhat. Remember that these lights still have a spherical falloff. Preference and experimentation will prove what looks best to you. Please note that what the material we defined does is load a cubemap while we established that ambientCubicLights only work with irradiance maps. Let’s see if this causes any problems in-game. I save the map and run it in game to see the results. If I already have TDM running, I type “reloadDecls” in the console to reload my material files and “reloadImages” to reload the .tga images in the /env folder. [Fig. 8] Well this looks completely wrong, big surprise. Wouldn’t you know it, putting a cubemap in the place of an irradiance map doesn’t quite work. Everything in the scene, especially the AI, looks to be bathed in slick oil. Even if a material doesn’t have a specular map, it won’t matter, the ambientCubicLight will produce specular reflections like this. Let’s compare how our cubemap .tga files compares with the IEM .tgas we’ll have by the end of the tutorial: [Fig. 9] t_back.tga is the back face of the environment cubemap, tIEM_back.tga is the back face of the irradiance map derived from it. As you can see, the IEM image looks very different. If I were to use “env/tIEM” instead of “env/t” in the material definition above, I would get the proper result, as seen in the last screenshot of part 1. So it is that we need a properly filtered IEM for our lights to work correctly. Speaking of that mtr def though, let’s not invoke an irradiance map we haven’t learned to convert yet. Let’s try an automatic, in-engine way to convert cubemaps to IEMs, namely the makeIrradiance material keyword. makeIrradiance and Its Limitations Let’s uncomment the sixth line in that definition and comment out the seventh. cameraCubeMap makeIrradiance(env/t) //cameraCubeMap env/t Here is a picture of how a cubemap ran through the makeIrradiance keyword looks like: [Fig. 10] Say ‘Hi’ to our friend in the back, the normalmap test cylinder. It’s a custom texture I’ve made to demonstrate cubemap interactions in a clean way. Hey now, this looks pretty nice! The scene is a bit greener than before, but you may even argue it looks more pleasing to the eyes. Unfortunately, the devil is in the details. Let’s compare the makeIrradiance keyword’s output with the custom made irradiance map setup seen at the end of part 1. [Fig. 11, 12] A closer look at the brick texture reveals that the undesired specular highlighting is still present. The normal map test cylinder confirms that the reason for this is the noisy output of the makeIrradiance keyword. The in-engine conversion is algorithmic, more specifically, it doesn't allow us to directly compare .tga files like we did above. Were we able to, however, I'm sure the makeIrradiance IEM would look grainy and rough compared to the smooth gradient of the IEM you’ll have by the end of this tutorial. The makeIrradiance keyword is good for quick testing but it won’t allow you fine control over your irradiance map. If we want the light to look proper, we need a dedicated cubemap filtering software. A Review of Cubemap Filtering Software Here I’ll introduce three programs you can produce an irradiance map with. In the coming parts, I will present you with a guide for working with each one of them. I should also note that installing all of these is trivial, so I’ll skip that instructional step when describing their workflows. I will not relay you any ad copy, as you can already read it on these programs’ websites. I’ll just list the advantages and disadvantages that concern us. Lys https://www.knaldtech.com/lys/ Advantages: Good UI, rich image manipulation options, working radiance/specular map filtering with multiple convolution algorithms. Disadvantages: $50 price tag, limited import/export options, only available on Windows 64-bit systems. cmftStudio https://github.com/dariomanesku/cmftStudio Advantages: Available on Windows, OSX and Linux, free, open source software, command line interface available. Disadvantages: Somewhat confusing UI, limited import options, missing features (radiance/specular map filtering is broken, fullscreen doesn’t work), 32-bit binaries need to be built from source (I will provide a 32-bit Windows executable at the end of the tutorial). Modified CubeMapGen https://seblagarde.wordpress.com/2012/06/10/amd-cubemapgen-for-physically-based-rendering/ Advantages: Free software, quickest to work with (clarified later). Disadvantages: Bad UI, only Windows binaries available, subpar IEM export due to bad image adjustment options. Let’s take a break at this point and come back to these programs in part 3. A lot of caveats need to be expounded on as to which of these three is the “best” software for making an irradiance map for our purposes. Neither of these programs has a discreet workflow; rather, the workflow will include or exclude certain additional programs and steps depending on which app you choose to work with. It will dovetail and be similar in all cases. Part 3 The aim of this tutorial is twofold. First, it aims to provide the most hands-free and time-efficient method of converting an envshot, environment cubemap to an IEM and getting it working in-game. The second is using as few applications as possible and keeping them all free software that is available for download, much like TDM itself. The tutorial was originally going to only cover IEM production through Lys, as that was the app I used to test the whole process with. I soon realized that it would be inconsiderate of me to suggest you buy a fifty dollar product for a single step in a process that adds comparatively little to the value of a FM, if we’re being honest (if you asked me, the community would benefit far more from a level design tutorial than a technical one like this, but hey, maybe later, I’m filling a niche right now that nobody else has filled). This led me to seek out open-source alternatives to Lys, such as Cubemapgen, which I knew of and cmftStudio, which I did not. I will preempt my own explanations and tell you right away that, in my opinion, cmftStudio is the program you should use for IEM creation. This comes with one big caveat, however, which I’m about to get into. Six Faces on a Cross and The Photoshop Problem Let’s review. Taking an envshot in-game gives you six separate images that are game-ready. Meaning, you get six, split cubemap faces as an output, you need six, split irradiance map faces as an input. This is a problem, because neither Lys nor cmftStudio accept a sequence of images as such. They need to be stitched together in a cube cross, a single image of the unwrapped cube, like this: [Fig. 13] From Lys. Our cubemap has been stitched into a cross and the “Debug Cube Map Face Position” option has been checked, showing the orientations of each face. In Lys only panoramas, sphere maps and cube maps can be loaded into the program. The first two do not concern us, the third specifically refers to a single image file. Therefore, to import a TDM envshot into Lys you need to stitch your cubemap into a cross. Furthermore, Lys’ export also outputs a cubemap cross, therefore you also need to unstitch the cubemap into its faces afterwards if you want to use it in TDM. In cmftStudio you can import single map faces! Well… no, you can’t. The readme on GitHub boasts “Input and output types: cubemap, cube cross, latlong, face list, horizontal and vertical strip.” but this is false. The UI will not allow you to select multiple files on import, rendering the “face list” input type impossible.2 Therefore, to import a TDM envshot into cmftStudio you need to stitch your cubemap into a cross. Fortunately, the “face list” export type does work! Therefore, you don’t need to unstitch the cubemap manually, cmftStudio will export individual faces for you. In both of these cases, then, you need a cubemap cross. For this tutorial I will use Adobe Photoshop, a commercial piece of software, to stitch our faces into a cubemap in an automated fashion (using Photoshop’s Actions). This is the big caveat to using cmftStudio, even if you do not want to buy Lys, PS is still a prerequisite for working with both programs. There are, of course, open source alternatives to Photoshop, such as GIMP, but it is specifically Photoshop’s Action functionality that will power these workflows. GIMP has its own Actions in the form of Macros, but they are written with python. GIMP is not a software suite that I use, neither is python a language I am proficient with. Out of deference for those who don’t have, or like working with, Photoshop, I will later go through the steps I take inside the image editor in some detail, in order for the studious reader to reconstruct them, if they so desire, in their image editing software of choice. At any rate, and at the risk of sounding a little presumptuous, I take it that, as creative types, most of you already have Photoshop on your computers. 2 An asterisk regarding the “impossibility” of this. cmftStudio is a GUI for cmft, a command line interface that does the same stuff but inside a command prompt. I need to stress that I am certain multiple faces can be inputted in the command line, but messing with unwieldy prompts or writing batch files is neither time-saving nor user-friendly. This tutorial is aimed at the average mapper, but a coder might find the versatility offered in cmft interesting. The Cubemapgen Workflow You will have noticed that I purposefully omitted Cubemapgen from the previous discussion. This is because working with Cubemapgen, wonderfully, does not need Photoshop to be involved! Cubemapgen both accepts individual cubemap faces as input and exports individual irradiance map faces as output. Why, then, did I even waste your time with all the talk of Lys, cmftStudio and Photoshop? Well, woefully, Cubemapgen’s irradiance maps look poor at worst and inconsistent at best. Comparing IEMs exported from Lys and cmftStudio, you will see that both look practically the same, which is good! An IEM exported from Cubemapgen, by default, is far too desaturated and the confusing UI does not help in bringing it to parity with the other two programs. If you work solely with Cubemapgen, you won’t even know what ‘parity’ is, since you won’t have a standard to compare to. [Fig. 14] A comparison between the same irradiance map face, exported with the different apps at their respective, default settings. Brightened and enlarged for legibility. This may not bother you and I concede that it is a small price to pay for those not interested in working with Photoshop. The Cubemapgen workflow is so easy to describe that I will in fact do just that, now. After I do so, however, I will argue that it flies in the face of one of the aims of this tutorial, namely: efficiency. Step 1: Load the cubemap faces into Cubemapgen. Returning to specifics, you will remember that we have, at the moment, six .tga cubemap faces in a folder that we want to convert to six irradiance map faces. With Cubemapgen open, direct your attention to these buttons: [Fig. 15] You can load a cubemap face by pressing the corresponding button or using the hotkey ‘F’. To ensure the image faces the correct way, you must load it in the corresponding “slot”, from the Select Cubemap Face dropdown menu above, or by pressing the 1-6 number keys on your keyboard. Here is a helpful list: X+ Face <1> corresponds to *_right X- Face <2> corresponds to *_left Y+ Face <3> corresponds to *_up Y- Face <4> corresponds to *_down Z+ Face <5> corresponds to *_forward Z- Face <6> corresponds to *_back ...with the asterisk representing the name of your cubemap. With enough practice, you can get quite proficient in loading cubemap faces using keyboard shortcuts. Note that the ‘Skybox’ option in the blue panel is checked, I recommend you use it. Step 2: Generate the Irradiance Map [Fig. 16] The corridor environment cubemap loaded in and filtered to an irradiance map. The options on the right are my attempt to get the IEM to look right, though they are by no means prescriptive. Generating an IEM with Modified CubeMapGen 1.66 is as easy as checking the ‘Irradiance cubemap’ checkbox and hitting ‘Filter Cubemap’ in the red panel. There are numerous other options there, but most will have no effect with the checkbox on. For more information, consult the Sébastien Lagarde blog post that you got the app from. I leave it to you to experiment with the input and output gamma sliders, you really have no set standard on how your irradiance map is supposed to look, so unfortunately you’ll have to eyeball it and rely on trial and error. Two things are important to note. The ‘Output Cube Size’ box in the red panel is the resolution that you want your IEM to export to. In the yellow panel, make sure you set the output as RGB rather than RGBA! We don’t need alpha channels in our images. Step 3: Export Irradiance Map Faces Back in the green panel, click the ‘Save CubeMap to Images’ button. Save the images as .tga with a descriptive name. [Fig. 17] The exported irradiance map faces in the folder. These files still need to be renamed with appropriate suffixes in order to constitute a readable cubemap for the engine. The nomenclature is the same as the table above: “c00” is the X+ Face, to be renamed “right”, “c01” is the X- Face and so on. Right left, up down, forward and back. That’s the order! This is all there is to this workflow. A “cameraCubeMap env/testshot” in the light material will give us a result that will look, at the very least, better than the inbuilt makeIrradiance material keyword. [Fig. 17] The map ended up being a little bright. Feel free to open Fig. 4 and this in seperate tabs and compare the Lys/cmft export with the cubemapgen one. A Review of the Workflow Time for the promised criticism to this workflow. I already stated my distaste for the lack of a standardised set of filtering values with this method. The lack of any kind of preset system for saving the values you like makes working with Cubemapgen even more slipshod. Additionally, in part 2, I said that Cubemapgen is the fastest to work with, but this needs to be qualified. What we just did was convert one cubemap to an irradiance map, but a typical game level ought to use more than a single IEM. Premeditation and capturing fake, “generic” environment cubemaps (e.g. setting up a “blue light on the right, orange on the left” room or a “bright skylight above, brown floor” room, then capturing them with envshot) might allow for some judicious reuse and keep your distinct IEM light definition count down to single digits, but you can only go so far with that. I am not arguing here for an ambient cubic light in every scene either, certainly only those that you deem need the extra attention, or those for which the regular lighting methods enumerated in Part 1 do not quite work. I do tentatively assume, though, that for an average level you would use between one and two dozen distinct IEMs. Keep in mind that commercial games, with their automated probe systems for capturing environment shots, use many, many more than that. With about 20 cubemaps to be converted and 6 faces each to load into Cubemapgen, you’ll be going through the same motions 120 whole times (saving and renaming not included). If you decide to do this in one sitting (and you should, as Cubemapgen, to reiterate, does not keep settings between sessions), you are in for a very tedious process that, while effective, is not very efficient. The simple fact is that loading six things one by one is just slower than loading a single thing once! The “single thing” I’m referring to is, of course, the single, stitched cubemap cross texture. In the next part, I will go into detail regarding how to make a cubemap cross in Photoshop in preparation for cmftStudio and Lys. It will initially seem a far more time-consuming process to you than the Cubemapgen workflow, but through the magic of automation and the Actions feature, you will be able to accomplish the cubemap stitch process in as little as a drag-and-drop into PS and a single click. The best thing is that after we go through the steps, you won’t have to recreate them yourself, as I will provide you with a custom Actions .atn file and save you the effort. I advise you not to skip the explanations, however. The keen-eyed among you may have noticed that you can also load a cube cross in Cubemapgen. If you want to use both Cubemapgen and Photoshop together to automate your Cubemapgen workflow, be aware that Cubemap gen takes crosses that have a different orientation than the ones Lys and cmftStudio use. My macros (actions) are designed for the latter, so if you want to adjust them for Cubemapgen you would do well to study my steps and modify them appropriately. For the moment, you’ve been given the barebones essentials needed to capture an envshot, convert it to an irradiance map and put it in your level at an appropriate location, all without needing a single piece of proprietary software. You can stop here and start cranking out irradiance maps to your heart’s content, but if you’re in the mood for some more serious automation, consider the next section.

PLAYERS Implemented new system to estimate light for AI purposes. Players usually try to hide bodies in dark places so that guards don't see it when passing by. However, the old light estimate system does not properly account for shadows, so what is dark for player can be fully bright for AI. The new system considers all the details including: shadows, projected light textures, cubemaps, blinking and multistage lights, invisible skins (thread). There are many improvements to mission lists in the main menu. It is easy to search mission by name/author prefix, more missions fit into the visible area, several lists can now be scrolled. Default settings should no longer cause any extra micro-stutters, because Uncapped FPS and Vsync are enabled by default now. Other improvements include: support for Vsync on Linux, better implementation of FPS limit on Windows 8 and later. Level loading is further accelerated with better utilization of multicore CPUs and parallel loading of sound samples. Loading progress bar has been reimplemented to reflect all the optimizations of the past years. Subtitles got some improvements as well. The volume estimation is much better now, subtitles for too quiet sounds are no longer shown. Visual appearance of the subtitles font has been greatly improved. Tonemapping has been altered to improve appearance of overly bright colors. Such colors are no longer clamped at value = 1 and they desaturate at high brightness. Finally, brightness slider should be much more useful now (post). The training mission is further updated with vine arrows, EFX reverb, and better performance. New footstep sounds added for broken glass and ice. MAPPERS Added support for parallax mapping. This effect can be used to fake highly detailed geometry in some cases. (wiki, thread) Major overhaul for drunk AIs. Mappers now only have to set the "drunk" spawnarg to "1" on any AI in order for that AI to appear "drunk", and better yet, there are several customization options available to mappers to make their drunk AI more unique. In order to make this happen, we added two new drunk vocal sets for the Drunk Moor and Drunk Jack, respectively. In addition to several bug fixes, there are now improved drunk animations and drunk greetings, female AI and manbeasts can now also be drunk, and drunk idle bark times have been improved. Supported GUI debriefing screen on mission success. Previously mappers could set up debriefing video, but could not make arbitrary interactive GUI like they could do with briefing (thread). Also, mapper can pass information from GUI briefing to game and from game to GUI debriefing via persistent info. Previously it was only used to pass info between missions in a campaign (wiki). Finally, missions are allowed to modify cvars in relatively safe way. This is possible due to the new concept of "cvar mission override", which are part of game state. They can be set by script function sys.setcvar and by game console commands setm / unsetm. Beware that most of cvars are still internal and are not fixed for the sake of backward compatibility! (thread) Also, the cvar system has been cleaned up a bit and is thread-safe now. Major improvements in bumpmapped environment mapping: texcoords transforms like translate and rotate do work now, it is OK to have several bumpmap stages toggled on and off dynamically. The visual appearance has also been changed and is now similar to non-bumpmapped case (thread). The behavior of zero sound spawnargs has been changed: now it indeed sets the volume to zero, while previously it had no effect compared to nonexistent spawnarg (thread). The interaction groups in material are now extracted differently. Most importantly, you can split material stages across interactions using the new interactionSeparator syntax (thread). Some features are now enabled for shadow maps despite them being impossible to implement with stencil shadows: shadows on transparent surfaces and alpha-tested shadows (poll). Nested subviews now work properly: mirrors, remotes, sky, etc. They cost tremendous amount of performance, so this is not a feature to rely on. But it is still better than to have a large mirror turn black whenever a small water puddle with mirror material gets into player's view. It has become easier to set standard EFX settings with the new efx_preset spawnarg (thread). Several new player tools have been added: slowfall potion (thread) gas mine invisibility potion (from @kingsal missions) BUGS * Fixed dmap making almost axis-aligned visportals buggy (6480). * Fixed bug in idClip::Translation of non-centered models. * Fixed light culling bug on elongated models with non-identity rotation (6557). * Fixed rendering of volumetric light and particles in X-ray views and mirrors (6538). * Workaround for compiler bug which broke particle collisions with texture layout (post). * Fixed rare crash on loading collision models (post). * Fixed map immobilization not applied if opening map with inv use key. * Fixed frob interaction with candle holder that's initially extinguished (6577). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. INTERNAL The system for third-party dependencies has been moved to Conan 2 and extended. Now the CI server regularly builds TDM and its dependencies completely from source code.

Yeah i think of something a bit more specialized like the mechanism of hardware occlusion but used to feed the tensor cores with geometry data. Could be used for all kinds of raytracing effects light reflection shadows etc. Many years back me and a friend developed a different kind of getting light geometry for bumpmapping which was about 90% more effective than the normal way of doing it. It uses a way of getting getting geometry based on what the player is seing instead of the lightsource. Since there can be a gazillion different lightsources and the normal way has to calculate all of them it is quite wastefull. Our way only has to calculate what is in the players view so its quite a lot faster. I still have the code for the experimental quake engine we used it on if someone wants a look.

Yeah I'm seeing this too. Also running TDM 2.12 on Windows 10. Here's a decent spot to test it in the Training Mission, near a light on the path to the "Stealth and Shadows" tutorial building. Position is (-441.6 -2420.27 221.35) according to the screenshot filename. Crouched, normal: Crouched, leaning forward: It seems to work to some degree on most or all lights, but the strength varies. I feel like it's something to do with the elevation of the light compared to the player, not sure though. Definitely quite abusable to hide where one shouldn't be able to, getting nearly the minimum light gem value despite being very close to a light source.

I hope I'm not proposing some unfeasible idea that was already imagined before, this stuff is fun to discuss so no loss still. Riding the wave of recent optimizations, I keep thinking what more could be done to reach a round 144 FPS compatible with today's monitors. An intriguing optimization came to mind which I felt I have to share: Could we gain something if we had distance-based LOD for entity updates, encompassing everything visual from models to lights? How it would work: New settings allow you to set a start distance, end distance, and minimum rate. The further an entity gets the lower its individual update rate, slowly decreasing from updating each frame (start distance and closer) to updating at the minimum rate (end distance and further). This means any visual change is preformed with frame skips on any entity: For models such as characters animations are updated at the lower rate, for lights it means shadows are recalculated less often... even changes in the position and rotation of an entity may follow it for consistency, this would especially benefit lights with a moving origin like fireplaces or torches held by guards which recalculate per-frame. Reasoning: Light recalculation even animated models or individual particles can be significant contributors to performance drain. We know the further something is from the camera the less detail it requires, this is why we have a level-of-detail system with lower-polygon LOD models for characters and even mapmodels. Thus we can go even further and extend the concept to visual updates; Similar to how you don't care if a far away guard has a low-poly helmet you won't notice, you won't care if that guard is being animated at 30 FPS out of your maximum of 60, nor if the shadow of a small distant light is being updated at 15 FPS when an AI passes in front of it. This is especially useful if you own a 144 Hz monitor and expect 144 FPS: I want to see a character in front of me move at 144 FPS, but may not even notice if a guard far away is animating at 60 FPS... I want the shadows of the light from the nearby torch to animate smoothly, but can care less if a lamp meters away updates its shadows at 30 FPS instead. The question is if this is easy to implement in a way that offers the full benefit. If we use GPU skinning for instance, the graphics card should be told to animate the model at a lower FPS in order to actually preserve cycles... does OpenGL (and in the future Vulkan) let us do this per individual model? I know the engine has control over light recalculations which would probably yield the biggest benefit. Might add more points later as to not make the post too big, for now what are your thoughts?

I was replaying this GEM of a mission and remembering Thanks to this forum thread I also discovered As for one of the secrets, well, HUGE thank you to all of the creators of this mission!

I remember Melchior suggested new weapons once: "For the weapon system to be built around General Type/Intended Use: Blackjack / Club / Heavy-Vase / Hammer / Ether & Rag, ect... {Knockout weapons/tools} Short-Sword / Dagger / Stiletto, Blow-darts, ect... {Killing weapons/tools} Water (arrows) / Extinguisher (manual water pump) / Soot (arrows)... {Light Dousing tools} Fire; 'Explosive' (arrows) / Concussion (arrow) / Incendiary (arrow)... {Explosive weapon/tools} Rope (arrows) / Vine (arrows) / Grappling-Hook (hook & chain)... {Vertical movement tools} 'Ether' Gas (arrows) / 'Tear' Gas (arrows) / 'Mustard' Gas (arrows)... {Mixed use gas/vapour tools} Moss (arrows) / Paint (arrows) ...{Sound-impact / light absorbing tools} Glue (arrows) / Flash (arrows) / Noisemaker (arrows) / Fire-crackers... {Distracting / disabling tools} Noting the following are new; Heavy-Vase: used double-handed; a loud single use blackjack that leaves a mess... Dagger, Stilleto: Short range, Can't block - the latter CAN penetrate armour if attacking a weak-point... Blow-Darts: Specialized tool of assassins - useful dealing with multiple guards...or special people (its deadly). Ether-vial & Rag: Used from behind its very effective at disabling. It will evaporate in moments, limited uses. Extinguisher: Ever wanted to just spray some water on a torch? This, does that. That's it. Only close up. Paint Arrows: Permanently covers electric light sources & blinds optical sensors [which WILL trigger them!]. Glue Arrows: So, you need to stop charging guards?; Loosing one of these creates a puddle of Ultra-Adhesive capable of binding anything together for a little while. Works against Bi-pedal AND Quadrupedal foes!"

And some info can be found on this forum topics and wiki. Wiki article: https://wiki.thedarkmod.com/index.php?title=Parallax_mapping Topic: https://forums.thedarkmod.com/index.php?/topic/22574-experimental-support-of-parallax-mapping-in-213/

I read the release notes for 2.13 and was really impressed with the new AI lighting detection. I'm really curious how exactly it works - the notes mention a stochastic sampling of light pixels but what does that mean in practice (and why couldn't it be done before)? Are the light pixels on objects whose shaders are recording per-pixel lighting stochastically and then sending them to the CPU via compute shader? If so, does that mean values are only updated when they're being rendered on screen when the player looks at them? So many questions!

Start here: All "potentially visible" ( from AI pov ) entities run the full render pipeline for a random group of nearby pixels. Light and shadow casting is interleaved with the results added to a weighted running average. Before we had the Doom 3 source, there was no good way to sample the light textures in parallel for better performance.

Oohhhh, the day has come! This old lurker releases another creation of his deranged mind...! What has he in store? Does it involve sunlight and pollen and hayfever? Will it involve strange towers and priests with bad breath? Naah, just some mediocre airship type of mission, aimed at the Anniversary mapping contest! I have a lengthy/humourly rant/lore for some of the building process for anyone interrested, in spoiler tags. According to DarkRadiant I have worked 570 hours on this, and that doesn't take into account all hours of coding and scripting. This feels like an insanely huge amount of mapping time for this small mission but I try not to judge myself. DarkRadiant says 570 so...I say thanks to all calm hours at the night shift at work where I could sit and script and write readables. And I also humbly bow myself to the scripting genuses that are on the forums. A special thanks to my girlfriend who (almost) always lets me talk about my projects. She has also written some of the readables and voiced some recordings in the mission. Thanks to Dragofer, Mirceakitsune and Melchior for much needed scripting help. Thanks to YouTube channels BGM President and Sound Effects where I've borrowed some music and sound effects. Thanks to my betatesters; nbohr1more, Bergante, datiswous, Wesp5, nightmare, Jaxa and Cambridge Spy. And a big thank you to the mod in general for still being alive and supportive! ########################################## MISSION RELATED STUFF ########################################## On an airship, heading for Flowerdale a lot of strange things can happen. As some people guzzle down liquor in the bar, some others skulk around in the shadows. Certain people cannot be trusted and there are even those that kill for a living. Somebody may or may not work for foreign powers. But everyone yearns for those shiny pennies. There are some strange things in the cargo, huge coffers that can hold bodies, alive and dead. This story may unfold in several different ways; Three characters can be chosen; Zacharias the thief, Oliver Mortimer, the assassin or Rupert Peabody, youngling of the Wizlas woodfolk. DOWNLOAD LINK https://drive.google.com/file/d/10w_SJSBAxxVFYTwPjJhIo48fEzvuTo1M/view?usp=sharing

Thanks! I thought they were pretty fun. I haven't looked at those powder kegs in a long time, but it might be worth re making them someday. I remember them being fun to light with the flint and then tossing them on bad guys heads. @chumbucket91The powderkegs in volta 2 also use the flinder system but I think its a very different set up from the crates in volta 3. Might be useful in your search though.

@ArcturusIts probably a combination of things that contribute to gaps in the lightgem read out and the visual perception of how bright you are. I use light gem adjustments and a lot of ambient lights set to "ai_see" "0" I have my reasons for lighting missions this way, but its it a lot of manual work and prone to error. Its a trade off between light gem accuracy and cool lighting @WellingtoncrabNever though to set ambient_world to ai_see 0. Thats a great little trick.

Hello taffers, the people over at TTLG forums have started a speedbuild game jam. 1st Thief Speedbuild Jam It's not a contest, and you have a tentative submission date of Dec 1, to get a mission built for T1-3 or TDM. Looks fun, and I'm going to participate too.

Yes cavador, i think there is no problem with this. The excellent author Bienie tell you a story at the beginning and created all that hard work that you now can play and maybe enjoy while you live your real life. I understand that maybe you have found difficult to solve the objectives, but my advice is simple. Read the readables and enjoy this little gem in the TDM missions. I have replayed the mission actually and have not found any bug or something.

Inn Business It's business, at an inn, over three nights. Development screenshots: Download: https://drive.google...dit?usp=sharing Update 1.48 uploaded March 8th, 2014, one change: patches key rarely not being frobable in one of its possible spots Big thanks to my beta testers: Airship Ballet, Kyyrma and AluminumHaste! Development supporters of note: Sotha, Springheel and Obsttorte. Also thanks Sotha, for urinating in my mission. ;-) And thanks Kyyrma for the title screen! My appreciation to all forum/wiki contributors, without whom, this wouldn't exist. Thanks to positive commenters on my previous mission too, extra motivation helps! :-) Note this uses campaign features, what you use the first night, impacts subsequent nights. And to quote a tester, "...the level is maybe best experienced in more than one sitting". If you do pause between nights, please be sure to save, you can't begin partway through effectively. (If you accidentally start a night you already completed, just fail the kill objective to switch to another night.) If your frame rates are too low facing the cemetery, please reduce your "Object Details LOD" setting. It was designed with "AI Vision" set to "Forgiving", to be able to sneak through with minimal reactions, if you want more/less, adjust your settings accordingly. There are several random, conditional aspects, and ways of going about things, so others might have slightly different experiences. Post here if you discover hidden objectives for extra points! My condolences to loot completionists, I made a bit on the third night hard, you've got your challenge cut out for you! Speaking of which, there's a TDM bug that mission complete totals too high, here are the real amounts per night: 2026/970/202. Oh, there is something that in the U.S. would be rated PG, in case you play with kids in earshot. I hope you enjoy playing it, feel free to let me know you did, and I'm glad to respond to inquiries (like how stuff was done, nothing was scripted). (Note which night you are referring to if it's something specific.) (Please remember spoiler tags to not expose things meant to be discovered by playing.) Like so: [spoiler]secrets[/spoiler] Developed for TDM 2.01. PS: Thiefette, good news, no spiders! Springheel, if you find an optional objective you can skip...you might find it immersion breaking. Others, no undead! There are a couple other interactive critters though. :-) Edit note: Some posts below were from users of an unreleased version of TDM 2.02 which broke several things, they do not reflect regular game-play.

It would explain why volumes don't work with parallel lights then: They're being forced to stencil in that case. Hopefully the large lights limitation won't be around forever and all lights will use shadow maps eventually. Makes me wonder: What if the scale of shadow maps changed with light size? I remember it's a fixed setting, say 1024 global shadow map resolution; If they're unique per light maybe they should snap to the nearest increment (in powers of 2) based on the radius of the lamp, which would hopefully improve performance without overusing (v)RAM. For example: A candle can likely have a shadow map of just 128px or 256px, a torch flame 512px, street lamps are large enough to be 1024px... for a sun light it could stretch all the way to 2048px or even 4096px but it would only be for one light so most GPU's should handle it especially since the data is grayscale so just one color channel for intensity.

Quick idea I forgot to ask a while back, since new assets are still being added to the beta I figured it should work: Can we add the pray animation? Several FM's include pray.md5anim to have stuff like builders praying in churches: Figured FM creators would be grateful to have it available with everything else. I'd also consider Kingstal's animated grass, same situation. I improved it a bit in my FM, Gem of Souls: Let me know if you want my pk4 with the materials and entity configurations I tweaked.

Are you sure that can be set as a spawnarg? I think this needs to be specified in materials. Sorry, didn't read the wiki page well. Core light material: lights/square_strobe { { forceHighQuality map lights/squarelight1.tga red ( blinktable2 [Parm4 + (time * (6 * Parm3)) ]) * Parm0 green ( blinktable2 [Parm4 + (time * (6 * Parm3)) ]) * Parm1 blue ( blinktable2 [Parm4 + (time * (6 * Parm3)) ]) * Parm2 zeroclamp } } Maybe you have to set it in a material and then modify it via a spawnarg? The spawnarg setting for that light entity would link the specified number (0-1) to "Parm4" in the material code. I mean that makes sense to me. Or maybe that's how you meant it?

I am currently going through tons of Dark Mod FMs and replaying them. So far, I can play all of them in 4k resolution at a full 60fps without ever dropping a frame except for two: 1. Gem of Souls 2. Scroll of Remembrance Both of these FMs drops my frame rate into the 40s constantly and they are both created by the same author.