HMart

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.

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 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.

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.

"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.

It has solutions, the easy ones are those the others talked about.

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.

No problem glad I helped.

Like this? "you can make lights invisibility (or not) for X-Ray subview, but you cannot change their color, size, etc. " Also stgatilov may correct me, but if I'm recalling this well, suppressInSubview doesn't manipulate (aka changes) lights (or models) data at all? I think it is just a special render flag that tells the engine render, to ignore that particular entity in a certain subview.

People can dream... But is not as simple as just updating a few materials or textures. TDM lighting interaction shader will have to be changed to be fully physical accurate, because afaik right now is not, then the engine will have to support some kind of automatic global reflection system (screen space or cube maps with probes) all to support the metalness system, something it still doesn't have, and that are jobs for one or more good graphics programmers, plus if cube maps, will the probes be automatic or manually placed? If manually (that i doubt...), who will place them on all existing missions? What about those missions where original makers are MIA? Then there's the unescapable fact that, it will take a huge amount of work to change all TDM materials (the material code as well) and textures to PBR and I mean all, down to particles, overlays, flares, the all shebang (unless done automatically like you guys are saying....). I would love, to not be a doubter but unfortunately, I don't think this will ever happen, not unless a number of people on the TDM community, with sufficient knowhow, get serious about it and do it.

Thanks, but no I didn't wrote that sky portal stuff and that was never my nick, someone else deserves the praise for that. And about participating on a thread about the sky portal stuff, I don't recall that but perhaps I did but I doubt it was to say how to code that feature in.

I certainly expected and deserve that reply, but I just don't have the time and to tell the truth, I don't think I'm qualified to do it.

Indeed and yes Prey 2006 is literally Doom 3 engine with only a few modifications, TDM engine is way more removed from original idTech 4 than Prey engine was. Also I think this can be replicated in idTech 4 relatively easy (in c++ obviously): https://www.froyok.fr/blog/2019-03-creating-seamless-portals-in-unreal-engine-4/

Sorry for the off topic Kingsal.

Afaik player is a idEntity, everything on the engine is based from idClass->idEntity->all the rest. About Kingsal question unfortunately I also don't know what's causing the issue, this seems like something those working on the TDM engine, like stagtilov are better suited to answer.

If the raw original video files exist yes but with the final baked one is debatable. As you certainly know, videos are made of pixels, in a 4:3 ratio they are squares (more or less) and to make the frames 16:9, you need to change the pixels ratio from a square, into rectangles. This obviously, messes with the image look, makes it look stretched, so to solve that you need to somehow, increase the number of pixels in between, without changing the original ratio. Meaning you need to input new pixel info into the image, info that is not there. Afaik that is what upscalers do, aka bring "virtual" pixels into a image, so is probably possible but personally I only have seen them upscale images of the same ratio.

Yes that is the original behavior of caulk since the Quake days and probably before.

What is misleading about what I said?! Just because TDM world look in part like 17 century age, it doesn't mean it is a representation of our history or universe. So using our own world as a reason why guns should exist in TDM, is not valid.