Search the Community

Oh, some implementations might work a little differently from what I remember the term megatexture referring to. From what I used to know, it meant turning the entire level into a single model or set that uses a single enormous texture. While the concept may have its upsides, there are two major issues that negate any benefit in my view: The first is system resources, you don't benefit from any reuse as every pixel is unique, the only way to do it at scale is with a gigantic image thus a huge performance drop in pretty much every department. The second issue is that level design becomes far harder and more specialized... while here in TDM we only need to draw a bunch of brushes and place some modules to make a level, an engine based on megatextures would require level designers to sculpt and paint the entire world in software like Blender which is far more difficult and we likely wouldn't have even half of the FM creators we do today, even for those that know how to do it imagine the task of manually painting every brick on every home and so on.

Completely disagree it was a very good idea that unfortunately came too early with idSoftware RAGE 1 because hardware was still and is not truly ready for it. Megatexture is for textures, what UE5 nanite is for geometry, it permits huge amounts of texture data in a level and even totally unique textures per each surface, no repetition unlike older methods. MT isn't simple a giant texture slapped unto a level, it is a type of virtual texturing system, the MT is a huge "texture" but it's data, is not all drawn on a level at the same time, like a normal one is, it is broken into smaller squared peace's and those peace's into even smaller ones for LOD aka mipmapping, then those peace's are streamed in, in real time has the player moves around. Again IMO It is a very cool idea and if the hardware was fast enough, to stream it fast and it was possible to compress the MT data, to very small amounts and still keep good quality, it would be a fantastic system for very unique levels. Rage 1 world may look bad at close distance, but at medium to large distances imo it looks fantastic and totally unique.

The Megatextures concept predates idSoftware. It even predates hardware accelerated 3D in consumer graphics. The problem it solves is managing image diversity. It is well suited to photogrammetry where almost nothing is repeated \ tiled. It is not well suited to human texture artists because even the most perfectionist ones are going to use some sort of template that they repeat and thus it is a waste to store the resultant work as unique pixels rather than tiles.

Rage didn’t have terrible loading times but people complained that it took awhile for the texture fidelity to catch up. Doom 2016 tried to fix that by front loading more but they went overboard with that.

Megatextures were a horrible idea for obvious reasons, not sure why ID chose to learn that the hard way. The concept from what I remember is the whole map uses a single gigantic texture... instead of how we independently pick a couple of 1024 px brick materials for a few brushes and surfaces, the whole map acts as one model with one material and a single texture which probably needs to be 1 million x 1 million pixels even for a small level. This is ridiculous from a perspective of system resources with 100's of GB's of storage and huge (v)RAM requirements and hours of loading time, as well as raising the skills required for level editing since you now need mappers to also be texture artists and sculpt / paint their levels instead of just placing stuff. The only thinkable benefit is there's no repetition since every pixel on every part of the world is unique, but who notices any similarity with independent texturing if it's done right anyway? Detail textures have yet another advantage there: Since you scale the pattern independently on top of the original texture, you can make every surface appear as if it has unique pixels like megatextures. Hence why I'd advice having the details be very high-res, 4k or 8k even 16k if we can take it: Yes that's enormous, but remember we'd only have a few patterns probably no more than 15 in total, and can store them as grayscale then use a single image to modify both albedo / specular / normal (heightmap to normalmap): Map the detail in world space rather than the brush or model UV map, and the resulting pattern on every surface in the world will always be unique since the original and detail textures will be out of sync.

I think that this discussion is probably similar to discussions that idSoftware themselves had about the challenges of texture storage in engines that heavily rely on Normal Maps for real-time lighting. The conclusion was Megatextures ( later known as partially resident textures ) but the suggestion was a little too ahead of its time. Heck, early Megatexture games would probably benefit from detail textures more than idTech4 because they capped the pixel density to allow larger map-sized textures. Many modern games have caught up and use partially resident textures but do so in a more conservative way thus making them part of a hierarchy of texture usage methods that includes texture atlases and traditional tiled textures.

I always say that...The only thing that beats a fail is a try. I'm actually interested in these Detail Textures now that you further talked about its history and how today we'd use it on 1080p for 512 and 1024 textures. If anything, it would be a fun experiment just to see how it would look and how it would go. Also, yeah, I wouldn't want the game to be bigger than 100GB and have extreme loading times, all in the name of modern textures at 4k, I have a very hefty computer but that doesn't mean poor ol' but venerable IdTech 4 wants to handle it.

Indeed and try to wait until you are sure the model is finished before you go through the trouble of aligning textures. I couldn't tell you how much time I spent realigning textures after adjusting walls, windows, etc., or changing my mind about the materials (especially when bevels are involved).

@Ansome's question is correct. Nothing in real life ever has a perfectly sharp corner, and one of the pieces of advice often given to newbie modellers trying to make things look realistic and avoid the "obvious CG" look, is to give sharp edges a tiny bevel so they look like something that might be manufactured in real life. The problem you've got in DarkRadiant is (1) dealing with tiny bevels using regular brush geometry is awkward, and (2) brushes aren't smoothed at all (unlike the cube on the right which actually has full smooth shading which you don't notice because of the tiny bevel). So unless you're willing to create imported 3D models with smoothed bevelled edges and place them on the corner of your buildings, adding bevels in brushwork might be more trouble than it's worth. Probably the most important things with brickwork corners is to make sure the bricks line up properly. There's nothing more obviously CG than a plastered-on brickwork texture which just ends in an unrealistic column of cut-off bricks, with mortar joints that are completely unaligned with the brickwork on the adjacent face.

If it's supposed to be an octagon, I don't think the corners need to be bevelled. Certainly it looks much better to bevel square corners, but the angles of an octagon don't look bad imo. If you want a smooth cylinder though, the default cylinder patch has 16 sides, which looks smooth enough in game. That would be easier than bevelling 8 corners. Speaking of smoothing; I was pleasantly surprised to find that if you make a model in Blender with smooth-shading ticked, then export an ase file, it will retain the smooth shading when imported to darkradiant.

That is one reason. That is 2 more reasons. You'd like a script that, if you had to run it again, would "do the right thing". Unfortunately, that right thing is very hard to program, and needs IMHO to be both bidirectional and with a better method of string version control, to support both the FM author's updates and potentially multiple translators. Yes, another reason. Currently, it is my understanding that updating an FM (from the non-converted copy) and running the conversion script again causes mis-alignment of newly-generated #str values and previous .lang #str values. Another important cause of "nobody is making these language packs" is that Dark Radiant at best tolerates converted FMs. It offers no special translation support, as expressed in this code comment: "...we don't have any support for parsing the mod-specific translation data...." [from DR's DifficultySettingsManager.cpp]. That's where we are now. So officially give up on FM Western translations? Or improve the #str system to make it work for everyone? Or invent a new system? A new system. What would that look like to the FM author? To a non-author translator

Interesting idea. Not sure about my upcoming time availability to help. A couple of concerns here - - I assume the popup words uses the "Informative Texts" slot, e.g., where you might see "Acquired 80 in Jewels", so it likely wouldn't interfere with that or with already-higher subtitles. - There are indications that #str is becoming unviable in FMs; see my just-posted: https://forums.thedarkmod.com/index.php?/topic/22434-western-language-support-in-2024/

In post https://forums.thedarkmod.com/index.php?/profile/254-orbweaver/&status=3994&type=status @nbohr1more found out what the Fixup Map functionality is for. But what does it actually do? Does it search for def references (to core?) that don't excist anymore and then link them to defs with the same name elswhere? Also I would recommend to change the name into something better understood what it is for. Fixup map could mean anything. And it should be documented in the wiki.

I'm at the beginning of a new area, where bandits fights each other. Near the end, I imagine, but I'm not going to bother finishing it. The thing is tedious. It's very obvious your focus was on telling a story. The issue is that's not my thing, and I also think this is not the right game for it. You're trying to make it do things it was never designed to, so it feels clunky. I think the game shines best in a smaller map with some backstory and little touches in the mission, like notes one character leaves for another. Here, it feels like I'm being pulled along from place to place, having to go back where enemies have artificially respawned, with locked doors everywhere, JUST to further the story, not to give me an interesting challenge. And in terms of story, it's the same thing we see all the time: Pagans are the poor, downtrodden, nice people, and the Builders, are the heartless monsters. Yawn. I don't get how the gargoyle switch works in that guy's office, even after having read your explanation. I don't even understand what the situation is supposed to be. The gargoyle looks like it's locked inside a glass case, and therefore you want to get that glass case open. The note says the gargoyle switch is behind the downstairs desk. Downstairs from this note, there is no desk. And the note calls it the "gargoyle switch", which implies it's a switch for the gargoyle, not that the gargoyle itself is a switch. It's confusing for no good reason. Random notes: Boring name, as others have mentioned. A cursive font in letters is annoying to read. Loud music and sound effects are not fun, it just hurts the player's ears. The map is a screenshot. That ruins immersion. The light issues have been covered. For me, it never felt like I was in shadows, as opposed to other missions. Almost everything looks pretty brightly lit. I saw someone mentioning rope arrows are pointless, and I agree. You asked how that player could have made it past something without using one; well, I haven't used it either. You can just mantle. Of course, that's not an issue in itself. There's not reason to cry "I'm getting review bombed" when people are just giving their opinion.

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.

yeah its a jungle out there but a 12 gb card on a 128 bit bus would only be viable with dlss and then only just . but there will probably be plenty of options as you mention though id still go for something that would atleast be able to drag the ammount of vram without workarounds. strangely the old amd R9 390 had a 512 bit bus and could probably have accepted 32 gb vram but the card is to slow to do 4k in modern titles. even so the 8 gb model actually ran quite nicely in games such as the first horizon in 4K but would probably choke and die on forbidden west . minor wtf moment is crysis remastered it runs it at 4k in can it run crysis with a gazillion fps looks quite purty to but i suspect this is a bug.

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?

No, the 192-bit RTX 3060 12 GB came first. The cut down 8 GB model came over a year and a half later, and probably in small numbers because nobody talks about it much other than "don't get it, it's 20-30% slower". 3060 Ti had 8 GB from the start, and always has, although it looks like they made a GDDR6X version. They would have to change the bus width to accommodate 12 GB. There were rumors of products like 3070 16 GB, 3080 20 GB and so on, but they never materialized outside of engineering samples. If you think things are confusing now, just wait until 3 GB GDDR7 chips materialize within a couple of years. We could see 12 GB cards on a 128-bit bus, 9 GB on 96-bit, and so on.

3060 has 192-bit bus (cut to 128-bit for the maligned 8 GB model), and the gimped cards (like 7600 XT 16 GB 128-bit) can definitely use the extra VRAM in some scenarios. https://en.wikipedia.org/wiki/GeForce_30_series#Desktop

aye the rtx 3060 was another weird one, it only has a 128 bit bus which is to low to effectively handle 12 gb so it did not really help with the extra vram in higher resolutions. sadly they decided to continue with the same eh "mistake" with the rtx 4060 16 gb model . id call that deception to make users pay more for a card which is not even rated for 4K... sadly. the 16 gb 3070 model was scrapped by nvidia because it would be a contender for the much higher priced 3080 non ti i guess as it has a 256 bit bus and hence would be a capable 4k card. the 3060 ti 8 gb was a much better card sadly. https://www.techradar.com/reviews/evga-geforce-rtx-3060-black-xc

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.

Hm after testing: This does actually work fine. Both in DR and in tdm. I guess there's no point in specifing the model path, because then it only works on one specific func_static.