HMart
-
Posts
1599 -
Joined
-
Last visited
-
Days Won
14
Posts posted by HMart
-
-
Yes HPL2 can be considered a nice engine for a Thief 3 plus like game, as it has full real time lighting like TDM engine and even has a better physics engine but it lacks a few cool stuff TDM engine does and it also suffers from almost the same limitations of the TDM engine, as open spaces is concerned.
I feel like a few people here really underestimate how powerful TDM engine really is, yes is old by today standards and it has almost no support for open spaces, but has excellent support for "corridor" games and a very advanced fps controller.
Just a tiny comparation of what I know about both engines, I could really compare way more but imo this should be enough to show that TDM engine isn't as basic as some may assume:
** TDM Engine **
SpoilerSpot lights with soft (or not) stencil and or shadow maps, volumetrics and projected textures.
Point lights with soft (or not) stencil or shadow maps and cube map effects.
Special fog lights, special very cheap non shadow casting lights called blend lights (just does simple Opengl blending).
Directional lights with soft (or not) stencil or shadow maps but afaik only correct shadow casting for stencil...
Dedicated Ambient lights with no shadow support, to give the level a global light brightness and color. No support for normal maps or specular in these and blend lights.
64bits color support.
Somewhat advanced dedicated glass breaking effect.
Some LOD (level of detail) support
Physics engine is very old school, simplistic and doesn't support very complex physics systems apart from ragdolls (thou you can do some cool stuff just with ragdoll support).
Support for POM (Parallax Occlusion Mapping)
Very advanced Mirror surfaces, computer screens and "portal" like effects called "Xray screens" (don't confuse with portals for visibility culling)
Pixel and Vertex Shaders are based on popular GLSL shading language
Advanced multi-threading support using a modern jobs system
etc ...
** HPL2 **
SpoilerNo stencil shadow support.
Spot lights with shadow maps and projected textures.
Point lights, no shadow support for these.
Box lights (aka Ambient lights) with no shadow support as well, to give the level a global light brightness and color. No support for normal maps or specular in them.
No 64bits color support.
No dedicated glass breaking effect.
No LOD support.
Physics engine is very advanced and powerful, with support for very complex joints and motors and other stuff like cloth and such BUT Frictional Games only implemented a part of it, so just a subset of the Newton 2.X physics engine is really available in HPL2 (similar to what idSoftware did with .lwo model support, where idTech4 only supports a tiny part of that format real power)
Support for POM (Parallax Occlusion Mapping)
No support for Mirror like surfaces, apart from basic water reflections, no special "portal" like effects.
Pixel and Vertex Shaders are based on niche, old deprecated Nvidia CG language (it does run on AMD and Intel hardware as well)
No out of the box multi-threading support.
Editor tooling is even more simplistic.
etc ...
-
2
-
-
Sorry I don't have much time to see the full video but what I saw in the first few minutes where he built a room, is nothing special, I've done the exact same workflow for example in Max Payne 2 editor.
What he means with mesh's, is that the geometry you work with inside that Unreal Engine plugin, is the same one you do when you work in say Blender, Maya, etc, is just triangles and quads. Meaning the geometry is not composed of simple mathematical planes like brush's but real 3D geometry.
Why you don't use portals in there? Because Unreal Engine 4/5 afaik have no portal system for visibility culling.
Portals are a CPU concept and are normally used to prevent to render things that the player doesn't see during gameplay, but is not the only way to do this job. I think ever since UE4? Epic's engine uses a more advanced system (but more expensive one) called GPU occlusion queries, in simplistic broad terms, it uses the GPU to do "porteling" automatically for you. btw Unreal Engine also used CPU based, manually placed portals not that far in the past.
Also the idTech4 BFG fork RBDoom3BFG engine also supports occlusion queries but on the CPU, using a Intel made library, perfect for open spaces.
-
1
-
-
1 hour ago, chakkman said:
Good call anyway. If anything, I'd try Unreal Engine. Comparatively, nobody uses CryEngine.
Don't Unreal Engine also need a account to use? The last time I tried to use it I need one to download it. Plus afaik you still need to pay Epic if your games gets profits above a certain level.
IMO to anyone wanting a totally free, totally open source, no accounts needed and with good enough tools, Godot is a good choice.
-
2 hours ago, JackFarmer said:
...
@HMart: They talk about "meshes" in this video the whole time. Theses meshes (what are they? 2D patches?) are the equivalent to DR brushes? Apparently, portalling is no thing here? Sorry for the dumb questions, apart from DM mapping I have zero experience with other engines.
I didn't saw the video so I'm not sure, but normal mesh's in pretty much all engines I've used, are those imported from 3D tools like Blender, while the own engine geometry was called "primitives" or as you know them here brush's.
Afaik the diference between a mesh and a brush, is that the former comes already pre "baked"/compiled, meaning they come already made up of triangles, while a brush is just a bunch of mathematical planes that are then baked into real triangles at level compile time (dmap in TDM).
Hope this makes things more clear.
-
3 hours ago, Filizitas said:
...
Its especially annoying because people keep trying to commercialize TDM... Give it up man. Its been 16 years. Keep this thing in community hands. TDM needs to stay standalone!Anyone brave enough can try but TDM license forbids commercialization. Also the moment that happen, it would be sued by the current Thief IP holders and taken down very fast, why? Because this game is obviously very derivative of Thief.
IMO the only reason that has not happen already, is not the goodness of the Thief IP holders hearts, is the fact this game uses different names and lore from Thief, is totally free and very important the makers of it and the people working on it, are not getting money from any other source, like Patreon for example. So probably falls into some safe "fair use" territory.
-
2
-
1
-
-
On 12/30/2025 at 11:24 AM, chakkman said:
Everything above 200 Hz is total nuts for me anyway (and I doubt that most will see a difference). Big numbers = big deal for many people, it seems.
I bet on a blind test very few people, if at all, will see the diference between 240hz and 1000hz. People don't understand but at 240hz the monitor is already swapping the frame at 4 milliseconds already!
To achieve this speed at 4k on a modern raytraced or path traced game at max settings, you will need to have more power than even a 5090 can provide.
Yes you can activate FSR/DLSS and frame generation but then, you have to deal with fake frames sh that introduces artifacts in motion, for absolute no advantage whatsoever, at lest not on single player non competitive games. For me for a single player game, 120hz is more than enough and I have a 240hz monitor.
Hell I even play some games at 60hz, despite me agreeing is time to go above that but with no other choice, I'm perfectly happy with smooth 60hz.
And people also forget that the more speed you ask from your monitor and GPU, the less game effects you can push to the max (if you don't want to use upscalling...) also more heat they produce, more energy they waste, less time they live and more money you lose. All just you can see a big number changing on a fps counter.
Just my opinion.
-
1
-
-
Like Arcturus said materials names do not need to be a real path to a texture. Thou afaik Radiant (and probably DR?) uses it to display it in a virtual folder tree in the editor, meaning if is a single word, it shows up in the root of the media window.
SpoileridSoftware afaik used that convention because that is what they probably did since idTech1 or 2, in those days a "material" (or "shader" in Quake 3 parlance), was really a single texture in the base folder and ingame for the most part (not sure about Quake 3), so made sense for the path to point to the real texture.
Doom 3 and idTech4 changed all of that but the convention just stuck.
-
1
-
2
-
-
47 minutes ago, stgatilov said:
I don't know which Prey you mean and what exact reference is.
If it is Prey 2006, then it was most likely mesh animations (e.g. geometry and texcoords).It is technically possible to do animated textures in TDM using huge piece of copy/paste with if-stage per frame, but it is hell to work with.
afaik you can also use texture strips as well?! (the image frames connected one after the other in a single horizontal texture)
textures/particles/burst_strip_small { qer_editorimage textures/particles/hkball_strip.tga noSelfShadow translucent noShadows twosided deform sprite sort 5 { blend add map textures/particles/burst_strip_small.tga scale 1 / 32 , 1 scroll table32[ time * 1.4 ] , 0 } }the important part is the scale and scroll bits, 32 in scale, is the number of frames of your texture strip, what the 1 after the comma means I already forgot. And in scroll, time controls how fast your animation plays (scrolls to next frame)
and there's also the possibility to use roq videos as textures, doesn't work for materials used for lights, so you can't take a spot light and simulate a video projector, but that is easily faked imo.
video/tvshow { qer_editorimage textures/editor/video.tga { videoMap loop video/tvshow.roq } }-
3
-
-
On that video afaik that is how normal mapping works!?
Afaik you should only see the normal map effect, when a, per pixel, dynamic light casts on it, without that there's no way to calculate the bumps, so you only have a flat surface. And because this light seems to flicker fast, you see a flat surface for a moment than a normal mapped one and that, on, off effect, gives the illusion the surface is moving.
This could be somewhat mitigated with a second "static" light also striking the surface or better a ambient light that has a baked global direction encoded in it. And thinking about it, doesn't TDM already modified the ambient lighting to have direction already? I seem to recall talks of if before.
I just know original Doom 3 engine ambient lights, lack direction totally, so surfaces look flat with ambient light only.
Btw Source engine tried to solve this by encoding directional information on the light-mapping data itself and on shadow they use the specular map as a fallback to show the normal info, is why on shadow, Half Life 2 surfaces look very shinny, like they are very wet.
But idTech 4 and in extension TDM engine, does a more "realistic" type of surface lighting, meaning it doesn't have baked light ability whatsoever, it is totally dynamic relying on the real time lighting, to do the shading/lighting calculations each frame and so, every surface needs a light to cast on it, to know the final normal map direction data, meaning how to show the normal bump "shadow".
-
On 4/10/2025 at 1:16 PM, grodenglaive said:
I would define that as complicated
Yes is complicated but there's not much the team can do, besides creating a dedicated tool to edit the EFX presets visually but coding such a tool, is a big project on itself and few people would have the skills and time to work on it, for free.
Editing sound IMO will never be a press button, things sound awesome affair, sound modeling and physics, based on what I know, is a complex subject, because there's many "knobs to mess about" aka sound changes by many parameters, even in the real world. Is also probably why you see those music producers workstations fully packed with buttons and sliders and such.
-
40 minutes ago, chakkman said:
4K is very demanding, as the GPU has to process double the pixels, when compared to 1080p.
...
Not only that, if he turns on MSAA (multi sampling antialising) that can quadruple or more the amount of pixels the engine has to shade. And this engine uses full real time PER PIXEL lighting, meaning the more pixels you give the lighting system the slower it becomes.
And comparing this engine to other titles, imo means nothing, because we don't know how they handle lighting, shadowing, culling, compared to this one. Thou he talked about Dishonored 2, and I know that game uses a different visibility culling system to TDM engine, if I'm recalling well is based on a third party tech called Umbra (also used by Unity3D) that does the job entirely on the GPU. TDM still uses the original portal system from idtech4 and it runs entirely on the CPU. D2 engine also does character skinning (rigging and animation) on the GPU, TDM still does it on the CPU, and many other things, both engines are not comparable. One was improved by highly skilled professionals, paid to do so, another was improved by people with different skill levels, again and will not tire to mention, for absolute free. Very different things.
-
1
-
-
1 hour ago, OnlyTaffingCowardsHide said:
No dude, it is what it is, and I completely agree with what you're saying. The tech just isn't up to par performance wise with modern rendering techniques, no need to apologize for that. At least you're willing to admit what I've been saying all along, rather than trying to convince me that "it's totally optimized bro cause opengl 3 and LODS".
I've tempered my expectations accordingly.I never said the engine is totally optimized, you invented that on your head, what I said, is that the engine is updated way above and faster than the original Doom 3 engine and that is a fact. Some of the missions on this game, wouldn't run at all, on the original engine because of how heavy they are. That is how improved it is. You don't know how this game and engine evolved, how slow it was and how fast it has become. I'm here almost since the beginning, even when it was a mod of Doom 3, almost two decades ago, this engine and game have improved a ton.
Also If you think the engine is not up to your standards, then do something about it! It is open source the code is there, for anyone to change and improve, if you can do better than the people that worked on this, then do it! If not stop bad mouthing their work and behaving like they own you anything or that you paid anything for this game and deserve better service!
-
14 hours ago, datiswous said:
No it's not using an outdated engine. IDtech4 was open sourced and tdm is using that source, but has been building onto that. This means the current version of the engine tdm is similar, but not the same as idTech4 (at least that's how I understood it).
Also many performance improvements have been made over the years compared to original idTech4, but it's also way more demanding.
Indeed like you said TDM engine is not outdated, at lest not like the original Doom 3 engine is.
Yes is not using PBR and nanite and raytracing and all that new Unreal Engine 5 stuff that makes it a very fast engine ... not ... but the TDM engine has a ton of updates, above the original idtech4 engine from Doom 3, IMO has now more in common with idTech 5 than idTech4. And all done by a very tiny team of TDM players, with the necessary knowhow, on their free time, for absolute free.
Man some people don't deserve to get nice things for free... And I'm not talking about you datiswous.
To anyone wondering, here is some of the things TDM engine has above original idTech4 that I'm aware:
- soft stencil shadows like Wolfenstein 2009 (original is hard stencil shadows only).
- new shadow system using shadow maps.
- volumetric lighting (aka god rays).
- more advanced AI system (so more CPU heavy).
- GLSL shaders support and OpenGL 3.x akin to D3D10/11 level, (original is OGL 2.0 akin to d3d9 level and uses ARB assembly shaders only).
- modern multicore support (original is single core only).
- unlocked framerate (original is locked at 60hz)
- 64bits color support
- Screen Space Ambient Occlusion
- Parallax Occlusion Mapping
And a ton of more changes, like LOD support, obj models support, improved gui system, improved scripting system, better window system with support for high dpi monitors and 16 by 9 and other screen ratios, etc, etc. None of these changes were easy to make and took years of hard work, again for free, for a free game that we wall consume without paying a dime. IMO the lest some people can do, is respect that! Enough said.
-
2
-
1
-
-
10 hours ago, revelator said:
Yah quake 4 was the first idtech engine using megatextures,and it only used it on far away objects (compression was really awfull in the first version). Followed by enemy territory which used it for all world textures / geometry but also had way better compression.
Really? Quake 4 used megatexturing?! If that is true, afaik they never talked about it in the game promocional material. I always thought Quake Wars was the first idTech game to ever use them. Despite the feature existing hidden in the engine, since Doom 3.
And yes in Doom 3, a single 8k terrain megatexture is a couple of gigabytes (thou today games are reaching 200+ GB already...).
Also I wonder why JC didn't supported tga RLE compression feature for the MT, when the engine can already use it for basic textures, it wouldn't be as good as the later compression system they used but would still take out a few megas from the size. Perhaps the tga decompression, just took to long for the MT streaming feature?
-
5 hours ago, OrbWeaver said:
Prefabs don't exist in the original Doom 3 or D3Edit as far as I know.
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
-
On 5/3/2025 at 5:17 PM, kingsal said:
I don't think idDebris will work in TDM. Its mentioned a couple times in the source code related to projectiles and there is a defunct def of it in d3_junk.def.
AFAIK - we need to use the flinder objects which I know grayman did some work on back in probable 2.7 or 2.8 to make them usable.
Unfortunately I couldn't get them to ignore their own collision, maybe there is a spawn arg I'm missing.
Another issue is if you break a crate by an elevator or by a door, the flinder objects could potentially stop the elevator or door from moving. So I could either have them disappear after a time OR make them grabbable so the player can move them out of the way. I opted for the later because it made more sense.
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.
-
8 hours ago, kingsal said:
Coming in late in this discussion, but I've made some breakable crates for Volta 3 that work pretty well. It is a real pain to get the flinders to spawn at the right place since they need to spawn a few units away from each other or their clip models will get stuck and they'll float in the air.
If its helpful, you can check them out in volta_breakable_crate.def.
Breakable doors would be pretty cool, I wonder how AI will react to them?
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.
Quote'red', 'green', and 'blue' being set to 'param0', 'param1', and 'param2' allow the level designer to change the color of the glass by changing the 'shaderParm' values in the editor. As you will see later, this could be shortened to just 'colored'
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.
-
1
-
-
On 4/21/2025 at 2:35 AM, datiswous said:
There doesn't seem to be a difference in writing set or seta in autoexec.cfg, they both work (there).
What is the difference between set and seta?
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
-
1
-
-
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.
-
1
-
-
9 minutes ago, SeriousToni said:
How does parallax perform on non straight, but curved walls?? Did anybody test it for seams?
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.
-
1
-
-
47 minutes ago, chakkman said:
Yep. Same here. 8x is more than enough anyway IMO.
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...)
Share your Status / What's on your mind?
in Off-Topic
Posted
My condolences to you revelator. Like SeriousToni said we will be here for you to talk.