Search the Community

This appears to be the function which calculates the texture values for Q3 export: https://gitlab.com/orbweaver/DarkRadiant/-/blob/master/radiantcore/map/format/Quake3Utils.h?ref_type=heads#L56 It's largely based on legacy GtkRadiant code and means absolutely nothing to me.

sadly the upcomming 8xxx series from amd will only be for midrange atleast according to leaks (grain of salt maybe ?). well it would be something quite different thats for sure not sure if 32 gb vram would actually help (what is the max texture size today ?), it might help if they really go nuts with the detail level in upcomming titles but i suspect this might take longer as the game companies dont want to alienate players with less vram. ofc it will come at some point but i dont see it in the near future. the 2 and 3 gb vram chips might actually make a dent in the bus width war. what the hell happened with hbm memory ???, the old fury cards could actually do 4k no problem with only 4 gb vram because the hbm memory was so blazing fast.

@The Black Arrow That's a good analysis. I don't disagree but we're referring to different time periods with different quality aims: In the early days of 3D and low-res CRT screens when we had 256x256 textures, detail textures were used to make surfaces appear as if they have 1024x1024 textures... today in the age of 1080p monitors such texture can appear blurry from up close, we want to make 1024x1024 textures appear of 4096x4096 quality. Back then the goal was to get at least a little bit of perceived sharpness, today the goal is to see those microscopic details on every surface as if everything is real... while the concept of detail textures is old it scales to cover both aims. As you correctly pointed out, the ideal solution would be upgrading the actual textures themselves. Sadly there are two big problems with this that will likely never be possible to overcome: Someone must create or find identical textures to replace existing ones, which have to retroactively fit every old FM. That would be a huge effort for so many images, and will not look exactly the same way so people would complain how "this wall used to be made of small red bricks which are now larger and yellower which isn't what I intended and no longer line up". An advanced upscaling filter may be able to bump the resolution with good results, this would be a lot less effort and retain the exact appearance of textures. The even greater issue is storage and memory use would go through the roof. Imagine all our textures (from surfaces to entity skins) being 4096x4096 which would be the aim for decent quality today: TDM could take over 100 GB of drive space, you'd need at least 16 GB of RAM to run it, and the loading time of a FM will be 5 minutes. Detail textures are a magic solution for both problems: They're overlayed in realtime on top of the standard textures without changing their base appearance. This means you see pixels several times the scale of the image without requiring any image to actually be at that resolution, no vRAM or loading time increase. And if detail layers are disabled with distance you also don't lose FPS in per-pixels calculations when distant lights update.

Alright, so, I'm a Texture Artist myself for more than 20 years, which means I know what I'm talking about, but my word isn't law at all, remember that. I've worked (mostly as mods, I am a professional but I much prefer being a freelance) with old DX8 games up to DX12. When it comes to Detail Textures, for my workflow, I never ever use it except rarely when it's actually good (which, I emphasize on "rarely"). This is one reason I thought mentioning that I worked with DX8 was logical. One of the few times it's good is when you make a game that can't have textures higher than what would be average today, such as, World Textures at 1024x1024. Making detail textures for ANY (World, Model) textures that are lower than 128x128 is generally appealable. Another is when the game has no other, much better options for texturing, such as Normal Maps and Parallax Mapping. Personally, I think having Detail Textures for The Dark Mod is arguably pointless. I know TDM never had a model and texture update since 2010 or so, but most textures do seem to at least be 1024x1024, if there's any world texture that's lower than 256x256, I might understand the need of Detail Textures. Now, if this was a game meant to be made in 2024 with 2020+ standards, I would say that we should not care about the "strain" high resolution textures add, however, I do have a better proposition: Mipmaps. There are many games, mostly old than new ones, that use mipmaps not just for its general purpose but also to act as a "downscaler". With that in mind, you boys can add a "Texture Resolution" option that goes from Low to High, or even Lowest to Highest. As an example, we can add a 2048x2048 (or even 4096x4096) world texture that, if set to Lowest, it would use the smallest Mipmap the texture was made with, which depends on how the artist did it, could be a multiplication of 1x1 or 4x4. One problem with this is that, while it will help in the game with people who have less VRAM than usual these days, it won't help with the size. 4096x4096 is 4096x4096, that's about 32mb compressed with DXT1 (which is not something TDM can use, DXT is for DirectX, sadly I do not know how OpenGL compresses its textures). I would much rather prefer the option to have better, baked Normal Maps as well as Parallax Mapping for the World Textures. I'm still okay with Detail Textures, I doubt this will add anything negative to the game or engine, very sure the code will also be simple enough it will probably only add 0.001ms for the loading times, or even none at all. But I would also like it as an option, just like how Half-Life has it, so I'm glad you mentioned that. But yet again, I much prefer better Normal Maps and Parallax Mapping than any Detail Textures. On another note...Wasn't Doom 3, also, one of the first games that started using Baked Normal Maps?

Interesting! Does it update all default textures so it's used on everything in the world? I should replay it and check that out: It would give us a good view of how the effect will feel in practice. Looking at the page, they seem to do it the conventional way I was thinking of trying out, which is currently supported by the engine but more limited than a proper implementation. It also looks like they're only doing it for the albedo channel, to be effective detail should be applied to all maps... the normal map is where the improvement should be most noticeable as it responds to lighting and modifies everything else. The implementation I'm thinking of should be universal like all effects and work on any FM new and old. It would be controlled by a menu setting, no one needs to enable it if they don't like how it looks or it impacts performance. Each detail pass should fade and be hidden with distance, we don't want to stress pixel lighting by having it compute thousands of dots on distant surfaces each frame. Just like the TDM ambient method, we'll likely need a special segment for materials meant to indicate what kind of detail each texture wants, then based on settings and camera position the renderer must modify each surface accordingly.

There's been talk over the years on how we could improve texture quality, often to no avail as it requires new high-resolution replacements that need to be created and will look different and add a strain on system resources. The sharpness post-process filter was supposed to improve that, but even with it you see ugly blurry pixels on any nearby surface. Yet there is a way, a highly efficient technique used by some engines in the 90's notably the first Unreal engine, and as it did wonders then it can still do so today: Detail textures. Base concept: You have a grayscale pattern for various surfaces, such as metal scratches or the waves of polished wood or the stucco of a rough rock, usually only a few highly generic patterns are needed. Each pattern is overlayed on top of corresponding textures several times, every iteration at a smaller... as with model LOD smaller iterations fade with camera distance as to not waste resources, the closer you get the more detail you see. This does wonders in making any texture look much sharper without changing the resolution of the original image, and because the final mixture is unique you don't perceive any repetitiveness! Here's a good resource from UE5 which seems to support them to this day: https://dev.epicgames.com/documentation/en-us/unreal-engine/adding-detail-textures-to-unreal-engine-materials Who else agrees this is something we can use and would greatly improve graphical fidelity? No one's ever going to replace every texture with a higher resolution version in vanilla TDM; Without this technique we'll always be stuck with early 2000's graphics, with it we have a magic way of making it look close to AAA games today! Imagine being able to see all those fine scratches on a guard's helmet as light shines on it, the thousands of little holes on a brick, the waves of wood as you lean into a table... all without even losing much performance nor a considerable increase in the size of game data. It's like the best deal one could hope for! The idTech 4 material system should already have what we need, namely the ability to mix any textures at independent sizes; Unlike the old days when only a diffuse texture was used, the pattern would now need to be applied to both albedo / specular / normal maps, to my knowledge there are shader keywords to combine each. Needless to say it would require editing every single material to specify its detail texture with a base scale and rotation: It would be painful but doable with a text injection script... I made a bash script to add cubemap reflections once, if it were worth it I could try adapting it to inject the base notation for details. A few changes will be needed of course: Details must be controlled by a main menu setting activating this system and specifying the level of detail, materials properties can't be controlled by cvars. Ultimately we may need to overlay them in realtime, rather than permanently modifying every material at load time which may have a bigger performance impact; We want each iteration to fade with distance and only appear a certain length from the camera, the effect will cause per-pixel lighting to have to render more detail per light - surface interaction so we'll need to control the pixel density.

ok so after getting myself a rtx 3070 im left with a bit of a wonder about all the fud on the net. elitist users claim the 3070 cant do 4k (debunked it handles 4k just fine but you need to lower the texture resolution in some titles to not overshoot the frankly rather low amount of vram -> 8 gb). some back and forth on the 2080ti some claim that the 3070 is faster while others claim the 2080ti is. (from my own experience the 2080ti is a bit faster in 4k while the 3070 is a bit faster in lower resolutions). if you play exclusively in 4k go for the 2080ti -> reason it has more vram 11gb vs 8gb this might not sound like a huge deal but the extra 3gb helps a lot with ultra high texture resolutions. debunked (claims that the 3070 uses newer dlss features, it does not. the 2080ti supports the exact same dlss features that the 3070 does, it even supports dlss 3 minus the framegen feature. some claims the 3070 uses newer tensor cores which are faster, well is they are i dont see it... the 2080 ti has 4 times the amount of tensor cores compared to the 3070 while the 3070 has around 1000 more cuda cores hmm ???). the real reason i think the 3070 got so popular is that it delivered close to the same performance of the insanely overpriced 2080ti, i cant fault people for that choice but i would like some realism in the comparison and not something based on just the price. the 2080ti was a highend card back when it was new while the 3070 is a mid range card at half the price of the 2080ti with at least comparable performance but lacks enough vram to play all titles at 4k with everything cranked to the max. playing hzd forbidden west on the 3070 atm in 4k with everything on max except texture resolution which i have on high and i get > 80 fps with the framegen mod and around 45 fps without it (dlss is flaky in this game though), the 2080ti in the same game in 4k gets around 100 fps with the framegen mod and 55 fps without it with texture resolution at the highest setting).

Actually I think I found what's causing issues with my textures: DR changes the texture's Horizontal and Vertical Shift when a face gets slanted. E.g., my test door is facing -Y and sitting flat on the ground, which is at 0 in Z, so the v-shift is 0. When I move the bottom vertices of the door 8 units forward, and then re-fit the texture, the v-shift turns to 4 (3.97241). If I do the same but backward, the v-shift turns to 90.7035. But these values depends on the distance the face is from the world origin, and sometimes if I move the top vertices instead, the values don't change. I can't make sense of it... The other editors don't do this, so the plugin's import code doesn't account for it. Do you think you could help me understand the logic behind this? If I could understand it, maybe I could get the plugin working with it.

I'm not using the Quake 3 engine, I'm using the Godot engine. The results seem ok, except when faces are slanted, but I'm not sure why it happens. I'm trying to find out. I don't know anything about the Q3 engine, so I'm not the one to say what's correct and what isn't about the map format. When I said "correct", I just meant that it's the same value that is displayed in the editor. But there are differences between the Q3 format from DR and from other editors I've tested, like TrenchBroom and NetRadiant Custom. They keep the texture values as they are in the editor. One other difference is that DR exports entity brushes with coordinates relative to the `origin` spawnarg, for example. Though DR is also the only editor that enforces the `origin` spawnarg. (I know there are two Q3 formats, and I'm using the equivalent one on all editors.) I'm importing maps into Godot using a plugin. I've made some changes to it to accommodate for the differences in the map format and some editor specific stuff (e.g. DR uses "rotation" matrices instead of euler "angles").

So..., texture issues are being the only road block I'm having so far in trying to use DR with Godot, but I'm not exactly sure why yet. However, I've noticed when exporting maps in quake3 format, that the texture values don't match the ones in the editor. This is the door face in the map file: hs vs rot hscale vscale ( 24 64 0 ) ( -24 64 96 ) ( 24 64 96 ) darkmod/door/wood/board_brown_nails_hinge 64 256 -180 -0.375 -0.375 0 0 0 The horizontal shift is the only correct value. Is this a bug?

AHA, you're indeed correct! Changing the skin names so they start with "a1"' did the trick! This was actually a successful experiment I was trying out! The wiki goes into some detail about making "general skins" that can affect all models. My hope was that, if I made two models using the same skins, then I could just write a single skin file that would change all of them! For example, since "Straight Frame" and "V-Frame" models both use plaster_01 as their main background... ...all I have to do is make a general skin to change that specific plaster texture... ...and then any of the "V-Frame" and "Straight Frame" models can have different backgrounds! It's not a perfect system, as some skins just don't contrast well with the wooden beams, but I should still be able to get a LOT more out of my models now!

Yes. Sure, I will change it, but I do mind. In addition to changing the forum title, I have also had the name of the pk4 changed in the mission downloader and the thiefguild.com site’s named changed. It's not just some "joke". The forum post and thread are intended to be a natural extension of the mission’s story, a concept that is already SUPER derivative of almost any haunted media story or most vaguely creepy things written on the internet in the past 10 or 15 years. Given your familiarity with myhouse.wad, you also can clearly engage with something like that on some conceptual level. Just not here on our forums? We can host several unhinged racist tirades in the off-topic section but can’t handle creepypasta without including an advisory the monsters aren’t actually under the bed? (Are they though?) I am also trying to keep an open mind, but I am not really feeling your implication that using a missing person as a framing of a work of fiction is somehow disrespectful to people who are actually gone. I have no idea as even a mediocre creative person what to say to that or why I need to be responsible for making sure nobody potentially believes some creative work I am involved in, or how that is even achievable in the first place. Anyway, apologies for the bummer. That part wasn’t intentional. I am still here. I will also clarify that while I love the game, I never got the biggest house in animal crossing either. In the end Tom Nook took even my last shiny coin.

There are no console errors when I reload skins. I did double check and sure enough, one of the texture directories was incorrect. I went ahead and added it. Ah, of COURSE there would be a blank space somewhere...alright, I went ahead and fixed it. While both of your observations were correct, it unfortunately still doesn't load the new skin. I've attempted to reload it with no success. Yeah I suppose that would be important to explain lol. When I go into the model view, and click "Change Skin", it doesn't display a new skin. The console log confirms this, as before and after me making changes/reloading the skin, it only finds the same amount of skins.

I think you need to be more specific. What exactly "does not work"? Does the skin not show up in DR? Does it show up but crash DR? Does it appear but replace the wrong texture, or attach to the wrong model? From the screenshot of the skin file in Notepad it looks like you have a space in the model name, but I'm not sure if that's the cause of the problem or just a cosmetic artifact of the screenshot.

It was a weird mission, that's for sure. And you put a lot of original ideas into it. I appreciate that. The machines were very convincing. I don't know if you made them or if they're part of the new edition, but they are excellent quality. The game needs dirty water texture for its canals. And dirty building blocks. It's very cool that the doors consume the keys. The floor textures look strange on walls and ceilings. It took me a little bit more than 9 hours to finish it.

I've seen fun workarounds like that in other game modding as well. Years ago, maybe even a decade, some fella who was making a mod for Mount & Blade over at the Taleworlds forums revealed that he put invisible human NPCs on the backs of regular horse NPCs, then put the horse NPCs inside a horse corral he built for one of his mod's locations/scenes and then did some minor scripting, so the horses with invisible riders would wander around the corral. The end result was that it looked they're doing this of their own will, rather than an NPC rider being scripted to ride around the corral slowly. Necessity is the mother of invention. I don't know about the newest Mount & Blade game, but the first generation ones (2008-2022) apparently had some sort of hardcoded issue back in the earlier years, where if you left a horse NPC without a rider in its saddle, the horses would just stand around and wait and you couldn't get them to move around. Placing an invisible rider in their saddles suddenly made it viable again, at least for background scenes, of riderless horses wandering around, for added atmosphere. First generation M&B presumed you'd mostly be seeing horses in movement with riders, and the only horses-wandering-loosely animations and scripting were done for situations when the rider was knocked off their horse or dismounted in the middle of a battle. Hence the really odd workarounds. So, an invisible NPC trick might not be out of the question in TDM, even though you could probably still bump into it, despite its invisibility.

DarkRadiant 3.9.0 is ready for download. What's new: Feature: Add "Show definition" button for the "inherit" spawnarg Improvement: Preserve patch tesselation fixed subdivisions when creating caps Improvement: Add Filters for Location Entities and Player Start Improvement: Support saving entity key/value pairs containing double quotes Improvement: Allow a way to easily see all properties of attached entities Fixed: "Show definition" doesn't work for inherited properties Fixed: Incorrect mouse movement in 3D / 2D views on Plasma Wayland Fixed: Objective Description flumoxed by double-quotes Fixed: Spinboxes in Background Image panel don't work correctly Fixed: Skins defined on modelDefs are ignored Fixed: Crash on activating lighting mode in the Model Chooser Fixed: Can't undo deletion of atdm_conversation_info entity via conversation editor Fixed: 2D views revert to original ortho layout each time running DR. Fixed: WX assertion failure when docking windows on top of the Properties panel on Linux Fixed: Empty rotation when cloning an entity using editor_rotatable and an angle key Fixed: Three-way merge produces duplicate primitives when a func_static is moved Fixed: Renderer crash during three-way map merge Internal: Replace libxml2 with pugixml Internal: Update wxWidgets to 3.2.4 Windows and Mac Downloads are available on Github: https://github.com/codereader/DarkRadiant/releases/tag/3.9.0 and of course linked from the website https://www.darkradiant.net Thanks to all the awesome people who keep creating Fan Missions! 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!

I usually share other people's photos of historical and industrial architecture in this thread, but I've decided to finally share some of my own photos that I've accumulated over the years. Over the years, especially the last twenty or so years, I've wandered many of the old town quarters in cities and towns all around my country, taking snapshots. Wereas many of the main streets and major landmarks have long since had nice and beautiful restoration work done, many of the more obscure side streets, back alleys and occassional overlooked corners had interesting sights to behold. I've particularly been fond of old townhouses that show elements from different eras of history, as well as all the wear accumulated over the years and decades. As much as I like that many of these eventually also receive decent restoration work and look nice again, the sight of a well-worn, dilapidated or even ruined house or ocassional public building can prove really stimulating for the imagination. They've got a lot of proverbial "texture" (not just in the surface sense) and "character" that can hike one's imagination, especially with regards to lived-in environments with long histories.

Ah, pity I wasn't reading the forums back in February. I'm fond of that game, along with Bugbear's other early title, Rally Trophy. I was never too good at FlatOut, but it was always a hoot to play.

What Stgatilov mentioned about the psychological aspect of some lights being breakable and others not is going to be the toughest hurdle for you to overcome with this idea. Realism with the clear glass casing idea is nice, but you are still fighting against the rigid Thief programming that electric lights are always unbreakable. It needs to be very obvious, perhaps best identifiable at a glance, that it can be broken by the player. Consider how all explosive barrels in video games are red: it immediately differentiates them from regular set dressing barrels. I don’t believe that I would be able to consistently identify or interpret a clear glass bulb as different from any electric light. Add a red stripe to them, give them a specific recognizable light texture, make them look inherently damaged, etc. You may need to sacrifice a degree of realism in order to communicate what is thus far a contradictory mechanic to the player effectively.

I couldn't help thinking of another realism related suggestion, don't know if it was discussed before but it seemed like an interesting idea. If this were to be changed on existing lights by default, it would have minor gameplay implications, but the sort that make missions easier in a fair way. So... electric lights: Like the real ones of the era, they're implied to use incandescent light bulbs... the kind that in reality will explore and shatter upon the smallest impact, and which like real lamps are encased in glass or paper. In any realistic scenario, shooting a broadhead arrow at a lamp or even throwing a rock at it would cause it to go through the glass and break the light bulb inside. Is it wrong to imagine TDM emulating this behavior as a gameplay mechanic? Just as you can shoot water arrows at flame based lights to put them out, you'd shoot broadhead arrows at electric lights to disable them... you must however hit the glass precisely, there's no room for error and it must be a perfect shot. As a way to compensate for the benefit, AI can treat this as suspicious and become alert if seeing or hearing a lamp break, or finding a broken lamp at any time if that's deemed to provide better balance. A technical look at implementing this: Just as broadhead arrows can go and stick through small soft objects such as books, they should do the same if you hit the glass material on a lamp, while of course still bouncing off if you hit metal: Lamp glass would need a special material flag that sends a signal to the entity upon collisions but allows arrows to go through, unlike glass in other parts of the world which is meant to act as solid and changing that everywhere would break a lot of things. When pierced by an arrow, the lamp should immediately turn itself off while playing a broken glass sound and spawning a few glass particles. The glass material should be hidden if the model is a transparent surface, or replaced with a broken glass texture in case the glass is painted on a lamp model without an interior... obviously this would be done by defining a broken skin for the entity to switch to. This does imply a few complexities which should be manageable: Existing lamps supporting this behavior will need new skins and in a few cases new textures, the def must include a new skin variable similar to the lit / unlit skins in this case a broken skin. Any electric light may be connected to a light switch, we don't want toggling the switch to bring the light bulb back to life... as such a flag to permanently disable triggering the light from that point on would be required. For special purposes such as scripted events to reset the world, we should allow an event to unbreak lamps, setting their state back to being lit / unlit while re-enabling trigger toggling. What do you think about this idea and who else wants it? Would it be worth the trouble to try and implement? If so should it only be done for new lights or as a separate entity definition of existing ones, or would the change be welcome retroactively for existing missions without players and FM authors alike feeling it makes them too easy?

I think we can use this script (mod) to extract all textures with specular maps, and if possible, create a map for testing. Unfortunately, I'm not yet familiar with the editor to help with this. I came here because I plan to work on textures more thoroughly, and I'm currently reading the wiki on texturing issues. In general, I'm interested in this topic. Maybe I'm not competent at all, but is it possible to make a texture have a constant reflection (yes/no) and a variable with a setting in the editor/accompanying document (?) that controls the intensity? For example, the same object/texture can behave differently on different maps.

Yep... just what I was thinking of, except it's even worse than I remember now that I see it. Biggest limitation with stencil is you can't have alpha texture shadowing, so stuff like plants had to have their shadows turned off. I'd say this is the most important reason why enabling map-only effects was a good decision, followed by other improvements and potential future features like transparent / colorized (stained glass) shadows.

@snatcher I understand that when you feel your work doesn't live up to your goals that you don't want it out in the wild advertising your own perceived shortcomings but that leads to a troubling dilemma of authors who are never satisfied with their work offering fleeting access to their in-progress designs then rescinding them or allowing them to be lost. When I was a member of Doom3world forums, I would often see members do interesting experiments and sometimes that work would languish until someone new would examine it and pickup the torch. This seemed like a perfectly viable system until Doom3world was killed by spambots and countless projects and conceptual works were lost. I guess what I am trying to say is that mods don't need to be perfect to be valuable. If they contain some grain of a useable feature they might be adapted by mission authors in custom scenarios. They might offer instructive details that others trying to achieve the same results can examine. It would be great if known compelling works were kept somewhere safe other than via forum attachments and temporary file sharing sites. I suppose we used to collect such things in our internal SVN for safe keeping but even that isn't always viable. If folks would rather not post beta or incomplete mods to TDM's Moddb page, perhaps they would consider creating their own Moddb page or allow them to be added to my page for safe keeping. Please don't look at this as some sort of pressure campaign or anything. I fully understand anyone not willing to put their name next to something they aren't fully happy with. As a general proviso, ( if possible \ permitted ) I just want to prevent the loss of some valuable investigations and formative works. The end of Doom3world was a digital apocalypse similar to the death of photobucket. It is one of my greatest fears that TDM will become a digital memory with only the skeletons of old forum threads at the wayback archive site.