HMart

Not only that but IMO today with Nvidia AI frame generation (or any equivalent tech that AMD may eventually come up with), frame rate numbers lost all their meaning (at lest with frame generation turned on), with DLSS3 FG you can have a "60" fps game that can feel like a or less than a 30 fps game ( on input lag and if that is the base frame rate from where DLSS AI is working from). High frame rate numbers are a good way to sell GPU's ...

I'm sure they will create a stable 2.12 version, when its done! But the official game release is at version 2.11! The 2.12 is still in heavy development and so, will have bugs and most probably break very easily, it shouldn't be used for real play, only to help TDM code team, to test, find bugs and regressions. This dev version is accessible to the general public, only by courtesy of the TDM team, so we can experience and see how the game engine is developed, bugs and all, don't make them regret it, if more people start complaining, instead of helping, they will more than likely closed it behind doors, like they did before and do the public testing, only way later when is more stable. But that also makes it longer to release, because they will have less people testing, will have to do most of the testing themselves and because, afaik 1 or 2 people, are working on the engine at the moment, it will take way more time to develop and then test to the final release. And it will very probably come with more bugs, than if they did early public testing like they do now. Unlike paid comercial developers, TDM team doesn't have a dedicated paid bug testing team, we the players are the tester, is the lest we can do for be giving this fantastic free game. And so IMO complaining the development branch is not stable, doesn't help, they know that, if you want a more stable version and not experience bugs, then use only the oficial 2.11 release, wait for the final oficial 2.12 release, again, when its done.

I was thinking about this the other day, after seeing that Source engine add a func_occluder entity, while idTech4 has not, Valve at lest thought they were still useful for something, I bet they are used to help optimize the HL 2 outside areas, that game has plenty of those. That lead me to search about the subject and saw this two links, imo they have some useful info. https://www.gamedeveloper.com/programming/rendering-the-great-outdoors-fast-occlusion-culling-for-outdoor-environments https://bazhenovc.github.io/blog/post/gpu-driven-occlusion-culling-slides-lif/

Then is something else thanks for the info.

Just for curiosity, If any of you are running with unlocked frame rate, lock the game to 60fps (or 60hz) and see if the problem goes away?

I comprehend but you do lose volumetric effects with stencil but only the really recent missions have volumetric lights. Btw In reality there's a big difference between what shadow maps are capable off and stencil maps are capable off, unfortunately because of backwards compatibility with old missions and the fact that for a long time, only stencil was available, TDM team add to limit shadow mapping capabilities mostly to what stencil can do.

MSAA is heavy specially at 16x because is more or less a type of super sampling (rendering the scene at higher rez than displayed), but unlike the later is way faster, but like SSAA, MSAA still increases pixel count. Yes i'm not surprised AA was the main culprit good it was not something else. Btw Stencil shadows are mostly CPU based, shadow maps are GPU based and because you were already GPU bound, changing to to maps wouldn't make any diference, perhaps even make it worse, because maps are normally slower than stencil, thou today because of some exclusive effects to maps, I would recommend them to everyone.

Then the problem is also the material, yes. I would assign a opaque dark material, to the inside faces of the light housing, minus the glass front, so they don't blend with the background.

Was this model made in DR? The uvmap is all over the place, meaning it falls outside the 0 1 area. But that is not the problem, the problem is that It add a missing face in the back of the lamp thing, so you could see to the outside thought it. I put a face there that should solve the problem. mod_playerlamp_model.lwo

Link the model here and I will solve that, is easy (famous last words.... ). To me no need to link the material or textures just the raw model. Btw is the model lwo? I can only open .lwo models in Modo my tool of choice.

That is slightly less than 4k but imo is still a really a high rez, specially for this engine, that is ~7.3 million pixels that the engine has to calculate/shade, per pixel 60 times or more, every second! also why MSAA (multisampling anti-alising) can be very expensive on this engine, it increases pixel count. So like nbohr1more said, if you have it on, lower it or better disable MSAA, at that rez IMO you don't need it anyway and it has no effect on geometry faces/surfaces, only on geometry edges and if you really want AA, also like nbohr1more said, force a post process one (FXAA or better if possible TAA) using the Nvidia driver. You can also try to lower the rendering scale and increase the sharpening filter to counter balance the loss of definition in the video options menu. About the CPU the fact you have low CPU utilization and high GPU utilization, shows you are getting GPU bound in this case, so increasing thread count in the game console, I don't think will help but try it. Btw sorry if you already know this but if you don't, at lest may explain to you why this "old" game, is so heavy even for your modern very expensive GPU, this game uses a modified Doom 3 engine, with better support for multicore CPU's and other modern stuff making it way faster than original Doom 3 engine, but is still using the old forward render and unlike more modern renders like deferred render or forward+, that can render hundreds of (non shadow casting) dynamic lights, before getting slow, a old forward render like of Doom3/TDM, can get really slow with a relatively low number of dynamic lights in a scene, worse if they all cast shadows, and on this game all lights are fully dynamic and in many missions most of them cast shadows, real time shadows, there's no light baking of any kind.

If dmap doesn't show a leak and there's a leak into the void (a gap in the world into the void or a model origin in the void) that is really strange, too see if is a leak and dmap somehow fails to show it, try to start your map with "devmap mapname.map" instead of using "map mapname.map" devmap afaik ignores leaks, if the map/mission opens then is a leak. But the fact that you are having AAS out of date warnings after dmap, sounds like you are opening a old version of the map not the one you dmap a new, perhaps you have DR badly setup and it is saving the fresh maps and files into a different folder than you think?

Personally I really don't know if that is available or not but that does sound too a specific guard behavior, so perhaps is not defined? If is possible to have that? Yes, if is not available already, unfortunately there's no other way but code it into the guard AI, in c++ or script yourself, if you know how to code.... Btw the civilian AI does have "fear" and runs away from danger, is that AI type really entirely separate from the guard AI, or the guard behavior is just "dormant" on the civilian AI and vice versa? If all AI's are done through the same AI system then perhaps is just a matter of turning some stuff on or off. If they are totally separate AI's, they are still so similar in parts that perhaps so you could adapt/transfer the civilian fear behavior into the guard AI for specific types of danger. But all of this requires coding. Sorry for not being more helpful than this, I really don't know much about TDM or even Doom 3 AI stuff.

Yeh that is also how Doom 3 weapons were done, but perhaps this can be worked around? Next to weaponDepthHack there's also a modelDepthhack bool I assume for every other model, perhaps that just needs to be put in the model def file or enabled by a spawn argument? I really don't know, or if that spawnarg even exists, if not then is something to put in the roadmap.

Is the lamp a weapon? Unless TDM weapon system is different from Doom 3, weapon models should have the "depth hack" thing enabled, that "hack" (that is how idSoftware calls it ) makes sure the weapon never intersects with geometry. in the code: bool weaponDepthHack; // squash depth range so view weapons don't poke into walls Don't know if there's a way to enable that without messing with c++, stgatilov or others may know.

Perhaps but the game, has gameplay features that can muffle your footsteps sounds, carpet and other ground textures, the vine arrows also, so by making them more silent/quiet, imo you may end removing the incentive, for mission makers and players to make use of those. To me, If a player thinks the footsteps are to loud then maybe the mission maker, didn't put enough ways for the player to walk more silently in the level and so he always hears loud footsteps and thinks that is bad/broken. Btw what about incentivizing mission makers to do certain things, by the older more experienced mission makers, agreeing on a small list of "best practices for mission makers" for performance, looks and gameplay and pin that at the top of the forum? Then any new developer may learn something from that and avoid some rookie mistakes, like for example, not putting enough ways in a level for a player to walk more quietly. Just my two cents.

This most be a TDM only thing, because I tried it right now and I can use volume keyword, in a sound shader, in Dewm 3 engine, to both increase and decrease sound volume. Or unless is particular to the player footsteps, I didn't tested those, will see and update this comment. Worked with the player footsteps sounds as well but I remember messing around with the c++ code to make those work. I used Blendo Games starter pack and the player system that comes with it, has the footstep system disabled, this because the starter pack has no real player model, just a floating camera. Ps- btw I add to call reloadDecls in the console NOT reloadSounds for the volume keyword to work.

demagogue to me its doesn't matter that its "somewhat right" what it wrote there, is mostly BS, is not true. Not such game mode on this game... nor this game community is called "Dark Mod", that is the name of the game. I bet the AI said that, because many indeed refere to this community online has "The Dark Mod" community but the AI totally failed to get the real meaning/context of those words. Again there's no such game mode, nor players make levels using ingame tools and resources. That is obviously marketing from some online MMORPG game or such. Again to me it doesn't matter that the intention is almost there, you and me know that because we know the game and its community, but if we were new players, the truth is, that description would give us a totally wrong idea about this game. Because players don't assume the role of builders, builders are a ingame enemy faction, players don't build anything, they play the missions and the roles of thief's or assassins', mission makers (no matter if they are themselves players) are the ones that build missions, the only thing right in that quote is " trying to avoid detection by patrolling guards". What that original quote show to me, is that the AI can write coherent frases but still be totally wrong, is just a clever mashup of cool marketing words, from other games i bet, being reused in a new context, mixed with a few correct bits/words from Dark Mod.

Soma uses Newton Dynamics (Newton 2.x or 3.x? )I know that physics engine, is very accurate, is also why it is slower than Havok and PhysX for games, unlike the others it takes very few shortcuts in its physics calculations (there the name), that made it's joints and friction handling very stable and perfect for the type of player world interaction that Frictional Games wanted for Penumbra, the fact the physics engine was so stable and rather unknown, is IMO one of the main reasons their first game was so unique and successful. Btw Newton Dynamics started as a physics engine for robotics and stuff in academia, so it needed to be accurate, the main developer of the engine, is now making a modern version more focused at games, Newton 4.x and it is way faster than the former versions, but I assume that with that speed comes less calculation stability but I don't really know.

John Carmack the main idTech 4 developer once said, "best way to mesure performance is not FPS numbers but frame timing" and I agree, we tend to mesure game performance by counting higher and higher fps's but you can have a very responsive and playable game at 30fps, if the frame timing is constant and a very lagging game if not, even if the fps numbers are 60 or higher. And today in the age of Nvidia DLSS 3 AI frame generation, FPS numbers, are imo becoming irrelevant, hardware unboxed found that with DLSS 3 you can have a game, for example show 120fps but feel almost exactly like a 60fps game (because is the speed the game is really running at, DLSS 3 is just inserting fake frames between each real one and artificially upping the frame rate).

Perhaps you have a infinite loop in one of your scrips? Infinite loops can cause freezes. But I also thought the script parser was able to caught those? Btw I don't remember ever having, Doom 3 in this case, freeze because of changing a def file (or even a script?), the worse it could happen is crash the game or cause ingame bugs but I'm not absolutely sure on this.

I don't think we need a extra PPU card not today, I'm just saying that Ageia failed, not because their competitors could do the exact same or better, without a accelerator but because they just couldn't show, or didn't knew how, the true promise of the PPU to the public, in visual terms, not in a way that non tech savy people could see it. And when some of its effects, could be made "good enough" with less physics complexity, and or faked like for example Valve did in HL2 with the baked "cinematic" physics, it add no chance. hahah Indeed Not trying to start a debate over this stuff but CPU's even modern ones, IMO aren't still capable of what even the old PPU could do, at lest I haven't seen a game with CPU only physics doing that, you are free to show me wrong thou. Agree Is like saying software rendering, everything done on the CPU is said as being done in "software" but at the end of the day, is a peace of hardware doing the calculations. We agree we disagree on this? Plus Havok is as dead as Ageia PPU today, Nvidia PhysX pretty much dominates the physics engine market. I certainly can't argue with that, totally agree. Btw Bullet physics engine made by a old Physx engineer (if I'm not mistaken) did support OpenCL acceleration on AMD and the company did showcased it but like almost AMD stuff, it didn't add any use, in gaming at lest. Btw guys sorry for the huge replies but is hard to say everything I wanted to say about this subject in a few words.

Havok never did such a thing, I know because I was a owner of a Ageia card and Havok demos or games, were never able to reach the same level of physics Ageia PhysX demos displayed. I know Ageia is now a joke and people have forgotten most of it but I experienced it first hand and let me tell you, to this day, there's not a single, Havok or Nvidia PhysX, game or demo, that to me, does what some of the old Ageia demos did, at lest not all of it, again I saw it with my own eyes and played them on my PC. Warning massive wall of text: edit: Revelator I see that you were also a owner of a Ageia PPU, that makes your comment even more strange to me, what Havok demo/game did you played that made you get that impression?

IMO there's some benefits to using "" around paths, one it permits you to put spaces in your paths (thou I don't recommend that at all), second it breaks your paths into easier strings, for the text parser to read/deal with, it also help us visually distinguish what's is what better. They aren't a rule you can ignore them but imo using them maybe decreases the probably of parsing errors. About lower case, I'm not sure but unless you are comparing strings, I don't think the parser itself cares about the case of character in a string. Thou because of portability to linux and other OS's idSoftware recommended, no spaces in folder names and no higher case letters in a path, the engine even has a warning message just for that. But like you see above, even I forget that sometimes, is why I have plenty of warnings about non portable paths in the console!

Instead of that try this to see if it works, it does on my end skins/bathroom/Tube01a_waterclean { model "models/mapobjects/washroom/bathtub_oldA.lwo" "textures/common/nodraw" "textures/water_source/Water_clear" } change the stuff for your own model/materials of course