HMart

Oh never knew Doom 3 editor lacked prefab ability, one reason DR got so popular then, prefabs are awesome. I never used inhouse Doom3 editor, besides trying it for a few minutes but DR felt better to me, so I used that. Custom DR prefabs, do work in Doom 3, obviously TDM ones will not. I did used prefabs in Doom 3 for some things, like wall lamps and such, where I connected a model, a light and a particle effect for example. Never looked at the DR source code, but behind the scenes I bet the entities are just being bound to each other and that Doom 3 supports fine. About the topic, I would love to help the person but like i said, I never used inhouse Doom3 editor, so I can't really compare behaviors between the editors. And what you said sounds totally reasonable.

Are you talking about the prefabs? If yes, afaik DR supports prefabs well, so if you are getting issues with that, could be because you are importing the model/entity not the prefab itself? To use prefabs (pre-fabricated complex group of entities) you need to right click on a 2D view and click on "insert prefab". If you are already doing that and it still doesn't work, then is probably some prefab that got outdated/broken, if so, please do a bug report for it. https://bugs.thedarkmod.com/my_view_page.php

That is very surprising, idDebris imo was a very useful entity, not only for projectiles, thou this "flinder" class apart from the physics seems to be the same thing, thou I was unfamiliar with that word. Also probably idDebrie add code that couldn't be transferred to standalone TDM or something. I would love to give better help because I do think more destructibility for TDM objects would be cool, but unfortunately I did that stuff so long ago that I totally forgot how I disabled the physics. I went to look at the Doom 3 idDebris c++ code and saw nothing directly that says "disable physics" but I did saw something in Entity.cpp, a function called RunPhysics() that is also called by idDebrie class, and on there, I saw a particular entity flag, one called "fl.solidForTeam", that sounds like it controls physics for entities in the same "team" and that is probably what I used. So I imagine that there's a way to negate this flag through scripting? try writing a entity spawnarg "solidForTeam 0" on the flinder objects in the editor.

I solved that issue by disabling collision between the peace's, if you see on the video I posted they don't collide with each other only the environment. Is not perfect I know, nor realistic but imo is better than making sure they spawn separate, prevents you from making them spawn in place for example, to make the break more realistic and also saves on performance what its a bonus imo, because gives you the option to put many breakables in the same space. And many comercial games used this trick as well and probably still do thou I have not being paying attention.

have you looked at the "colored" stage keyword? Not sure about TDM but some Doom3 materials use that to create different colored objects, that share the same material and textures. from here: https://iddevnet.dhewm3.org/doom3/materials.html there's also: https://modwiki.dhewm3.org/Colored_(Material_stage_keyword) About a tutorial I don't really know one, so I hope this is enough hints to get you going. What I did and always recommend is to take a look at Doom 3 materials (and why not TDM materials) and see how they did it.

cvarName [X] Sets the value to X if the variable exists. set cvarName [X] As above, but creates the CVar if not present. seta cvarName [X] As above, but also stores the CVar value in [game]config.cfg so that it will be the default value. Never use seta on the command line! from here https://modwiki.dhewm3.org/Console

idTech4 engine has used on Doom 3 already had a destructible entity system for the destructible barrels, was that removed? In Doom3 you can create debris entities and they become physics entities, never heard of this "flinder" stuff so I assume is a new TDM entity type. Don't know if this is useful for TDM, if not ignore, but who knows could give some hints. This was how I created a simple destructible wood barrel in Doom 3 engine. First I defined the broken debris peace's: (yes they are individual entities and models) entityDef debris_woodbarrel_1 { "spawnclass" "idDebris" "mins" "-3 -3 -3" "maxs" "3 3 3" "model" "models/maps/temple/mapobj/pipo broken/pipo_debri_1.lwo" //"skin" "skins/exp_barrel_red" "health" "0" // amount of damage projectile can take if damaged (0 means it can't be destroyed) "velocity" "1 1 450" // how fast the projectile leaves the gun (or distance if fuse is 0) "random_velocity" "1" "angular_velocity" "105 215 10" // how the projectile is rotating when it leaves the gun "thrust" "0" // the rate of acceleration (always in the direction of the projectiles model) "thrust_start" "0" // when to start accelerating "thrust_end" "0" // when to stop accelerating "linear_friction" "1.0" // "air" friction "angular_friction" "0.1" "contact_friction" "0.9" "bounce" "0.1" // how much speed a projectile retains when it bounces off of objects (coefficient of restitution). 0 means no bounce. "mass" "50" "gravity" "1066" // how much gravity affects the trajectory. gravity direction is same as the entity that fired it. "fuse" "10" // how long before the projectile is removed or self-detonates. Use 0 for beam weapons (velocity == distance). "detonate_on_fuse" "1" // whether projectile should detonate when it's fuse runs out "detonate_on_death" "0" // whether projectile should detonate when it's "killed" (health runs out) "detonate_on_world" "0" // whether projectile should detonate when it hits an obstacle "detonate_on_actor" "0" // whether projectile should detonate when it hits a character in the game "smoke_fly" "debristrail.prt" // particle effect while in the air "snd_bounce" "tray_impact" // parametric particles -- temp "model_detonate" "" "smoke_detonate" "" // particle effect when detonates "smoke_fuse" "" "smoke_bounce" "" } entityDef debris_woodbarrel_2 { ... } etc, then I define the main entity: entityDef moveable_woodbarrel { "editor_color" "0 .5 .8" "editor_mins" "-16 -16 0" "editor_maxs" "16 16 48" "editor_rotatable" "1" "editor_usage" "Moveable woodbarrel. Works just like a func_moveable. However the barrel" "editor_usage1" "has special handling to make it appear more round. This version also explodes when damaged enough." "editor_usage2" "Only add model, model_detonate or model_burn or health to override defaults" "editor_var burn" "number of seconds to burn before exploding." "editor_model model_damage" "model to leave as damaged base" "editor_model model_detonate" "ips model to switch to for explosion." "editor_model model_burn" "ips model to show when on fire." "editor_var def_debris" "add as many as you like, debris1, debris2, etc.. " "editor_var health" "how much health the barrel has, default is 5. If burn is set to 1, the health is effectively doubled so you have to kill it twice to get the explosion" "editor_var respawn" "if non zero the number of seconds to respawn after killed" "editor_var respawn_range" "no player in distance range to actually respawn - default 256" "editor_var respawn_again" "try again in seconds if player in range - default 10" "editor_var triggerTargets" "if set to 1 will trigger targets after being killed" "editor_mat mtr_lightExplode" "light shader to use for explosion" "editor_mat mtr_lightBurn" "light shader to use for burning" "spawnclass" "idExplodingBarrel" "density" "0.02" "friction" "0.2" "bouncyness" "0.4" "def_splash_damage" "damage_moverCrush" "ignore_player" "1" "model" "models/maps/temple/mapobj/pipo.lwo" "def_debris" "debris_woodbarrel_1" "def_debris1" "debris_woodbarrel_2" "def_debris2" "debris_woodbarrel_3" "def_debris3" "debris_woodbarrel_4" "def_debris4" "debris_woodbarrel_5" "def_debris5" "debris_woodbarrel_6" "def_debris6" "debris_woodbarrel_7" "def_debris7" "debris_woodbarrel_8" "def_debris8" "debris_woodbarrel_9" "health" "35" "snd_explode" "wood_barrel_breaking" "snd_bounce" "woodimpact" } This was the effect: https://drive.google.com/file/d/1lsXwNssxp-QO3MZKOmUiBd1DWhd0V7HY/view?usp=sharing Hope this helps.

Parallax Mapping can look odd in curved surfaces, if they have a strong curvature, about seams there's nothing people can do at the technique level (that doesn't destroy performance), is a limitation of the technique but is possible to hide them with other geometry. Parallax Occlusion Mapping, can look very good but is a visual illusion and doesn't really tesselate a surface, so is best to have in mind its limitations and strengths to better take advantage of it.

To me 8x is more than enough, if you play at 1440p IMO 2x is enough and at 4k there's no need for it. This game uses old school MSAA that is not a post-process AA system, like most modern games now use. In simple terms, MSAA is a faster super-sampling system, instead of super sampling the entire image (rendering at higher res and down sampling) and so destroy performance, MSAA instead uses the geometry edges, to only give more pixels to 3D models borders and nothing else, so is way faster than real SSAA while being able to remove a large amount of stair-steping artifacts, but there's a issue with it, the reason MSAA as been deprecated, is because it will not anti-aliase transparencies and textures and pretty much all modern games, is all about shaders and textures. IMO for those wanting more performance and still wanting some aliasing mitigation, disabling MSAA and instead forcing a post-process AA like SMAA or others, though reshade, is the better curse of action. Btw almost forgot, the reason MSAA is so performance intensive on this game, is because it does real time lighting and pixel shading, per pixel, every frame, so the more frames you give it, the more pixels you give it, the heavier the lighting becomes and MSAA increases pixel count.

peter_spy is right specular maps don't necessarily need to be gray scale, Doom 3 has plenty of specular maps with color on it, see in the base/textures/hell folder for examples. And I have used specular maps with color before as well. A Quake 4 tutorial that imo shows how color in specular maps can be usefull. (hope the link works for all...) https://web.archive.org/web/20160321000657/https://www.iddevnet.com/quake4/ArtReference_CreatingModels#head-4152af2ebdcdf51e21eaf84fd7ea3f511a7a1fab

Yep shows how old some of my knowhow is, thanks for the update. Btw I did read something about AMD 3Dc format for normal maps being better than dxt5 ages ago, but was a AMD thing so I mostly ignored it and used normal DDS dxt5. Also reading this, it seems 3Dc, is BC5 and is not very different from dxt5! http://wiki.polycount.com/wiki/3Dc Is that correct?

Afaik both are correct, I was taught to use dxt5 for normal maps

Not surprising to me, this is a influx code base, being updated and messed about everyday and messing with peace's of code written decades ago and not really thought to run or work on the ways we need them to work today, like the collision code. It was made for a 60hz locked fps game, TDM is now pushing it beyond its original design parameters. Unless is a old bug that even idSoftware itself missed... About if C++ will ever have Rust like compiler abilities. Personally I pretty much doubt it, they will implement some things to make it safer (like they implemented smart pointers) but to be like Rust, it would need to be a very different language. Because of this thread, I went to read more about Rust and saw a video where a Rust person said that C++ to be able to become a "safe language", would have to, 1 - totally remove pointer arithmetic 2 - totally remove pointers and references 3 - remove new and delete (aka manual memory management) this sounds like it would totally break C++ and be a very different language, you better name it something else at that point.

First I'm not from the TDM team, I don't speak for them and this is only my opinion. Now this game has been in development for more than a decade and the engine has been in C/C++ for decades more and has been very successful and very stable, specially because the main programmers, were and are excellent programmers, why all of the sudden do you think this game needs Rust for "memory safety"? Do you think the game is constantly crashing for people because of memory overflows or memory leaks? Why are you assuming the people working on this engine, are incapable to managing memory? If you want to interface Rust with C++ and DoomScript for performance telemetry or for web debugging or whatever you were doing, go for it, as a player, I would prefer if you spent your obvious coding skills, doing more productive things for the game itself, like improving or bringing new engine features or improve the tools, but do what you want to do. And please don't take this as an attack, or as if I'm against bringing Rust or any other programming languages for TDM, that is not the case and if I was, I'm not from the team anyway so you can ignore my opinion, but please, don't assume Rust is necessary to make TDM "memory safe", because that to me, is like accusing the programmers that worked on this for decades, of not doing a good job managing memory and IMO they did, a excellent job, even using a "unsafe" language. Just my two cents.