HMart
-
Posts
1588 -
Joined
-
Last visited
-
Days Won
13
Posts posted by HMart
-
-
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...)
-
1 hour ago, OrbWeaver said:
DXT5 for normal maps is obsolete. Both game and DR support BC5 (RGTC) normal maps, which are better quality and more efficient than DXT5 for this purpose.
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
-
1 hour ago, nbohr1more said:
Not that it amounts to migrating the whole code-base to Rust but I have to admit that we have encountered memory management bugs, even recent ones:
I wonder if some future C++ version will include Rust-like compiler requirements...
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.
-
5 hours ago, ptw23 said:
To be again absolutely clear - the reason I picked Rust is not that I (or anyone else) has a reservation about the quality of the C++ code the team is writing, it is (a) a curiosity project and (b) because my assumption - right or wrong - is that people, especially the core team who are responsible for making sure [supported addon workflows and] new code does not break TDM, would not want to support DLLs because it is impossible to trust that the code of third-parties does not corrupt memory (accidentally, malicious code being a separate problem).
- I don't know if you have ever moded idSoftware engines but if you did, you would know that using a .dll for mods as always been the practice, and even thou everyone knew there was always a chance for malicious code or for bad written code, the community was willing to risk it and this as been running fine since 2004 at lest since I follow idTech4.
- And if someone coded a bad dll, filled with memory errors, leaks and bugs that mod, would just get bad publicity and be forgotten very fast. And afaik this .dll's, don't brake the original idSoftware game, because they are self contained modules/games, with their own folders and such and just call or link assets from the original game and do not modify them, so in that case, they are totally safe. Just delete the mod folder and bang, you return to the original game.
- Btw sorry if I'm not understanding you well, English is not my main language, but are you saying TDM should remove support for dll's? If so, how would people make independent mods then? Not that I know many dll mods for TDM, but Doom 3 has a few (TDM was one of them one time).
- So without making a .dll, using a SDK, you would have to modify the main engine c++ and game code itself, don't you? And that, would indeed break the main game or that person, would have to fork TDM into a totally seperate game. But I maybe misunderstanding all of this, if so please ignore what I'm saying.
The idea is that giving people a starter pack that auto-checks things the team are unlikely to trust is not a bad thing.
- Nothing against this, more safety is good. I just hope all those checks, don't sacrifice performance and easy of use for missions...
I also put a list of limitations directly after that, very explicitly stating "Rust is safe" is a bad assumption. Rust is not a solution, it may not be sufficient, but I'm more than happy to do a C++ version, if that is not an issue in the first place -
- Like I said do what you want, I didn't commented to make you stop using Rust and go for C++, use the language you like to use and you feel happy with, this should be a hobby not a job after all.
... That aside, the OOP paradigm for C++ is probably (I suspect) better for game engine programming, but I'm not going to fight any Rust gamedevs over that.
- I most say I know next to nothing about Rust, apart that it exists and claims good memory safety.
The point of this is that perhaps not all features are things that could or should be in the core, and that modularity could allow more experimentation without the related risks and workload adding them to the central codebase - happy to be corrected, but I doubt bringing new core engine features is just about developing them, it's also deciding when it's worth baking all new code, and functionality, right into the main repo to be maintained for ever more for every release and every user.
- This is where mod folders and its .dll really help! If you want to extend TDM and don't want to mess with the original game, just make a separate mod and pass that along.
I'm pretty sure the TDM community will not mind, unless is something meant to hurt others, that I'm sure is not the case.
Similarly, but I would appreciate if you responded to the points, and the caveats, I made, rather than stating something clearly unreasonable to suggest is a bad idea. It misleads others too.
- You are right, I jumped the gun and for that, I'm totally sorry. Like I said English is not my main language, you wrote a huge comment and I just glazed my eyes over it, saw "Rust, TDM and memory safety" and that just reminded me of the relative recent fallout between the older C/C++ programmers and the new Rust programmers about the Linux kernel.
About responding to your points, stgatilov is a way better person to do that, he is the main engine programmer for TDM, a excellent C++ programmer and knows the engine very deeply, if what you are doing is good or bad for the game, he is the person to say it not me.
-
1
-
-
Quote
is the decreased risk of accidental subtle memory bugs, aka being "memory-safe" -- essentially
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?
SpoilerAnd about other types of safety, this game is open source, anyone can take the source and create their own fork or even create a dll to be used as a mod, if any of us really really cared about safety, no one would play this game, because most of us players don't really know what the people working on this put on the code, we just trust them and they have shown and proven, to be trust wordy, so no IMO there's no need for Rust in TDM for "safety".
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.
-
On 1/2/2025 at 7:53 PM, stgatilov said:
Also there is FLT model, but no idea what it is.
afaik .flt was a old OpenFlight model format that Jon Carmack was using to test MegaTextured terrains using idTech4 as a test bed, I don't think anyone ever used it, besides him. Never tested it but is probably broken and doesn't work, like MD3 also didn't worked initially.
-
Just need to say this
Quotelwo ... break your model (smoothing groups might be pain)
This was not true at all for me, when I modeled for Doom 3 at lest, all my lwo models worked fine, including smoothing, thou I use Modo 601 that was the exact modeling tool Seneca a model artist from idSoftware used and I also used his custom Doom 3 exporter pluging for Modo that cleans up and prepares .lwo files to Doom 3 prior to exporting.
This is what I do in Modo 601 to export clean lwo files, perhaps helps those using Blender as well.
1 - put model origin at world 0,0 and move model geometry if necessary so its origin is at the place you want, like the model base.
2 - (optional) clean geometry using some automatic system, if available, so your model doesn't export with bad data (like single vertices floating disconnected).
3 - bake all model transforms, so rotation, translation and scale are all put at clean defaults (that will respect any prior scaling and rotation you may have done)
4- (in modo smoothing works this way) go to the material section and if you want your model to be very smooth (like a pipe for example) set material smoothing to 180%, you can set smoothing per material. If you want more smoothing control, you can literally cut and paste the faces/quads and you will create smoothing "groups" or islands that way.
5 - use or select a single model layer and export that (the engine only cares for a single lwo layer) if you want a shadow mesh and collision mesh as well, put them all on the same layer as the main model.
6 - never forget to triangulate model before export (Seneca plugin did that for me automatically)
I did this and all my models exported fine and worked well ingame. Thou .lwo was invented by lightwave and Modo was developed by former lightwave engineers/programmers, so perhaps their lwo exporter is/was well optimized/done compared to other 3D tools.
-
1
-
-
9 minutes ago, Wellingtoncrab said:
More polys/geometry usually isn’t easier in the context of this game, where making content which runs at all is about producing clean sealing geometry and portalization.
For all its faults an illusion like POM, which derives detail while retaining minimally complex sealing geometry seems well suited to that and the workflow of most mappers.
Maybe hardware tessellation could achieve something similar with less of the drawbacks, but I am pretty happy with this so far.
Agree, I talked better about tess but for TDM POM is perfectly fine. I expect Tess requires harder work at the engine geometry handling system, like a way to dynamically tesselate models and create LOD's.
-
6 hours ago, stgatilov said:
I'm not sure this is true.
Even with per-pixel raytracing, POM seems to be faster than throwing more polygons.Perhaps you want to test it yourself?
It would really interesting to see competition between parallax maps and high-poly + normals maps (perhaps tessellation shaders also?)But it is indeed easier to just throw more polygons at the problem, no need to dance around the quality issues.
Today's "cutting edge" approach is to use shitload of polygons with auto-generated LODs and hope that GPU does not die rendering it (UE5 Nanite)."POM seems to be faster than throwing more polygons" Good to know but I did heard the contrary from some people in the gaming industry but I never tested it my self and this was years ago, so things most have changed by now.
But even so even if POM is faster and look awesome when it works, there's no denying that it has serious issues with curve surfaces and characters.
And your totally right about UE5 nanite, IMO this focus on that tech, is creating huge performance issues for modern games, some developers are even stopping making custom LOD's anymore and relying entirely on nanite.
And is not only nanite, mesh shaders are gaining popularity and they gave rise to D3D12 "meshlets", that is what Alan Wake 2 uses for example. The Remedy engine debug visualization of them, does look very similar to that of nanite, so perhaps they are the same thing?
Lumen is another thing that IMO is creating big performance issues and ugly noisy games, even TAA cannot solve that, I played a indie UE5 demo of a horror game and when I entered dark rooms and turned on the light, it took almost half a second for the light to resolve, it was very jarring.
-
2
-
-
1 hour ago, datiswous said:
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.
It has solutions, the easy ones are those the others talked about.
-
1
-
-
3 hours ago, datiswous said:
How would you make the edges look good? Currently it looks weird where it stops on the edge.
I mean with the cobblestones.
This is not real geometry tessellation this is cool but is a fake trick, a optical illusion, the surface is still flat, so it cannot do anything about the edges.
Parallax Occlusion Mapping (POM) is just a improved (and way more heavy) parallax mapping affect.
SpoilerBellow another perhaps better video explanation for this stuff.
-
1
-
Garbage Performance and Broken AA (1660 Super)
in TDM Tech Support
Posted · Edited by HMart
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.