Search the Community

Of course. The depth hack works as intended and basically stops weapons and weapon attachments from clipping through the map geometry. I confirmed this by setting it to false in the engine code and noticed that the weapons/items clipped without the hack enabled. I think the issue happens when an object is fully outside of the map. You can see this if you "noclip" to an out of bounds zone, the weapon will stop being rendered. So, when the player leans against a wall, the items in the hand, which are fairly small, will be completely outside of the map and thus stop showing on screen. To fix this, I simply added a square plane to the object model to make it bigger than it actually is, and added the "nodraw" texture to this plane so it wouldn't be visible. This way, the object is big enough that some part of it is always inside the map, forcing it to be rendered. The easiest way to add this invisible plane is by exporting the object model we want as an ASE file in Dark Radiant - so we can open and change it - and then manually adding the geometry and material of the plane to the file. I edited the first item in blender to add the invisible plane and then saved its geometry and material in a template file that I can now use to just copy and paste to any new models I want to add to the mod. It seems to work well. The only important part is exporting the model in Dark Radiant with origin at "0 0 0", since the first plane was created for an item with that origin.

Unfortunately, I don’t think this is possible—at least not with the way the mod is currently implemented. All the models and animations are tied to the “unarmed” weapon entity, not the player entity. In order to have the legs and the rest of the body, we would need to add the models and animations to the player entity and modify the source code to allow the body to be visible, kind of like how it's done here. I did initially try this method but realized that the existing model/animations are a bit of a mess and it would be a LOT of work to make it look good. Also, I chose to do it this way to allow the mod to be compatible with everything, since the script and def files for the "unarmed" entity aren’t modified by any FMs (as far as I know—I haven’t tested them all). I assumed that someone may have tweaked the player files for their FM, as those are far more relevant than the "unarmed" files (which are essentially blank in the vanilla game). If I had overwritten them, I’d risk breaking their mission. There has been some discussion in the forums about having full body awareness and there didn't seem to be a lot of interest in it. Plus, it could end up being immersion-breaking. Imagine standing on a small rope and then looking down, only to see your feet just kind of floating in midair.

You are assuming way too much, and you're creating artificial pressure. Nobody in the public forums knows whether TDM team even considered including this feature in TDM core, regardless of its completion state or quality. Obviously you have right to have a personal opinion on the modification itself (which I think is cool too). Sorry for the offtopic here Jivo, you're doing great, and don't let this little side note distract you from your work

@stgatilov Even better news! The following commit fixed this issue regardless of r_tonemapOnlyGame3d setting. r10930 | stgatilov | 2025-01-25 | 7 lines Clear background during main menu. This fixes the issue e.g. with AT1: Lucy and tonemap disabled. The briefing there does not use any backgrounds, and no-clear policy results in HOM-like effects. Originally reported here: https://forums.thedarkmod.com/index.php?/topic/22635-beta-testing-213/#findComment-499723

I'm sorry that I'm so late to the party. I wonder if it would be better to turn all font images into TGA to avoid recompression artefacts? The engine loads images as materials, so if we add a material file per every image file, we can as well do forceHighQuality for the fonts and avoid any compression artefacts completely. UPDATE: Actually, I guess compression artefacts is not a big problem here. The fonts necessarily have alpha channel, so they use DXT3 compression. It has DXT1 color blocks which are 100% lossless because the color is full white (at least I hope so), only alpha information is relevant for the fonts. Also DXT3 has 4-bit per-pixel alpha channel. Basically, the alpha channel is stored at 4-bit precision instead of 8-bit precision, thus offering 16 grades of opacity instead of 256 grades. Something tells me 16 grades is enough. Also, it is pretty obvious what exactly the compressor would do to the raw alpha we push into it: it will just round the value to the nearest 4-bit-representible value.

the softshader part is not strictly nessesary to port to GLSL as my renderer is a hybrid and even if it uses GLSL for interactions it can still load ARB material shaders, the damn thing is that the gamma code is not treated as such it is actually hacked into the ARB interaction shader so it wont work for that. TBH it looks quite messy for something as simple as gamma and there must be a better way ?.

Hi folks, and thanks so much to the devs & mappers for such a great game. After playing a bunch over Christmas week after many years gap, I got curious about how it all went together, and decided to learn by picking a challenge - specifically, when I looked at scripting, I wondered how hard it would be to add library calls, for functionality that would never be in core, in a not-completely-hacky-way. Attached is an example of a few rough scripts - one which runs a pluggable webserver, one which logs anything you pick up to a webpage, one which does text-to-speech and has a Phi2 LLM chatbot ("Borland, the angry archery instructor"). The last is gimmicky, and takes 20-90s to generate responses on my i7 CPU while TDM runs, but if you really wanted something like this, you could host it and just do API calls from the process. The Piper text-to-speech is much more potentially useful IMO. Thanks to snatcher whose Forward Lantern and Smart Objects mods helped me pull example scripts together. I had a few other ideas in mind, like custom AI path-finding algorithms that could not be fitted into scripts, math/data algorithms, statistical models, or video generation/processing, etc. but really interested if anyone has ideas for use-cases. TL;DR: the upshot was a proof-of-concept, where PK4s can load new DLLs at runtime, scripts can call them within and across PK4 using "header files", and TDM scripting was patched with some syntax to support discovery and making matching calls, with proper script-compile-time checking. Why? Mostly curiosity, but also because I wanted to see what would happen if scripts could use text-to-speech and dynamically-defined sound shaders. I also could see that simply hard-coding it into a fork would not be very constructive or enlightening, so tried to pick a paradigm that fits (mostly) with what is there. In short, I added a Library idClass (that definitely needs work) that will instantiate a child Library for each PK4-defined external lib, each holding an eventCallbacks function table of callbacks defined in the .so file. This almost follows the idClass::ProcessEventArgsPtr flow normally. As such, the so/DLL extensions mostly behave as sys event calls in scripting. Critically, while I have tried to limit function reference jumps and var copies to almost the same count as the comparable sys event calls, this is not intended for performance critical code - more things like text-to-speech that use third-party libraries and are slow enough to need their own (OS) thread. Why Rust? While I have coded for many years, I am not a gamedev or modder, so I am learning as I go on the subject in general - my assumption was that this is not already a supported approach due to stability and security. It seems clear that you could mod TDM in C++ by loading a DLL alongside and reaching into the vtable, and pulling strings, or do something like https://github.com/dhewm/dhewm3-sdk/ . However, while you can certainly kill a game with a script, it seems harder to compile something that will do bad things with pointers or accidentally shove a gigabyte of data into a string, corrupt disks, run bitcoin miners, etc. and if you want to do this in a modular way to load a bunch of such mods then that doesn't seem so great. So, I thought "what provides a lot of flexibility, but some protection against subtle memory bugs", and decided that a very basic Rust SDK would make it easy to define a library extension as something like: #[therustymod_lib(daemon=true)] mod mod_web_browser { use crate::http::launch; async fn __run() { print!("Launching rocket...\n"); launch().await } fn init_mod_web_browser() -> bool { log::add_to_log("init".to_string(), MODULE_NAME.to_string()).is_ok() } fn register_module(name: *const c_char, author: *const c_char, tags: *const c_char, link: *const c_char, description: *const c_char) -> c_int { ... and then Rust macros can handle mapping return types to ReturnFloat(...) calls, etc. at compile-time rather than having to add layers of function call indirection. Ironically, I did not take it as far as building in the unsafe wrapping/unwrapping of C/C++ types via the macro, so the addon-writer person then has to do write unsafe calls to take *const c_char to string and v.v.. However, once that's done, the events can then call out to methods on a singleton and do actual work in safe Rust. While these functions correspond to dynamically-generated TDM events, I do not let the idClass get explicitly leaked to Rust to avoid overexposing the C++ side, so they are class methods in the vtable only to fool the compiler and not break Callback.cpp. For the examples in Rust, I was moving fast to do a PoC, so they are not idiomatic Rust and there is little error handling, but like a script, when it fails, it fails explicitly, rather than (normally) in subtle user-defined C++ buffer overflow ways. Having an always-running async executor (tokio) lets actual computation get shipped off fast to a real system thread, and the TDM event calls return immediately, with the caller able to poll for results by calling a second Rust TDM event from an idThread. As an example of a (synchronous) Rust call in a script: extern mod_web_browser { void init_mod_web_browser(); boolean do_log_to_web_browser(int module_num, string log_line); int register_module(string name, string author, string tags, string link, string description); void register_page(int module_num, bytes page); void update_status(int module_num, string status_data); } void mod_grab_log_init() { boolean grabbed_check = false; entity grabbed_entity = $null_entity; float web_module_id = mod_web_browser::register_module( "mod_grab_log", "philtweir based on snatcher's work", "Event,Grab", "https://github.com/philtweir/therustymod/", "Logs to web every time the player grabs something." ); On the verifiability point, both as there are transpiled TDM headers and to mandate source code checkability, the SDK is AGPL. What state is it in? The code goes from early-stage but kinda (hopefully) logical - e.g. what's in my TDM fork - through to basic, what's in the SDK - through to rough - what's in the first couple examples - through to hacky - what's in the fun stretch-goal example, with an AI chatbot talking on a dynamically-loaded sound shader. (see below) The important bit is the first, the TDM approach, but I did not see much point in refining it too far without feedback or a proper demonstration of what this could enable. Note that the TDM approach does not assume Rust, I wanted that as a baseline neutral thing - it passes out a short set of allowed callbacks according to a .h file, so language than can produce dynamically-linkable objects should be able to hook in. What functionality would be essential but is missing? support for anything other than Linux x86 (but I use TDM's dlsym wrappers so should not be a huge issue, if the type sizes, etc. match up) ability to conditionally call an external library function (the dependencies can be loaded out of order and used from any script, but now every referenced callback needs to be in place with matching signatures by the time the main load sequence finishes or it will complain) packaging a .so+DLL into the PK4, with verification of source and checksum tidying up the Rust SDK to be less brittle and (optionally) transparently manage pre-Rustified input/output types some way of semantic-versioning the headers and (easily) maintaining backwards compatibility in the external libraries right now, a dedicated .script file has to be written to define the interface for each .so/DLL - this could be dynamic via an autogenerated SDK callback to avoid mistakes maintaining any non-disposable state in the library seems like an inherently bad idea, but perhaps Rust-side Save/Restore hooks any way to pass entities from a script, although I'm skeptical that this is desirable at all One of the most obvious architectural issues is that I added a bytes type (for uncopied char* pointers) in the scripting to be useful - not for the script to interact with directly but so, for instance, a lib can pass back a Decl definition (for example) that can be held in a variable until the script calls a subsequent (sys) event call to parse it straight from memory. That breaks a bunch of assumptions about event arguments, I think, and likely save/restore. Keen for suggestions - making indexed entries in a global event arg pointer lookup table, say, that the script can safely pass about? Adding CreateNewDeclFromMemory to the exposed ABI instead? While I know that there is no network play at the moment, I also saw somebody had experimented and did not want to make that harder, so also conscious that would need thought about. One maybe interesting idea for a two-player stealth mode could be a player-capturable companion to take across the map, like a capture-the-AI-flag, and pluggable libs might help with adding statistical models for logic and behaviour more easily than scripts, so I can see ways dynamic libraries and multiplayer would be complementary if the technical friction could be resolved. Why am I telling anybody? I know this would not remotely be mergeable, and everyone has bigger priorities, but I did wonder if the general direction was sensible. Then I thought, "hey, maybe I can get feedback from the core team if this concept is even desirable and, if so, see how long that journey would be". And here I am. [EDITED: for some reason I said "speech-to-text" instead of "text-to-speech" everywhere the first time, although tbh I thought both would be interesting]

Moved this topic from development forums, since it covers a potentially important behavior change in 2.13. Luckily, its important is countered by the rarity of such complicated materials. I hope that this change has not broken existing materials. And even if it had broken any, we will be able to fix them manually...

Detection of player, bodies, ropes, etc. by AI depends a lot on how well-lit the object is. The player case is the most important one. It uses its own system to compute lightgem value, which renders additional views on GPU. Even with many improvements over the years, this approach costs a lot in performance, so it cannot be used for all objects which AIs can see. That's why there is another system for computing light values for the other objects. Since the engine was closed source when TDM was originally created, this system is very approximate. It takes into account light intensity and size, but mostly ignores the other factors like shadows, light projection/falloff textures, light texture transforms, blinking lights, lights with some material stages disabled etc. A new light estimate system has been implemented, and it is going to be default in 2.13. In fact, it has already been default since dev17104-10844. As far as I know, it accurately takes into account all the properties that our lights have. It has its own issues of course. It relies on a few samples on the object surface, and it is rather performance-intensive because it casts shadow rays all other the world. I had to distribute its work over several frames to reduce performance cost, so now it takes some delay to compute the proper value (which can also cause problems sometimes). Here is how it works on a test map: What it means for us? On the good side, you should no longer have a problem when you put a corpse into a dark spot under a table but guards still detect it easily as if the table did not exist. On the bad side, the new light values are inherently different, so guards might detect objects in situations where they did not detect them before or vice versa. Also the delay can probably cause some issues e.g. guards acting upon an obsolete value which is updated just afterwards. The effort is tracked in 6546. There are several cvars about this: g_lightQuotientAlgo: value = 0 uses the old system, value = 1 uses the new system. g_showLIghtQuotient: enables debug visualization like in the video above. g_les*: lots of internal parameters to tweak the system (you should not mess with them).

And for some pointers, read the following topic: https://forums.thedarkmod.com/index.php?/topic/22533-tdm-for-diii4a-support-topic/

If OBJ works correctly in TDM, it should be a recommended format, at least over ASE. Even though both are text-based, OBJ is much more lean, and it compresses faster and better. This is a high-poly cube (24k polygons) saved and compressed in both formats: I haven't tested OBJ with 2.11 yet, but ASE has other downsides, like it has to be exported from a clean scene, and the scene material library can only have materials that are used for a particular model. OBJ should just use what's been assigned to it, and it should use model pivot point instead of world/scene origin point (0,0,0). If that's true, then exporting single models should be much easier now. You won't need a separate clean scene do do your exports.

Just need to say this This was not true at all for me, when I modeled for Doom 3 at lest, all my lwo models worked fine, including smoothing, thou I use Modo 601 that was the exact modeling tool Seneca a model artist from idSoftware used and I also used his custom Doom 3 exporter pluging for Modo that cleans up and prepares .lwo files to Doom 3 prior to exporting. This is what I do in Modo 601 to export clean lwo files, perhaps helps those using Blender as well. 1 - put model origin at world 0,0 and move model geometry if necessary so its origin is at the place you want, like the model base. 2 - (optional) clean geometry using some automatic system, if available, so your model doesn't export with bad data (like single vertices floating disconnected). 3 - bake all model transforms, so rotation, translation and scale are all put at clean defaults (that will respect any prior scaling and rotation you may have done) 4- (in modo smoothing works this way) go to the material section and if you want your model to be very smooth (like a pipe for example) set material smoothing to 180%, you can set smoothing per material. If you want more smoothing control, you can literally cut and paste the faces/quads and you will create smoothing "groups" or islands that way. 5 - use or select a single model layer and export that (the engine only cares for a single lwo layer) if you want a shadow mesh and collision mesh as well, put them all on the same layer as the main model. 6 - never forget to triangulate model before export (Seneca plugin did that for me automatically) I did this and all my models exported fine and worked well ingame. Thou .lwo was invented by lightwave and Modo was developed by former lightwave engineers/programmers, so perhaps their lwo exporter is/was well optimized/done compared to other 3D tools.

Here is what I know: static models: LWO: somewhat default small uncompressed size since it is binary loading code is horrible, can be slow and break your model (smoothing groups might be pain) ASE: larger uncompressed size since it is text (compressed size is probably OK?) loading code is as awful as for LWO OBJ: the only format added specifically for TDM, so not very widespread uncompressed size is large because it is text (compressed size is probably OK?) loading is very fast and does not "fix"/break your model, you'll get exactly the topology & smoothing you exported ragdolls: The only format is .af text format, which is handmade for Doom 3. No changes here since Doom 3. It is notoriously hard to create/edit. The only tool is the Windows-only builtin command editAFs, and this is the only in-game editor which has no outside alternatives. We wanted to port it to either DarkRadiant or at least better GUI framework, but it did not happen. animation: MD5: md5mesh --- Doom 3 custom text format which represents a mesh attached to skeleton (joints, weights, etc.) md5anim --- custom text format that represents an animation of a skeleton. I'm pretty sure Blender has some working exporter for these. MD3: This is Doom 3 custom text format which represents linear vertex morphing. It is rarely used, but it is a perfect fit in case animation is clearly not "skeletal" (e.g. animated grass or water). I suppose some converters can be found?... Ask @Arcturus, he used it. Also there are some hardcoded pieces of code which transform a mesh into something else, that are enabled via "deform" keyword in material. The most known example is particles. All of this is very specific and uses custom formats. There is also MA loader (Maya ascii format?), but it is not used an I have no idea how functional it is. Also there is FLT model, but no idea what it is. video: The mainstream idea is to use (mp4 + h264 + aac) for FMV. There is also legacy support for ROQ, but I guess you should not use it today. I think all the other formats are disabled in FFmpeg build that we use. There is no common understanding about in-game videos, I'm not even sure it is a useful case. One specific case is animated textures (e.g. water), and they are usually implemented as a pack of copy/pasted if-s in material file, which point to different frame images. Something like "Motion JPEG/TGA/PNG/DDS" Maybe one day we will make this approach easier to use... textures and images: TGA: The simplest uncompressed format, basically default in case compression is not used. PNG: Lossless compression, but pretty slow to load. Should be OK for some GUI images, but probably not a good idea to e.g. write all normal maps as PNGs: I imagine loading times will increase noticeably if we do so JPG: Lossy format, but pretty small and rather fast to load. I think it is usually used for screenshots and maybe GUI images, otherwise not popular. DDS: This is container which can in principle store both compressed and uncompressed data, but I think we use it only for precompressed textures. TDM supports DXT1, DXT3, DXT5, RGTC compressed formats (each of these formats has a bunch of pseudonymes). If you use compressed DDS, then you can be sure it will be displayed as is, as no further processing it applied to it. Sometimes it is good, sometimes it is bad. The engine has fast compressor/decompressed for all texture compression formats, so if you supply TGAs and they are compressed on load, you only lose in mission size. Images inside guis (briefing, readables) use the same material loading system, so they should support all the same image formats. sound files: OGG: Relatively widespread open format with lossy compression. I guess it is used for everything by default, which seems OK to me. OGG files are loaded on level start, but decompressed on the fly. WAV: Simple uncompressed sound file. Obviously larger than OGG, not sure why it is used sometimes (maybe less compression artifacts?) The only thing I know is that the "shakes" feature of materials specifically asks for WAV.

Changelog of 2.13 development: beta213-05 (rev 17312-10946) * Removed back menuLastGameFrame feature because of random texture popup (post). * Console font minor tweak to avoid artifact under P. * Minor fix for Catalan language. beta213-04 (rev 17306-10940) * Fixed bug with compass + X-ray glasses combination. * Fixed two buttons displayed in menu objectives during game (post). * Added new smoking animation. * Added menuLastGameFrame image to show game footage in in-game main menu (6608). * Changed install/uninstall mission to select/deselect in main menu. * Fixed editor images for HD carpets (6607). * More fixes for Catalan language. beta213-03 (rev 17294-10935) * Fixed crash in WS3 due to script name collision in invisibility potion. * Added praying animation. * Fixed heat-haze shaders with nontrivial Render Scale. * Restored back tonemapping in the menus. * Allow settings hotkeys for gasmine, slowfall, invisibility, made strings translatable. * Fixed double-cursor in game console on 1920x1080 (post). * Applied noise reduction to new vocals for drunk "jack" AI. * Added support for Catalan language. * Fixed UV maps on stove models (6312). beta213-02 (rev 17281-10932) * Fixed HOM-like artifacts in AT1 Lucy and trash frames on TDM start on Linux (post, post). * Disabled tonemap compression curve and reverted settings to 2.12 defaults (post). * Added menu options to disable volumetric lights and parallax mapping. * Fixed varioius issues with largesquare01 materials (6579). * Fixed several issues in the new parallax materials (6604). * Deleted plain_redgreen_design_HD material which references non-existent textures (6601). * Some main menu buttons during game start replaced with generic "Next" (post). * Climbing sounds now depend on material (4991). * Added shaded_lamp_with_grill model (6589). * New fabric_ornate and fabric_fleur materials. beta213-01 (rev 17262-10927) * Improving the fonts continued (thread). * Fixed unwanted mine deployment when player eats the last bit of food in hands (6598). * Removed old hack to fix for scripted savegame crash (4967). * Added a model ext_timber01_window01_empty.lwo (6600). * Fixed missing skin for atdm:ai_revenant_spirit (6595). dev17251-10920 * Added slowfall potion. * Added invisibility potion. * New tonemap settings are now default (post). * Added Texture Quality settings in the main menu. * Added pipes_industrial_modular models. * Minor adjustments to colored versions of gen3 environment maps. * Default value of inv_count is back at 1 to fix issues with inventory counts. * Fixed rare crash on loading collision models (post). * Refactored heatHaze shaders. dev17234-10914 * Added many new high-res materials, half of them with parallax mapping. * Implemented optional HDR compression in tonemapping + other improvements (post). * Implemented interactionSeparator syntax in materials (post). * Added new entityDef: atdm:radio. * Added colored versions of gen3 environment cubemaps for metallic materials. * Added new environment cubemaps: sparkles, studio, blurry. * Added coat_commoner_hanging and coat_inventor_hanging models. * Added mantle_clock_ticking sound. * Improved lightgem calculations while leaning (post). * Fixed regression with double-sided materials (5862). * New sorting of inventory grid items (6592). * Reduced font size of mission list, which allows to see more missions and longer names (post). * Added scrollbar to "notes" of a mission in the main menu. * Optimization: don't render interaction groups with black diffuse & specular. * Improved "scepter" material (thread). * Fixed normal map of ornament_relief_mold_eaglelshield (6585). * More tweaks to starry2 materials. * Made material noshadows: moon_full_shaded, shooting_star, moon_glow. * Added "inv_count" "1" spawnarg to atdm:playertool. * Gas mine now costs 125 instead of 75. * Added min/max builtin functions to game scripts. * Added script events about gravity, health, in-air movement. * Added script events setUserBy, setFrobActionScript. dev17171-10894 * Added entityDef archery_target01 with hit detection, it is now used in Training Mission. * Fixed missing steam_pipe02_straight in Training Mission. * Hiding mouse cursor during briefing in official missions (6576). * Cleaned up the code for extracting interaction groups in material. * Parallax mapping: supported "translate", self-shadows are disabled properly (6571). * Fixed meshes generator_big, generator_small, generator2, warehouse_front_doorframe (6581). * Fixed material on model stove_open02 (6580). * Fixed decals on ext_timber01_window01 (5782). * Improved largesquare01 materials with bumpmap and specular (6579). * Added skybox materials clouds3 and clouds_4_small + prefabs. dev17152-10890 * Major update of Training Mission, including vine arrows (4352). * Added TDM version + engine revision in lower-left corner of main menu. * Experimental implementation of parallax mapping (6571). * Fixed frob interaction with candle holder that's initially extinguished (6577). * Better icons for scrollbar thumb in menu, fixed author search (6339 6570 6449). * Fixed hiding mouse cursor during video briefing/debriefing (6576). * Fixed map immobilization not applied if opening map with inv use key. * Forbid adding missions to download when download is in progress (6368). * Skip disabled bump stages in environment mapping (6572). * Disabled texture compression for light images: falloff and IBL cubemaps. * Minor change in shadow map acne / blur radius computation (6571). * Added banner01_edgar and banner01_viktor banners, along with long versions. * Fixed UV map for longbanner_ragged model (6573). * Added missing jack/drunk_idle13.ogg sample (6507). * Fixed handle_curved02_latch prefab, deleted pull_handle (6286). * Replaced normal map of cobblestone_blue_black with high-res version (6574). * More detailed editor images of some materials (6575). * Added small_dresser_openable prefab. * Added banner_sword + tdm_bannerlong_sword materials. * Increased size of secret message overlay GUI. dev17121-10869 * Massive improvements in mission select & download menus, added search (6339 6570 6449). * Improvements and fixes for "builder priest" animated mesh. * Improvements of idle01 animation. * Improved newspaper01 model (6568). * Added gas mine to "map start pack" prefabs (6559). * Fixed text alignment in save/load menus. * Minor CI/build fixes. dev17104-10844 * Enabled the new system for tracking light value by default (6546). * New light value tracking integration covers ropes and doors + optimized shadow rays (6546). * Added atdm:playertools_gasmine (6559). * Workaround for compiler bug which broke particle collisions with texture layout (post). * Fixed r_showTris: color, values 2 and 3 (6560). * Minor improvements to drunk vocals (6507). * More tweaks to sculpted/girard_relief_pho. dev17095-10833 * Major improvements in drunk AIs: setting "drunk" spawnarg is enough now; new sounds, animation improvements, greetings, etc. (6507). Fixed drunk women AI (5047). * Incorporated stone font updates by Geep (thread). * New footstep sounds for ice and broken glass (6551). * Fixed light culling bug on elongated models with non-identity rotation (6557). * Added new system for tracking light value of entities (6546). It is disabled yet. * Technical change in loading of particle collisions (6546). * Now AI follower settings can be set as spawnargs, added prefab (6552). * Added proper dmap error message if map file contains an entity before worldspawn. * Fixed water_medium_running sound (5384). * Fixed window/metal_irregularpanes_moonlit material. * Fixed wood/boards/rough_boards_scratched (4157). * Fixed wall/ship_wheel model (6549). * Fixed gaps in awning_cloth_01_large model (6550). * Added weather particles with static collisions enabled (6545). * Added a pack of new factory_machines models (6537). * Added fabric/cloth_baize materials (red and purple). * Added window/diamond_pattern01_moonlit_bright material (6133). * Added AO and specular maps to sculpted/girard_relief material. * Added musicbox sound, added prefabs for it and for victrola. * Added wood/panels/mary_panel model. * DarkRadiant now knows about parallelSky param (6496). dev17056-10800 * Supported "efx_preset" spawnarg on location entities (6273, thread). * Fixed rendering of volumetric light and particles in X-ray views (6538). * Fixed rendering of particles in mirrors (6538). * Improved volume estimation for subtitles, very quiet subtitles are hidden (6491). * Fixed bug in idClip::Translation of non-centered models. * Third-party integration greatly reworked for better integration with conan (6253). * Stone/subtitle font improvements by Geep. * Fixed sleeping sounds for drunk AIs (6539), and other sounds for them too (6507). * Fixed missing shadow on endtable_001 model (6288). * Added girard_relief material. Known issues: * Shadows of Northdale Act 1 does not start (6509). (mission has been updated) dev17044-10746 * Supported mission overrides for cvars which are tied to gameplay state (5453). * Fixed crash on start with 32-bit Windows build. * Rebuilt all third-party libraries with conan 2 system (6253). * Reverted improvements of capped FPS to fix video/audio desync (5575). dev17042-10732 * Restored ability to create cvars dynamically, fixing bow in missions (5600). * Fixed issue where .cfg files were saved every frame (5600). * Added sys.getcvarf script event for getting float value of cvar (6530). * Extracted most of constants from weapon scripts into cvars (6530). dev17035-10724 * Support passing information between game and briefing/debriefing GUI via persistent info. Also changed start map & location selection, added on_mission_complete script callback (6509 thread). * New bumpmapped environment mapping is now default (6354). * New behavior of zero sound spawnarg is now default (6346). * Added sound for "charge post" model (6527). * Major refactoring of cvars system to simplify future changes (5600). Known issues: * Bow does not shoot in some missions: thread (only in this dev build) dev17026-10712 * Nested subviews (mirrors, remotes, sky, etc.) now work properly (6434). * Added GUI debriefing state on mission success (6509 thread). * Sound argument override with zero now works properly under cvar (6346 thread). * Environment mapping is same on bumpy and non-bumpy surfaces under cvar (6354 thread). * Default console font size reduced to 5, added lower bound depending on resolution. * Added high-quality versions of panel_carved_rectangles (6515). * Added proper normal map for stainglass_saint_03 (6521). * Fixed DestroyDelay warning when closing objectives. * Fixed the only remaining non-threadsafe cvar (5600). * Minor optimization of depth shader. * Added cm_allocator debug cvar (6505). * Fixed r_lockView when compass is enabled. dev17008-10685 * Enabled shadow features specific to maps implementation (poll). * Auto-detect number of parallel threads to use in jobs system (6503). * Improved parallel images loading, parallelized sounds loading, optimized EAS (6503). * Major improvements in mission loading progress bar (6503). * Core missions are now stored uncompressed in assets SVN (6498). * Deleted a lot of old rendering code under useNewRenderPasses + some cleanup (6271). dev16996-10665 * Environment mapping supports texcoord transforms on bumpmap (6500). * Fully disabled shadows on translucent objects (6490). * Fixed dmap making almost axis-aligned visportals buggy (6480). * com_maxFps no longer quantizes by milliseconds on Windows 8+. * Now Uncapped FPS and Vsync are ON by default. * Supported Vsync control on Linux. * Added set of prototype materials (thread). * Fixes to Stone font to remove stray pixels (post). * Loot candlestick no longer toggle the candle when taken. * Optimized volumetric lights and shadows in the new Training Mission (4352). * Fixed frob_light_holder_toggle_light on entities with both skin_lit and skin_unlit. * Now combination lock supports non-door entities by activating them. * Added low-poly version of hedge model (6481). * Added tiling version of distant_cityscape_01 texture (6487). * Added missing editor image for geometric02_red_end_HD (6492). * Added building_facades/city_district decal material. * Fixed rendering with "r_useScissor 0" (6349). * Added r_lockView debug rendering cvar (thread). * Fixed regression in polygon trace model (5887). * Added a set of lampion light entityDefs.

BEHAVIOR CHANGES: g_lightQuotientAlgo --- which light estimate system is used by AI (0 = old system). g_showLightQuotient and g_les* --- can be used for debugging of the new system. r_envmapBumpyBehavior --- selects visual behavior of bumpmapped environment mapping (0 for the old behavior, 1 for the new one). s_overrideParmsMode --- selects the behavior of zero value in sound emitter parameters (0 for the old behavior, 1 for the new one). r_materialNewParse --- how are material stages grouped into interaction groups (0 for the old behavior, 1 for the new one). r_shadowMapAlphaTested, r_shadowMapOnTranslucent --- enable some shadow effects which can only be implemented with shadow maps, and don't work with stencil shadows. See also this post. TROUBLESHOOTING: r_lockView --- a debug cvar which freezes culling, so you can fly around and see what is rendered in the frozen frame (thread). r_subviewMaxDepth --- limit on depth of nested subviews. Worth trying to lower this if performance is suddenly awful. dmap_outputNoSnap --- control flag for the latest fix in dmap. Ideally, you never need to change it, unless you try to understand why dmap works differently in 2.13. r_skipEntities, r_skipParallax --- new debug cvars, might be useful to detect performance issues. s_levelLoadParallel 0 --- disables parallel loading of sound samples. jobs_numThreadsRealtime, jobs_numThreadsNonInteractive, jobs_maxHddThreads --- various cvars to tweak parallelism across threads/cores, mainly affects level loading. OTHER: r_postprocess_compress --- controls the new compression curve for overbright colors in tonemapping. r_postprocess_compress*, r_postprocess_overbright_desaturation, r_postprocess_desaturation --- tweak the specifics of this addition. Please read this post! r_tonemapOnlyGame3d 1 --- tonemapping is disabled outside 3D game (e.g. in main menus). tdm_subtitles_volume* --- how volume of played sound is converted to opacity of the location ring on subtitles. CMDS: printPersistentInfo --- debug command that prints "persistent args" to game console. These arguments are used to pass information between missions in a campaign. setm/unsetm --- commands that set mission override value for a cvar, equivalent to setting cvar value from game script.

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.

The simple "TLDR" version: 1) Obtain or create a skybox cubemap https://wiki.thedarkmod.com/index.php?title=Category:Skybox 2) Use a 3rd party tool to convert it to an irradiance cubemap 3) Create a material def that uses the irradiance cubemap https://wiki.thedarkmod.com/index.php?title=Light_Properties#lightAmbientDiffuse_and_lightAmbientSpecular_(_Previously_ambientCubicLight_) 4) If you want interior cubemap ambient lighting, use envshot to capture an in-game cubemap of the location ( at the spot where you intent to place the light-center of the ambient light ) then perform steps 2 and 3 on the envshot images.

This is a topic about using the ambient cubemap: I think the instinct to suggest ambient cubemap lighting is because your church has unreadable geometry due to the flat ambient lighting and same texture all over it. Other than ambient cubemaps, you can ( in order of least to most difficult 1) Enable SSAO and increase your SSAO radius ( r_ssao_radius 128 , etc) 2) Place dim lights around the church to emphasize contours ( this is typically called "bounce lights" and you use the ai_see 0 entity arg to prevent the light from impacting the lightgem ) 3) Simulate AO via grime decals 4) Re-texture parts of the church with textures that are similar but have different shades to simulate some directional lighting 5) Export the church to Blender and bake lighting to a texture in Blender then export the baked lighting as a model with a blend filter decal material to overlay the church 6) Use the "Strombine" lighting technique: http://lunaran.com/maps/quake4/strombine/

A "stage keyword" converts the image to a normalmap. Material defs can have multiple normalmaps but the order impacts whether they are visible or not. You can also use the addnormals keyword to blend a Doom 3 heightmap with a Normal map Both heightmaps use grayscale images to represent height.

All is working and has a basic directory and save system, with automatic scaling to the recommended dimenstions (upper left) and can be used just to make the maps for input images (to the right from the directory and name, the red lines indicate how the reference image stays as it is), or have the inputted image as a reference for the AI to work from. I tried to make it as simple as possible where things can be bypassed (like maps and saves) and a lot of nodes are hidden under other nodes, and nodes are pinned so you can't drag them around without unpinning them. Next step: getting it all ready and packed for download and install so ppl can use it .. and some sort of manual I guess : P @nbohr1more I see the texture guidlines were updated! But now I wonder about the recommended dimension or the heightmap?

It was my fault at the very beginning but later I started following these guidelines: Precaching (def files). When I debug my mods (decl_show 1) I notice nothing unusual except for the images: parsing material path/to/image Trying to load image path/to/image from frontend, deferring... 0x0 path/to/image Whatever it is, when image X is required by the game for the first time it can cause a stutter. I say "can" because sometimes the stutter happens and sometime it doesn't OR sometimes I notice it and sometimes I don't.

This was a great excuse to play this mission again. Its still amazing even after all these years. The EFX changes sound pretty good, however, I agree with @SeriousToni. @datiswousCAVE should be replaced with either STONEROOM or CASTLE_LARGEROOM. I find that castle sounds pretty good for large echo chambers. For future reference. the EFXs with prefixes sound the best (CASTLE_ , FACTORY_, ect). The ones above that have some weird effects, but are pretty specific and some just sound wrong.

Thanx, in the Texture guidlines I read normalmaps should be TGA (uncompressed, no RLE) and I can't find any "node" for comfyUI that can save to TGA .. but I have a node that can save to DDS (bc1, bc3 or bc5) with mipmaps. Thing is that this node also creates a json with it. There is an other node that saves in DDS that it has no settings but doesn't create an other file with it. If this node puts out bc5/dxt5 with mipmapping, would it be acceptable to save diffuse, normal, specular and height with it? The other thing is, since it can't save in TGA, what fileformat would be preferable for the highres backups? I'm now making a automated save structure for the different maps where project name, material type, optional sub type and material name can be set globally and it will save in projectname/(dds)/textures/materialtype/(subtype)/materialname The materialname wil be assigned the appropriate postfix; _local,_s,_h,_ed. I think the folder HighRes will be in in projectname/textures/materialtype/(subtype)/HighRes. Or would there be a better directory for that? The maps will be downsized to the apropriate max resolution before saving, but ofc. the high(er) resolution images won't be downsized. It's quite a puzzel, but it should all work in the end : )

Pff .. now I have to try and implement this I guess: https://www.reddit.com/r/comfyui/comments/1blhkk6/comfyuitexturesimple/ https://github.com/gokayfem/ComfyUI-Texture-Simple I want to finally get a good save name and save path structure where the material class name can be set to have the output saved in a folder with that material class name. And the material name that will be set to all outputted files like: name_diffuse, name_normal, name_specular, name_height, name_editor ( or however these are called in TDM / however the general syntax for texture files is?). When that all works, I like to simplify the whole UI as far as possible and have toggle buttons for creating and saving the maps, so you can only generate a (diffuse) image till you have something you like.

I guess if these are mission specific textures, you could use material keywords to do the inversions: { blend bumpmap map scale( invertColor( /path/to/bumpmap ), 1, 1, 0, 1) } invertcolor does all RGB, the scale reverts blue