HMart

What model it is? I can inspect it in Modo if you want. Btw is not only two sided faces that duplicate vertices, for smooth shading, using hard and soft edges and if I'm not mistaken, smoothing groups like in 3DS Max, literally cut the model at the edges marked has hard at export time, so duplicating and overlapping vertices.

non uniform scaling will most probably deform the model to much and make it look bad, but no harm in trying. About the texturing, the same has the model, it will stretch the texture and imo make it look bad. DR has a nice feature in that it can unlock/decouple the textures, from surfaces, by disabling "Texture Lock" the lock icon at the top icon menu UI, this makes it so you can move and scale surfaces and the texture will stay put but unless I'm missing something this only works for brush surfaces, not models imported from a outside tool or even made on DR and converted to ASE or LWO, for those, you need to open the model in Blender for example and resolve the UV stretching there.

Hum if Pascal8888 GPU is a Nvidia one, then it is evidence that the Bindless Textures causing problems, is not only a AMD driver thing.

Yes that is true but if you make it only show the HD model relatively close to the player than the number of HD models visible at a time, will be low, so it should help. About scaling down the model, I hope you know that it will have zero affect on the triangle count? But thinking about it, it does make the model take less screen space and so, few pixels needed to render it and it also increases the probability it will not be lighted by many lights at the same time, so perhaps there's something to that trick but I don't believe the performance gains will be comparable to LOD's, imo is still the best option, with the benefit that at close range the player will see a HD model, instead of always the same model at all distances.

IMO use TDM LOD (level of detail) system, meaning at far distance the HD models will change to the low poly ones no need to make new models.

Option 2 is the right one, no need to negotiate a license with Bethesda and like you suspect, I also don't think they would even license it anymore, afaik none of the idtech engines can be licensed now, they are exclusive to Bethesda own studios.

Hello Cecil of Cynope others already said much of what you wanted to know but here is a example of a comercial game being made on idtech 4 and using Dark Radiant as their tool of choice for levels. Skin Deep You can just do the same.

Thanks roygato, will try those when I have the chance.

Surveillance tech like this has the potential to help many people and also the potential to give the power to bad governments to suppress dissidente voices, like all tech has bad and good things, everything can be used to harm, we just need to mesure if the bad outweigh the good and personally, I don't know if it does in this case. For example, Cellphones are used has surveillance tools, I know of two cases were people were arrested after a serious crime, because of evidence found on and because of their cellphones, so how many here are in favor of the ban of cellphones?

Does anyone know on what AMD driver this feature worked? I tested on 21.3.2 and 21.4.1 both displayed the problem, would like to try one that works but would also like to avoid installing drivers at random and see what works or not. Btw if anyone with a AMD GPU haven't done it yet, I recommend using the bug report available in the driver GUI at the top right corner, I did it, don't know if they will care for a free game like TDM but there's no harm in trying to report it and imo the more people that do it the chance of them taken notice is higher. There's also Terry Makedon or something in twitter, afaik he is the driver department manager, he posts about the AMD drivers in his tweeter account, so could be a nice place for a bunch of us to report this to him, visibility could make them prioritize a fix.

I totally agree with OrbWeaver. Today I fired TDM up after a long hiatus, only too see this problem and I also have a AMD GPU a RX 570X, tried two different driver versions same problem, so I assume is not a driver problem but seems to be a case of bindless textures not working correctly on AMD GPU's. IMO it should be a option for Nvidia users on the menu, perhaps with a warning/hint that it may or may not work on AMD/Intel hardware. Btw the more I read about this particular feature the more I see Nvidia mentioned on it, making me think that this is a case of Nvidia tech not playing well in their competitors hardware. I think so, because of the following two things, is a old discussion so maybe very outdated but on the khronos forum someone says, that BT is a Nvidia patented feature and on the khronos OpenGL wiki it says "This is not a core feature of any OpenGL version; at present, it only exists as an extension." a NV_ extension plus a ARB_ one, if true that is a extension to OpenGL and one by Nvidia, no surprise it has problems on AMD, afaik both it and Intel are known for only optimizing for OpenGL core features and their own extensions, it also says "both AMD and NVIDIA have a lot of hardware that can handle it" but based on what is happening here, I don't think that is entirely true, at lest on the AMD side and perhaps Intel.

Afaik "the player" for the AI is not the visual mesh, is the invisible bounding box that encompasses the visual player mesh, so even if the player may be totally hidden by the pillar, his bounding box may not.

Perhaps is not this at all but just in case, if you don't know, lights have a light_center, from where light is "cast", for point lights it is normally (0, 0, 0) meaning at the center of the light entity, relative to the light entity "space". In DR for point lights, afaik you cannot edit this origin, in the 3D or 2D views but you can do it, in the entity tab using the spawnargs, so perhaps, someone changed the light_center from (0, 0, 0), if is even a point light, to something else or created the light programmatically, so again perhaps the light_center, is not at the normal light origin but far away and poking into the other room?

For walls idSoftware always recommended 8 or more, even for detail walls.

You are right, there's a slight flaw in the system but even thou the light maybe entity zero the c++ code only considers the entity, the world entity, if it has this particular spawnarg, that lights don't have. So even if you create a light first and a worldspawn brush second everything should work fine. else if (!idStr::Icmp(key, "classname") && !idStr::Icmp(value, "worldspawn")) { worldent = true; } I bet idSoftware never cared to have a test for that error because all their level designers, first create a room than create all the other entities and that is how they have been doing since quake or even the first doom. Plus this kind of problem seems to be so rare that in decades following idtech 4 scene this is the first time I saw someone cause such a error. ps. Btw nothing gained from creating a light first, because lights only work if they have some surface to interact with, if no surface will just be a black void no matter how many lights you spawn.

That sure makes more sence to me now, that would be what i would do has well.

Ah ok thanks, not that I have much confidence on windows but makes me more relieved that is not worse than Vulkan, there's not much around but I've yet to have a vulkan game/demo crash windows and for now, I don't see anyone complaining about that in TDM, so that is also a good sign.

I said almost the same thing to him Destined, in another thread, what I got in return was imo scorn. To me not a good start in this community.

Was reading about bindless textures to know what they are and saw this: Is that really that unsafe?

The engine is not mine sir "I am an experienced tester..."

I didn't realized you were talking about a single room, in my mind I though you were talking about your entire map so my bad. But even so be carefull, If your room is relatively small and square shaped, I don't think theres any problem. I learned to map by doing it, even thou I never released a TDM mission or anything of importance yet, I did spent many hours, just messing around with DR not going anywhere but it did permitted me to learn but you don't really have to map to know what I said, I'm following the Doom 3/idtech 4 mapping scene for decades now, I learned many things along the way. Springheel far from me to try giving you a lesson, you certainly know your craft well more than me. But just to clear some stuff to me, what you said is totally true, entities don't seal the void and you need worldspawn geometry to seal against it but IMO even thou it works fine in most instances, I'm I wrong in assuming that if, for example, you create a cross shaped corridor + and you just make a sealing room around all that, it will cause problems with AAS, sound pathing and cause light leaks, all because you will not be able to portalize (is that the word?) the corridors?

The programmer of this game is not a single person... I also work with idtech 4 and have many experience with it but that doesn't mean what I know serves or works in DarkMod, why, because it doesn't use the original Doom 3 engine, it has been changed in many aspects. You shouldn't expect, all console cmds that worked in Doom 3 to still work, they could be dead code that was just not removed, even the original idtech 4 engine has console commands that do nothing, console cmds are very volatile and change or get deprecated during development. You also shouldn't expect this game to work, in your PC like Doom 3 did, why because, it has a relatively modern render, using GLSL 3.0+ I think and doesn't support old GPU's that Doom 3 supported fine. Having said that there's no harm in telling the darkmod team that some commands don't work, perhaps they should but have in mind what I said above.

If the tutorial teaches that then, it is teaching a bad behavior, you should never solve leaks, by just making a "room" around your map, leaks are VERY important to catch, if a map has a leak, the engine portal system will fail to properly occlude geometry, sound and light and the map will run like garbage, have sound going through walls and light leak into rooms it shouldn't, causing visual and auditory glitch's. Another thing that causes leaks is the origin of models being in the vacum, the origin IS NOT where the model is visually, the origin is a invisible point, used by the engine to know where they are and place models around, even though a model may be visually inside a room, its origin may be not. When you select a model, its origin shows up as a gizmo shown as Red, Green, Blue lines (x, y, z) coordinates, if you select a entity and don't see the gizmo, then it means the origin is far away from it.

I will not jump immediately 100% to the side of Frogwares, like many here, why, because this seems really suspicious to me, Nanco left huge clues behind, like they didn't care if they got caught, is if they are very sure they will win any law suit frogwares throw at them and that maybe because of something we don't know. We only heard one side here. But don't think I condone the behavior or any publisher stealing developers.

stgatilov I know this will increase coding complexity and work but couldn't you guys do that automatically in the background, when the user brings the rez down in the menu? IMO it would totally eliminate this complains. So I would remove the resolution scale from the menu to minimize confusion, keep the "old school" resolution option but when the user is messing with the rez they are in reality messing with the rendering scale, the rez label is just a front to hide the truth but to the final user the visual effect should be the same, what do you think?