All Activity

Ps. sorry for the huge wall of text....

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.

Yes, if you turned too fast, you could see the textures pop in. Most Unreal engine games still do this when you start...

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.

Wasn't "Megatextures" the reason Doom 2016 (IdTech 6) takes years to load though, even on a high-class SSD? I've then heard that Megatextures were scrapped out in Doom Eternal (IdTech 7), which apparently could add to the fact it loads incredibly fast.

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.

Here's mine, also 3 monitors but I only use 2 for DR: single XY view on the first monitor; switch between XY views using CTRL-Tab Camera and all other tools on 2nd monitor - now that everything is a tab no need to tile everything 3rd monitor for other non-DR stuff (like the forum )

I can share mine (3 monitors), I hope it can help

I wasn't really thinking about cohesiveness. i was trying to give the game a more Golden touch like in DXHR. I'm using Cinetool Lut which has many options for color combination. Each one makes the game look and feel different and it's a great Reshade Tool.

Iris is one of the very best, for sure.

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).

Venturing beyond the base game... A candle set consists of a candle holder and a candle attached to it. Core candle holders, candles and candle sets are properly named in v1.0 but mappers sometimes create their own candle sets and because of how these object are handled by the engine we end up with a "Candle holder" on screen. We can approach this puzzle in different ways but for the sake of simplicity in v1.1 everything is a "Candle", including single candle holders. Find v1.1 attached to this post. Remember you need the Core Essentials for the mod to work. z_nameless_objects_mod_v1.1.pk4

Also, related to font improvement, I've just released "ExportFontToDoom3All256", a reconstruction of an earlier but now lost tool variant. This is described and available in the wiki article ExportFontToDoom3 I tested that tool using one of the TDM FM fonts, Andrew Script, for which a TTF file is available. I generated a fresh set of bitmaps (newly including any available Latin-1 characters). I also mucked about with FontForge, to reconfigure that TTF to be ordered like the TDM custom codepage. However, Andrew Script is missing a fair number of Latin-1 glyphs, so it would take some work to make it good (whether by editing in FontForge or post-export as bitmaps). I'm putting that aside for now, since the jury is out on whether Western language support in FMs and their fonts will become viable (see Western language support in 2024?). Instead, I plan to turn my font-improvement-for-2.13 attention to Stone 24pt, which (because its used in HUD captions) is more clearly worthwhile to work on. Looks like I'll have to convert the Stone DDS to TGA as a prerequisite to bitmap editing.

Just for the record to benefit readers here, the archived Stone .tga's turned out to be the original ASCII-only versions, not the versions that got extensive bitmap editing. Too bad.

@Wellingtoncrab - thanks for the fast response! Thanks again for all your hard work - I'm looking forward to driving on with this FM!

@Grey Mauser thanks for taking the time to play! I am glad to hear you are enjoying it. Yeah at some point the glasses effect became much more subtle than it was during development and this should probably get fixed at some point. It seems near impossible for a lot of players to make out.

This is just amazing! I'm a latecomer to TDM and have only tried out a few FMs. I didn't think anything could ever approach the immersive experience of The Painter's Wife, until now. Tip of a HUGE hat to Wellingtoncrab and their team for what must have been an enormous labor of love! Now to a request for some help re. House Ursine:

@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.

I agree, that is an issue. It would be better if the system handling briefings/readables could be revised as you indicated, to handle individual sentences as #str_, rather than whole pages. Baring that, having a key field like "#str_This is a whole page\nfull of text that goes on and on and on [...] until done" would appear as a very long single line. That is nasty to look at in the Readables Editor, and even worse in the .langs file, where the too-long text would appear twice on a line (once with #str_ prefix of English version, another in translation). So for those, it would be better in the short term to stick to symbolic keys, e.g., existing #str_12345 or revised form #str_myfm_book_of_spells_page_1 I might add, in the longer term, enhancing the Readable Editor to use the .lang files would be an enormous improvement for FM authors and a significant accomplishment. A fair amount of work though, but probably doable in increments over several releases.