Search the Community

That's very interesting, thanks for laying out the current possibilities so well. It's better than nothing at all. But as can be easily seen, they are very limited in how far you can go. Engine changes would be needed but greater and more difficult things were achieved. The worst thing is like you said we can only deform texture coordinates not real vertice positions. Essentially TDM only lets you use fragment shaders but not vertex shaders, and it's the later we need to apply a sine deform to, although in other engines GLSL lets you use both as necessary. Vertex deforms need to be exposed in our shaders to allow any realism for banners swaying in the wind or the clothes and hair on AI as they walk through windy areas. Then there's the issue that the direction and intensity of the deform doesn't match that of the wind. This can be manually done to some extent, by adjusting the direction of the func_pendulum for each grass blade, but it's so tedious you'd need to use a complex script to set it especially if you want to spawn a lot of grass with a seed across complex terrain so it's not worth it. With the system I'm envisioning, the mapper places the same func_static flag model in multiple locations and each will be pushed away from the wind source automatically, also the flame particles on torches as well as candles the player is carrying will be automatically pushed away in the correct direction wherever they're located or moved. There's also no actual variation this way. My idea of using sound intensity like for flickering lights would allow making plants and particles pushed by the wind based on the volume of its sound at that moment, of course multiplied by attenuation based on the distance of the wind speaker and the distance of each vertice / particle from it. We can even apply a delay based on distance from the sound source, so whenever it gets louder you see the wave traveling across cloth and grass blades, once the base system is in place details like this should be far easier and look amazing

AI has reached video game development. The current model is capable of recreating DOOM in real time while playing. https://arstechnica.com/information-technology/2024/08/new-ai-model-can-hallucinate-a-game-of-1993s-doom-in-real-time/ https://gamengen.github.io In the near future, daily a new TDM mission autogenerated? I remember in the past the game Rise of the Triad. Very nice FPS of 1995, similar to DOOM. But apart of the normal levels of the game, it included also an generator capable to create with an click any number of random maps and an Editor to create maps by hand A remastered version on Steam €19,95, the Demo version for free (10 maps, I think) https://store.steampowered.com/app/1421490/Rise_of_the_Triad_Ludicrous_Edition/

Here's my first FM. A small and easy mission, inspired by Thief's Den and The Bakery Job, where you must find and steal a cook's recipe book in order to save a friend from going out of business. Download (version 4): Mediafire (sk_cooks.pk4) TDM Website's Mission Page The in-game mission downloader Thanks to: The people who helped me get this far, both in the forums and on Discord. The beta testers: MirceaKitsune, Mat99, Baal, wesp5, Cambridge Spy, jaxa, grodenglaive, Acolytesix ( Per the author in the beta testing thread. ) Skaruts has given permission to the TDM Team to add Subtitles or Localization Strings to this mission. (No EFX Reverb.) If anyone from the Community or TDM team wishes to create these we will gladly test them and update the mission database.

I'm not sure what is "GPU time %". FPS on Vsync off is much more sane performance metric. Did you check that quality is about the same when looking at the same distance? How did you set texture size for parallax mapping? Downsampling it might help performance.

Getting ready to head back home and did a quick search on the wiki page from my laptop. The commands I need are hide() and show() for visibility, setModel() for changing the model, setSkin() for changing the skin. The key questions are: What happens if I use show() and hide() on an AI or ragdoll? Does TDM know to hide all entities attached to that AI and suspend AI processing then resume when showing again? Or would it only make the body entity invisible and break stuff? What happens if I use getHead() to get an AI's head then use setModel() on that? In my disguises mod I used to get a crash when changing the player's head model but this has since been fixed, I take it doing it on AI should be safe too then?

Also, a more general lesson to draw from these examples is that context is critical to Large Language Model (LLM) algorithms. LLMs are pattern completion algorithms. They function by searching for patterns in the letter-sequence of the text within its memory buffer. It then predicts the most likely sequence of letters to come next. (Or more accurately it randomly selects a block of letters called a token from the predicted probability distribution of possible tokens, but that distinction is mostly academic for the end user.) These models are then trained on effectively the complete written works of humankind to self-generate an obscenely sophisticated prediction model, incorporating literally billions of factors. Context matters because the LLM can only build on patterns already established in the prompts you give it. The less context is given in the prompt, the more the response will tend towards the most common sort of non-specific example in the data set. Conversely the more patterns you establish in a conversation the more the model will want to stick to those patterns, even if they are contradicted by the user's directions or basic logic. In the life is a journey example, once the model has been infected with the idea that "Life is a journey" has four syllables that very simple and powerful meme starts to stick in its "mind". The mistake is to then introduce linkages to syllable counting and even arithmetic without ever directly contradicting that original mistake, which becomes a premise for the entire conversation. In a world where "Life is a journey" has four syllables is an axiom, it is actually correct that 1+1+1+2=4, Incidentally that conversation also demonstrates what I like to call mirroring. Not only does ChatGPT pick up on the content of the prompts you give it, it will also notice and start mimicking text features humans aren’t normally even conscious of: like patterns of writing style, word choice, tone, and formatting. This can be very powerful once you become aware of it, but causes issues when starting off. If you want a specific sort of output, don’t model an opposing mode of conversation in your inputs. If you want the maximize the model's openness to admitting (and embracing) that its previous statements are wrong then you should model open mindedness in your own statements. If you want it to give intelligent responses then talk to it like someone who understands the subject. If you want it to be cooperative and polite, model diplomacy and manners. I actually think it is worthwhile regularly saying please and thank you to the bot. Give it encouragement and respect and it will reciprocate to keep the conversation productive. (Obviously there are also tasks where you might want the opposite, like if you were having the AI write dialogue for a grumpy character. Mirroring is powerful.)

I'm happy to present my first FM, The Spider and the Finch. There may be a spider, but no ghosts or undead. It should run a couple hours. It's now available on the Missions page or the in-game downloader. Many thanks to the beta testers Acolytesix, Cambridge Spy, datiswous, madtaffer, Shadow, and wesp5 for helping me improve and making the mission to the best of my abilities. This would not be have been possible without Fidcal's excellent DarkRadiant tutorial. Thanks also to the many people who answered my questions in the TDM forums. Cheers! 2023-12-13 Mission updated to version 3. Fixed a bug where the optional loot option objective was not actually optional. Updated the animations for Astrid Added a hallway door so the guards are less likely to be aggroed en masse. 2024-05-31 Mission updated to version 4. Adjusted tower guards Added voices for conversations Improvements to objectives 2024-07-12 Updated to version 5. added dialog subtitles small bug fix

Hey there, I've been making a map for a few months now, and am finishing up with polish before I can pass it off for critique. One thing I want to fix is making it so that an instance of the model the_hammer_small1.lwo can highlight when frobbed, as the goal of my map is to steal this particular item. I understand that this particular model wasn't intended as a loot item (as I had to make it an atdm:loot_broach entity), but I figured getting a highlight wouldn't be too much work. Several hours later, I'm ready to pull my hair out. I've managed to make a .mtr file: sk/the_hammer_small_highlight { metal diffusemap models/darkmod/props/textures/thehammer_small_bronze_d_ed { if ( parm11 > 0 ) blend add map models/darkmod/props/textures/thehammer_small_bronze_d_ed rgb 0.15 * parm11 } } As well as a .skin file, which is showing up in DarkRadiant: skin small_hammer_highlight { model models/darkmod/decorative/statues/the_hammer_small1.lwo sk/the_hammer_small_highlight models/darkmod/props/textures/thehammer_small_bronze_d_ed } However, the texture used in editor and the game isn't the bronze texture that I've specified, which makes me believe there's an issue with the .mtr file, either in its being read, or its syntax. Would someone be able to explain to me how to get this working? Much appreciated!

Here's the pre-release build 3.1.0pre2 After this pre-release phase I'm going to consider doing this differently, like pushing out the releases more regularly, skipping the "beta" phase. It's a lot of work putting the pre-releases together, and I'm somewhat tired of it. What's new: The Texture Tool got its Free Scale operator now, allowing you to fit the texture with the mouse instead of having to type in the percentages. A lot of work went into the Declaration handling (EntityDef, Skins, Materials, Particles, etc.), which is now much more robust and more conformant to how the game is doing things (at least until TDM 2.10). The Material Editor got a plethora of issues resolved Improved the Model Export dialog and options For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/12zKwbeesRIMP7DNeGd0znGl5xqBVrrPX/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/12u5YtpDvpIPL7cR8EPdIIFcnjx9TzpCe/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 3.0.0 can be seen on the Bugtracker changelog, here's the summary: #6065: Feature: DR doesn't consider wildcards in skins #5503: Feature: Reload Images #5805: Feature: Texture Tool free scale #6021: Feature: Add "Show Definition" to all ResourceTreeView instances #6003: Fixed: "Reload Defs" doesn't remove entities that have been commented out #6007: Fixed: 'Reload Sounds' doesn't load new FM sound shader definitions #5504: Fixed: Reload Defs is not sufficient for reloading modelDefs #6035: Fixed: Models are reset to origin after reloadDecls #6064: Fixed: Skin Chooser doesn't preselect non-matching skins #6062: Fixed: Moving speakers deletes distance spawnargs if they're the same as in shader #5988: Fixed: Unable to select func_emitter with particle attached #6000: Fixed: Particle Editor Preview lacks vertex colours in lighting mode #6061: Fixed: Particle effects still visible when hidden via layers or filter #6036: Fixed: Entities referring to modelDefs should use the "idle" pose where possible #4910: Fixed: DR does not parse materials in def files #5982: Fixed: Modifier Hint Popup can crash when hitting Ctrl/Alt/Shift keys during shutdown #5981: Fixed: Insignificant digits displayed in Surface Inspector shift/scale/rotate values #5727: Improvement: Skin Chooser: show in which .skin file the skin is defined #5977: Improvement: Declaration Block Parsing overhauled #6023: Improvement: Python Interface for IDeclarationManager #5972: Improvement: leave player start entity selected after placemen #6066: Improvement: Let Map Info show materials used by models #6073: Improvement: Renaming Declarations causes problems when saving it later #6057: Improvement: Light Texture Preview should display editor images if present #6002: Improvement: Remove comments about particle generator in .prt files #6071: Material Editor: New Material is locked if the default unnamed name is already in use #6031: Material Editor: allow to delete materials #6054: Material Editor: image browser's "cancel" button rewrites the material source text #6030: Material Editor: does not save manual edits to source text #6055: Material Editor: should show .mtr the material is defined in #6069: Material Editor: after "Reload Images", image previews are only updated when selecting a different material #6050: Material Editor: suboptimal preview for cubeMap materials #6042: Material Editor: preview object doesn't have smooth shading #6043: Material Editor: preview doesn't take "scale" into account in Textured Mode #6053: Material Editor: blend add stages are rendered separately in preview in lighting mode #6059: Material Editor: test frob highlight button not working #6045: Material Editor: doesn't remember settings from previous session #6046: Material Editor: image thumbnails use "scale" keyword from previously selected material #6056: Material Editor: frob highlight stage not updated correctly when changing diffusemap #6049: Material Editor: using Escape to close ignores unsaved changes #6051: Material Editor: Global Settings should be preselected #6052: Material Editor: some declaration text is lost while editing#6047: Material Editor: clicking "cancel" when selecting a light classname clears the classname field #6034: Material Editor: new materials always sorted last #6033: Material Editor: filter for image browser #6037: Material Editor: can't unlock editing on materials in "Other Materials" folder #6029: Material Editor: tries to save materials in DarkRadiant folder if no FM is installed #6048: Material Editor: allow to change preview backgroun #6040: Material Editor: preview renders shadows for noshadows materials Changes since 3.1.0pre1 #5997: 'Export selected as Collision Model' doesn't auto-create path folder and throws error #6013: Model exporter: manually enter export origin #6012: Model exporter: export origin choice should use a radio button #6014: Model exporter: only 1 entity's model is reloaded #6011: Model exporter: "Use entity origin as export origin" still uses map origin #6015: Model exporter: rename "Center Objects around Origin" Thanks for testing, as always!

in DoomRadiant if you stretched a patch mesh (pmesh) but you elected a "normal" projection in the texture settings of the pmesh you would end up with the texture un-stretched, a completely planar projection of the uv's of the stretched pmesh over the texture plane, with DarkRadian though, if you stretch the pmesh you always get a stretched uv's that result in a stretched texture. is there a way to get the planar projection while stretching the pmesh?

Yeah ok, but it still needs a solution, no? Otherwise it cannot be used. I was thinking maybe you have to add a border to the texture.

real life example from tomazquake byte particle[32][32] = { { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 4, 5, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 4, 7, 13, 16, 13, 8, 5, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 3, 7, 9, 12, 18, 26, 30, 27, 21, 15, 11, 8, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 3, 9, 17, 22, 26, 31, 37, 42, 40, 36, 29, 25, 19, 11, 5, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 2, 7, 17, 28, 34, 38, 43, 52, 59, 57, 52, 45, 39, 33, 26, 16, 7, 1, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 1, 6, 15, 26, 36, 45, 53, 62, 73, 80, 80, 73, 65, 56, 47, 38, 29, 17, 6, 1, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 1, 4, 13, 25, 34, 45, 59, 73, 86, 98,106,104, 96, 86, 74, 61, 51, 40, 29, 14, 4, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 3, 10, 22, 32, 43, 57, 76, 97,117,132,141,138,126,111, 93, 77, 63, 50, 38, 24, 10, 2, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 6, 15, 28, 38, 52, 70, 94,123,155,179,191,188,170,143,117, 94, 75, 60, 46, 33, 18, 5, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 2, 7, 21, 33, 45, 61, 82,112,152,196,226,237,234,217,184,146,114, 88, 68, 52, 39, 24, 8, 1, 0, 0, 0, 0, 0}, { 0, 0, 0, 4, 12, 26, 38, 52, 70, 96,134,183,228,250,255,253,246,220,175,131, 98, 76, 57, 43, 27, 10, 2, 0, 0, 0, 0, 0}, { 0, 0, 0, 5, 16, 29, 41, 57, 78,107,153,208,246,255,255,255,254,240,197,143,105, 80, 60, 44, 28, 10, 2, 0, 0, 0, 0, 0}, { 0, 0, 0, 6, 18, 32, 45, 63, 85,117,163,218,250,255,255,255,255,245,205,151,109, 82, 61, 44, 29, 11, 2, 0, 0, 0, 0, 0}, { 0, 0, 2, 10, 25, 37, 51, 69, 89,118,158,208,244,255,255,255,253,238,196,147,109, 82, 61, 44, 29, 11, 2, 0, 0, 0, 0, 0}, { 0, 0, 4, 14, 28, 37, 50, 64, 81,105,136,179,221,244,250,248,237,211,170,130,100, 77, 58, 43, 28, 10, 1, 0, 0, 0, 0, 0}, { 0, 0, 3, 10, 21, 31, 40, 53, 67, 86,112,145,183,210,218,212,196,169,137,109, 86, 68, 52, 38, 23, 7, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 3, 10, 22, 34, 43, 54, 69, 90,116,142,158,161,157,145,128,110, 90, 73, 58, 44, 31, 16, 3, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 4, 14, 26, 35, 43, 55, 72, 92,109,115,115,113,107, 99, 88, 74, 60, 48, 36, 21, 8, 1, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 1, 7, 15, 24, 33, 43, 57, 72, 83, 86, 86, 85, 83, 78, 70, 60, 48, 37, 25, 10, 2, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 1, 6, 13, 24, 33, 43, 53, 60, 63, 63, 64, 62, 58, 51, 44, 35, 25, 13, 4, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 1, 6, 14, 24, 31, 39, 43, 43, 43, 44, 43, 40, 35, 30, 22, 12, 4, 1, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 1, 5, 11, 19, 27, 30, 29, 29, 30, 29, 25, 21, 15, 8, 4, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 1, 3, 8, 14, 16, 16, 14, 15, 14, 11, 7, 4, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 2, 4, 5, 5, 4, 5, 4, 3, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}, }; the funny thing is if you open a texture in say notepad and copy all the comma seperated numbers in there into a construct like the above you get the same result as actually loading the real texture, cool eh

hehe reminds me of some of the tricks we used in quake with hard baked textures -> byte texture1[sizeof x coordinates][sizeof y coordinates] = { ungodly amount of numbers representing the texture data, comma seperated ofc. }; then simply load the byte representation into the texture loader and voila . most of the times these were used for particle effects, but you could do any number of things with them

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?

not sure though i wonder if an allready pricey model would have become less attractive if they included an oled ?. thats not to say its good practice to leave buyers unaware , in retrospect if it had not been for the good reviews i would have seriously considered turning it back.

This just started today with my update of SVN to 15737/8388 followed by a rebuild. Some textures (not limited to the door texture shown) are painted black in-game. (Working fine prior to the latest update.) For textures on frobable items, normal highlighting appears when the item is frobbed. For textures on non-frobable items, the texture remains black regardless of distance from the object. Backing away to turn off highlighting paints the texture normally. Anyone else seeing this?

I dom't use it, i found it here with the filter set to OpenSource. the TOS and PP isn't excluding for an OpenSource app, if they use ads mean that they also need to pay an server for this online service. OpenSource is not synonymous with free either, perhaps after the beta phase it is no longer free, so perhaps you can take advantage of the fact that it is still free to create a series of textures that can be used or search another one in Futuretools. AI generated textures and assets, by definition, don't have any copyright, so you can use them as you want. https://www.futuretools.io/?pricing-model=free|open-source&tags-n5zn=gaming

Sorry I have no idea, I did find a review for the 15.6" model from a few years ago that said IPS if that's a help

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.

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.

Anything collection of polygons can be a collision model. It just needs a collision texture. To convert a non-solid visual model to collision, replace the texture with a texture that has inherent or explicit collision. To make a collision model visible in DR? Re-Texture it with a visible texture or skin. Beware of nonsolid entity arguments that override the collision texture. See also "surface parameters": https://modwiki.dhewm3.org/Global_material_keywords_(Doom_3)

Stone 24pt Font Upgrade, May 9 2024 Interim Release This first release just clears away some of the low-hanging fruit, while buffing the new datBounds program. In summary - stray mark next to W removed poor spacing of J and AE improved 6 characters got accents added. The download is made up of: .dat and 2 .dds files, for distribution/game inclusion .ref [with changes annotated] and .xcf [master source GIMP project, including datBounds layers] 2024 May 9 Stone 24 Interim font update.zip The changes were also doubled-checked using the testSubtitlesANSI FM. As this work continues, with an interim release approximately monthly, characters to be fixed will be chosen seemingly "at random", but actually due to layout considerations... you don't want to know. They'll all be done eventually. Details of Improvements: