Search the Community

Just realized a flaw in my proposal: Each probes view range can't be just its distance from the neighboring probe, as that distance will also be the maximum distance of the reflection itself. At a grid size of 64 for instance, a probe in front of a wall would only reflect at most 64 units behind that wall. So reflection distance should be minimum the grid distance doubled to avoid gaps, but also higher if you want your reflection to fade further. This would mean some bad news for performance unfortunately. An similar yet different alternative would be for each point to capture and retain a single color, acting as a 3D pixel / point of light altogether. This would automatically emanate light and show up in specular channel without requiring material changes, tackling both GI and reflectivity at once... the grid size would be the resolution of the result in this case. But now we run into the issue that points behind the player need to be updated... in this case it would be best to calculate and remember all voxels inside a room the moment its portal is opened, only updating ones within radius of a light or object when there's movement near it.

Last night we chatted on Discord about Vulkan support and PBR, bringing up a system for adding proper reflections once more. I suggested screenspace reflections but it was argued reflection probes would still be better than SSR in our case, a ticket for that is already open but I'm uncertain whether it's the best way: A manual approach would need new entities to be placed by the mapper... this requires extra effort and would exclude old FM's that are no longer updated, while the result will also be inaccurate and static meaning you won't see an AI reflected as they walk on a shiny metal plate for instance. If PBR with realistic graphics can be a hope for 2.12 or later, we'll definitely want to do it right rather than using a limited / limiting system. A technique came to mind that might just work for our engine and setup. I wanted to share it here before I forget the specifics; This might already be a common practice and even have a definition, for the purpose of this thread I'll just describe it as I originally imagined it and feel this would work for our engine. The idea is we'd use reflection probes but in an automated fashion: A probe is automatically spawned in every valid area (within bounds) in the player's view, at a given grid unit size. For example: If the grid scale is 16, a probe may exist at position '0 -48 16' another at ''0 -48 32' and so on. Every point projects its result on all surfaces in its radius which contain a specular channel masking it, the best alternative presently available till we were to convert all textures for PBR support. The cool thing is the same cubemap can also be projected as a light source, allow for global illumination in addition to just reflections! This would be similar to how the Irradiance Volume works in Blender / Eevee except each dot renders a little cubemap from its perspective. I already know what everyone is rightfully thinking: This is going to kill performance! After all each probe needs to produce a render from its perspective, and being a 360* panorama it will open portals in all directions. Normally that would be insane, but I thought of various ways in which the impact could be greatly minimized to very bearable amounts. The frame buffer of each probe will be at a very small resolution by default since much detail shouldn't be needed. Even 64x64 per cube face might do. Each probe only needs a draw distance double its grid size, given it only has to see as much as is necessary to fill the gaps between it and its neighbors. So if the grid size is set to 64, each probe would only have a draw distance of 128 to cover the space in between its neighbors, nothing beyond that would exist to it. Only probes the player can see would ever be spawned and calculated; If the view frustum doesn't overlap the virtual cube who's corners touch that probe's neighbors, the probe is dropped from memory. Probes are also only spawned in a valid visible space, never out of bounds including rooms culled by portals. A draw distance after which probes are removed or not spawned can also be included. This would further help by making any probe further than X distance be ignored, slowly fading away as to not noticeably pop in and out of existence. Reflections / GI are a discrete effect you'll only see up close. Similar to lights and shadows, the result of a probe should be cached and not calculated unless necessary. This means that unless something moves within radius of that probe its cubemap won't be rendered again. Probes would only be updated either when they first come into the player's view, or if something touching their cube has moved. Note that particles and lights with animated textures would have to count as you may see them in a detailed reflection, candles and torches would force constant updates per-frame for probes they intersect. If with all that performance is still affected, frame skipping is also a solution: Reflection probes can update at a lower frame rate to further decrease their impact. If you have a 60 Hz monitor and are running TDM at 60 FPS max, reflections could run at 30 / 20 / 10 FPS without looking out of place. They could in fact be defined as a fraction of your average framerate, so for the FPS you get you can decide whether it's going to be 1/2 or 1/4 or so on of that... this would have the added advantage of exponentially gaining back FPS the lower your FPS goes. There are several reasons why I believe this would be better than mappers manually placing new probe entities: Extra work is required for the mapper, who needs to figure out how to cover each area in probe lights. Every piece of the map would need to be encompassed in a reflection / GI probe otherwise you won't get shiny surfaces or bounce lighting which will look out of place. Most existing FM's will never be updated to use this: Only maps created or updated after the feature is introduced would benefit, anyone playing old missions will get boring visuals without reflections / GI which will be inconsistent to new ones. I strongly believe this should be done as an universal effect like SSAO. Single large probes will produce inaccurate results; The larger a cubemap is, the more drift and a fake results you get with distance from its center. This can be mitigated by using parallax corrected cubemaps which should be used for automated cubemaps too... none the less you get a single point of vision for a large room which makes the result inaccurate the further you go... with an automated approach you could have many probes in a dense grid (if your hardware allows it) for a much more accurate result at any position and angle. What are your thoughts on this solution, do you think it's realistic and can work out? I do believe it should be either this or screenspace reflections the way they're done in Godot or Blender / Eevee. If SSR isn't the right choice for our engine, reflections and global illumination alike could be captured using a global grid of capture points shining within their respective areas.

There are other complications though. How much fall damage should player take, if they decide to jump off a rope with the body? Should the player let go of the body or not? Also, right now it's much harder to jump off the rope with the body than without it. Why? And last but not least, how would you teach players these things, possibly without much hand-holding and text prompts explaining the rules? I guess I'm with @STiFUon this one, if you restrict dropping the body, you'll save yourself (and mappers) a lot of headaches. But even that doesn't solve all the problems, I know I'm in the minority in these forums, but as a player, I really appreciate the beauty and efficiency in simplicity of the design. Not overthinking everything and adding more and more rules for the sake of realism (or anything else).

I think the reason the dev forums exist is to provide a place where the implementation of features can be discussed without getting mixed up with other debates when someone believes what the devs are doing is wrong. We often post public discussion threads for features with subjective elements like the frob outline, because community feedback is very important. But there will always be vocal defenders with strong views for or against certain features, or how exactly it should be implemented in their opinion. At some point a decision has to be made and be carried through, which is what the dev forums are for. Almost all of the threads are very technical, basically explaining and discussing recent or potential code changes with other devs. Its hard to say. Its a hobby the devs do in their spare time, so people come and go when they're in the mood and when they have the time. The team page is mostly accurate except for some relatively newer additions like myself.

This is basically "do include my work ASAP because I worked so hard, or else *sulk*". This is similar case: https://forums.thedarkmod.com/index.php?/topic/21679-beta-testing-211/page/10/#comment-482352 This is neither a commercial product, nor a phishing email. That sense of rush and pressure is artificial. These releases typically do take long, and even then, there are often many things broken by mistake or omission. Often there aren't enough people to test stuff, or they're not competent enough, etc, etc. There's little point in hurry.

Looking at the source code and the core pk4 asset files, I don't see any changes that would make a difference. Does this happen with a single FM? Does the FM pk4 file include an "autoexec.cfg" file? From the source code, here's the load order of config files. exec default.cfg exec Darkmod.cfg exec DarkmodKeyboard.cfg exec DarkmodPadbinds.cfg ==> exec autoexec.cfg <load language> <exec command-line arguments> <init input> <init sound> <init OpenGL> <init ui> <load DLL> <init session> ==> exec autocommands.cfg Details about the addition of "autocommands.cfg" are at https://bugs.thedarkmod.com/view.php?id=3199 I thought "autocommands.cfg" was the right way to do it, because that is what I've read on the forums. It seems that "autocommands.cfg" was originally designed for one use case: running "dmap". However, maybe over time "autocommands.cfg" became the de facto config file for user commands and "autoexec.cfg" became the config file for FM authors to use. I don't know. Does anyone know for a fact whether or not this is the case?

Still very relevant since a solution to our lack of reflections hasn't been found, this is the type of thread revival I find most welcome. We've been talking about PBR (whether in general or for TDM) and I've been intrigued on whether we can get proper reflections using the specular maps of textures as (reverse) roughness. With the release of 2.11 not far away I've been wanting to hope some sort of solution might make it in time even if that seems unlikely. https://bugs.thedarkmod.com/view.php?id=5239 There's currently an open ticket on implementing light probes that can automatically capture a cubemap from a given position. The technique used here would definitely come in handy for such a thing! An issue with those is mappers would need to add them manually: I'd really prefer an universal solution like SSR so it can work on all FM's without requiring the mapper to enable it, same way SSAO came as an universal improvement. Thus my first idea was rendering a realtime cubemap from the player's POV each frame or every X frames... that would brutalize performance however, especially as it would open all portals around the player to capture a 360* panorama (goodbye view culling). Also it's worth remembering we're dealing with two independent yet interconnected issues here: Ambient lighting and reflection. Ideally a single solution can tackle both, lighting walls with the ambiance of the room as well as showing the reflected view that moves around with the camera. If we were to do it right maybe we could use a smart cubemap to achieve bounce lighting / realtime irradiance... I'm probably going so far off there, still who knows

It's alright, and that is normal: You won't see a huge difference on everything, just a few surfaces typically smooth metal and stone. The goal of the experiment was to see how close I could get to realistic reflections that would match what you get from a PBR engine... obviously this has nothing to do with PBR itself, just a comparison to its feel. Like in real life only some surfaces will produce reflections: You won't see sharp reflection on your walls for instance, but will see a light one on your door knob. The trick in my approach is only those materials with a specular map are given a cubemap reflection, the reflection is masked by the specular map and works as a supplement to it; This ensures every material is only as shiny as intended by the texture pack, which makes the effect barely noticeable on surfaces with low specularity. Making everything shiny could have looked prettier in the moment but would be fake and unrealistic. Also worth noting: There are three default /env/gen# cubemaps. gen1 is very low intensity (almost unnoticeable), gen2 is the strongest (makes everything bright), gen3 is somewhere in the middle (looks best so I used it). You can change the script to gen2 but apart from making the universal cubemap too obvious it might make everything too bright by default. I prefer Python myself, Bash is weird and uses strange syntax. It's what Linux has by default so I got used to thinking it's best for stuff like editing files, especially as I also need to zip / unzip archives. Something like this is easy to do though, if there was real need it could be easily redone in Python or Lua or NodeJS. That would be ideal and what I wanted, either something like this with light probes or actual SSR (screen space reflections). Unfortunately it's not currently possible with existing capabilities: I spent the first day trying to trick the material into using the _currentRender or _scratch pass to fake reflections, obviously it won't work. My approach is admittedly meant to be a crutch till we have that, for those of us who prefer seeing some kind of shine rather than just the boring specular reflections... both approaches are ugly and unrealistic but at the moment it's a pick between which is the least ugly.

I recently saw discussion about PBR materials being added to Doom3BFG with folks also talking about it on Discord. One of the things I always wanted from PBR is proper reflections, especially in a way that works on all FM's new and old without requiring changes (eg: new light entities). Lack of proper reflections is one of the biggest limitations we still have, leaving us with mere boring specular reflections lacking any detail. While currently we can't have things like metallicity or per-pixel roughness, not even the ability to use the skybox or player camera feed as a reflection map, we do have a generic cubemap used only on windows and a few special textures. So the thought itched me: What if we could make every material with a specular map also blend a cubemap reflection? I've done Linux batch scripts for complex tasks before, so after lots of searching (and dealing with DOS era line terminations getting in the way) I managed to create a bash script that will do just that! This 50 line script will detect all materials with a specular map, inject a customized cubemap reflection, then repack everything. It scans every material in TDM thus it changes all map textures models and entities alike, everything gets modified to benefit from this. Modifications are NOT made to the official pk4 files, instead a single pk4 named Z-tdm_materials_cubemap.pk4 is generated to override the old defs, you can revert at any time simply by removing this one file. The cubemaps are subtly blended in without using extra vertex / fragment shaders which should have minimal performance impact, they also respect the bump map of the material and are deformed by it... each cubemap is masked by the specular map which gives it a close feel to PBR, materials without a specularity texture are considered rough and remain unchanged. Simply download the script and use it in your TDM folder, you'll need either Linux or a bash environment on Windows (untested): material_cubemaps.sh #!/bin/bash # Add cubemap reflections to all TheDarkMod materials containing specular maps # Use sub(/\r$/,"") to fix DOS line termination, https://stackoverflow.com/questions/45772525/why-does-my-tool-output-overwrite-itself-and-how-do-i-fix-it # Unpack all materials mkdir "temp" for f in *.pk4; do unzip -o $f "materials/*" -d "temp" done mv "temp/materials" "temp/mtr" mkdir "temp/materials" cd "temp/mtr" # Inject cubemap code into all materials with specular maps, the reflection is masked by specular intensity # First ensure the file contains at least one definition that need to be modified to avoid needless repacking for f in *.mtr; do awk '{ sub(/\r$/,"") if($1 == "specularmap" && $2 != "_black" && $2 != "") exit !f }' "$f" if [ $? == 1 ]; then awk '{ sub(/\r$/,"") print $0 if($1 == "specularmap" && $2 != "_black" && $2 != "") { print "" print " // Cubemap reflection for specularity" print " {" print " maskcolor" print " map makealpha(" $2 ")" print " }" print " {" print " blend gl_dst_alpha, gl_one" print " maskalpha" print " cubeMap env/gen3" print " texgen reflect" print " }" } }' "$f" > "../materials/$f" fi done # Pack modified materials cd ".." zip -r "../Z-tdm_materials_cubemap.pk4" "materials" rm -r "../temp" At the moment I haven't done a full comparison and only tried it out on a map I'm working on: It's possible I might do my next TDM stream with this on which will allow others to see it better. From what I'm noticing it's pretty much perfect: Very subtle and doesn't disrupt visually, it does improve realism in a lot of cases as you move around and see the shine... given the texture is almost always masked and distorted by bump you don't feel the reflection is ugly and fake but it feels natural. Currently this is here as a mod for players that wish to use it... not gonna lie part of me is tempted to suggest it be considered for 2.11, it's definitely an improvement to having no reflections at all until a better method is found. Please try it out and share your own thoughts and images, below are a few screenshots I took during my first test to confirm it works as expected.

So I think we can count 12 or 14 missions depending on our opinion of La Banque Bienveillante and Sneak and Destroy. If these two reissues are counted as new missions (as JarlFrank did here: https://www.ttlg.com/forums/showthread.php?t=152035), then we have 14 missions. If not, then 12. Personally, I don't consider them new missions, so 12 in my opinion. Have no problem with other opinion. In any case, last year was productive!

My dream is for forums.thedarkmod.com to link to thedarkmod.com

Purah also worked on Dishonored: https://www.ttlg.com/forums/showthread.php?t=136214 One of my neurons knew it started with a 'P'

Thanks for noticing that. I still need to test the mirror / realtime reflection bug, but I need a proper test case which I no longer have meaning I may need to make a new map just for it. I played a FM with functional mirrors on walls and it had no issue, reflection works perfectly in latest beta... means it must be something only in certain rooms or with specific setups.

We got TDM VR, for a start. https://forums.thedarkmod.com/index.php?/topic/20468-the-dark-mod-vr-210-alpha-is-now-available/

Yes, it does. Which makes it interesting that you yourself explicitly said that it's interesting nobody had complained here on the official forums: I did, which is why it stood out to me so much that even though you yourself had personally been involved you would reply claiming nobody had complained here on the official forums. I'm not colorblind at all. Does that make people pointing out that almost no modern games have proper colorblindness support hyperbole? Just because it doesn't affect you, or you choose not to pay attention to the discussion of something, doesn't make it hyperbole. Pick pretty much any modern FPS and you will find plenty of discussion about the near universal disregard for FOV and camera movement as accessibility issues. Denigrating those as hyperbole because you personally don't feel the affects is as bad of a look as demeaning people who bring up the importance of valid allergen warnings like gluten or colorblindness and deafness support.

I literally registered just to point out that people HAVE been raising this as a serious accessibility issue since as far back as 2008. It's been repeatedly brought up over and over and over again. And that is just here on the official forums. If you really mean what you've said I think you should find it genuinely concerning that one of the single most widely discussed accessibility issues in gaming has been repeatedly brought up for over a decade with your game and apparently this is the first you've heard of it... even though it's even been subject to multiple issues in your issue tracking system according to these threads and other google results.

here use this link and never miss again its my startpage https://forums.thedarkmod.com/index.php?/discover

Speaking of reflection bugs and flickering: In the FM I'm working on (not public yet) I placed the puddle decal on some floors. I noticed that from certain positions and angles the puddle turns white, other decals seem to be working fine so it's likely specific to reflections. Should be possible to replicate using the button to create a decal on the selected face, moving the resulting patch 1 grid unit above the brush surface, then texturing it with "textures/darkmod/decals/dirt/puddle". Between the screenshots below, all I did was look a little to the right to trigger the new appearance, which can be seen becoming whiter and losing its reflection. There's also a difference of 20 FPS between the two, likely meaning the puddle shut reflections off... just now realized how great the performance impact of having puddles can be

You can find a test map here. Note that I remember not being too happy with it. https://forums.thedarkmod.com/index.php?/topic/19825-negative-spectrum/&do=findComment&comment=432949

DarkRadiant 3.7.0 is ready for download. What's new: Feature: Skin Editor Improvement: Script Window usability improvements Fixed: Hitting escape while autosaving crashes to desktop Fixed: Def parsing problem in tdm_playertools_lockpicks.def Fixed: DR hangs if selecting a lot of entities with entity list open Fixed: Float Property Editor's entry box is sticking around after selecting a float key Fixed: Spline entities without model spawnarg are unselectable Fixed: Entity window resets interior sizing forcing resize each time it is opened Fixed: Spline curves should not be created with a model spawnarg Fixed: Newly appended curve control vertices aren't shown at first Fixed: Light entities are zoomed out in preview window Fixed: Entity inspector spawnarg fields not always updated by UI windows such as Model Chooser Feature: Skin Editor (see video) Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.7.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep using DarkRadiant to create Fan Missions - they are the main reason for me to keep going. Please report any bugs or feature requests here in these forums, following these guidelines: Bugs (including steps for reproduction) can go directly on the tracker. When unsure about a bug/issue, feel free to ask. If you run into a crash, please record a crashdump: Crashdump Instructions Feature requests should be suggested (and possibly discussed) here in these forums before they may be added to the tracker. The list of changes can be found on the our bugtracker changelog. Keep on mapping!

Would it be at all possible to do this from the "main" website? I mean the one you first see when you look up "Dark Mod". Cuz it is a maze in these forums, goodies strewn about here and there but few resources that are intuitively accessible. Also @SeriousToni, what are you planning on uploading?

Originally the mug was created by @LordSoth https://forums.thedarkmod.com/index.php?/topic/13257-tdm-beginners-contest/&do=findComment&comment=287897

It seems that there is a reverse engineer group ( Amernime \ Nimez ) who are back-porting newer AMD drivers to older GPU versions. Terrascale 1 support is currently a "work in progress" : https://forums.guru3d.com/threads/amernime-zone-amd-software-adrenalin-pro-driver-release-nemesis-22-10-3-whql.436611/ If you are interested, they might have beta versions up on their terrascale discord. The downside is that these are community created drivers rather than official ones by AMD. Maybe AMD will release some sort of maintenance for terascale like they did for some of their other old GPU's.

id Studio did a poor job in defining its categorization of variable nomenclature, so in subsequent documentation and discussions there are divergent views (or just slop). In my series, I had to choose something, and went with what I thought would be clearest for the GUI programmer: Properties, which are either Registers (like true variables) Non-registers (like tags) User Variables (also true variables) I see that your view is more along these lines (which perhaps reflects C++ internals?): Flags (like my non-registers) Properties, which are either Built-in (like my registers) Custom (like user Variables) Also, elsewhere, you refer to "registers" as temporaries. I am willing to consider that there could be temporary registers during expression evaluation, but by my interpretation those would be in addition to named property registers. I'm not sure where to go next with this particular aspect, but at least can state it.