[TDM file format support info]

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? 

[TDM file format support info]

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

[Experiment with Rust in Scripts]

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.

[Experiment with Rust in Scripts]

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.

 

[Experiment with Rust in Scripts]

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?

Spoiler

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

[TDM file format support info]

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.

[TDM file format support info]

Just need to say this 

Quote

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

[Experimental support of parallax mapping in 2.13]

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. 

[Experimental support of parallax mapping in 2.13]

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. 

[Experimental support of parallax mapping in 2.13]

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.

[Experimental support of parallax mapping in 2.13]

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. 

Spoiler

Bellow another perhaps better video explanation for this stuff.

https://www.youtube.com/watch?v=cM7RjEtZGHw

 

[[2.10] X-Rays]

No problem glad I helped.

[[2.10] X-Rays]

On 12/9/2024 at 10:24 AM, datiswous said:

So I read this on the wiki page:

But then farther down below, I read the following:

 

How should I read this? Seems a bit confusing to me. I mean it seams to me suppressInSubview does manipulate lights.

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.

 

[PBR update of the Darkmod's character model]

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. 

[Warpzone portals]

16 hours ago, nbohr1more said:

No worries. I figured you'd be a good candidate.

I think @7318 made our HL2 style portal skies, I keep forgetting if that was your old alt \ nick.

( Don't recall both of you in the same thread ? )

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. 

[Warpzone portals]

2 hours ago, nbohr1more said:

If you post a patch we will merge it

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.

[Warpzone portals]

5 hours ago, OrbWeaver said:

These portals sound a lot like the ones in (the original) PREY, which I believe was an id Tech 4 engine.

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/

[GUI string character limit trouble]

Spoiler

IdPlayer is a extension of idActor that can be traced back to idEntity.

On c++:

class idAnimatedEntity : public idEntity  -----> class idActor : public idAFEntity_Gibbable -> class idPlayer : public idActor 

Sorry for the off topic Kingsal.

[GUI string character limit trouble]

18 minutes ago, datiswous said:

I have no clue what this is about, but I noticed this:

So it responds to idEntity. But in your code I see this:

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. 

[TDM logo video has 1:1 aspect ratio]

6 hours ago, datiswous said:

Instead of changing the aspect ratio of the video to 16:9, it's maybe better to make the (original) video not stretch at all? Is that possible?

....

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.

[Light seeping through caulk]

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

[Thoughts on... The Inventors Guild]

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.

[Thoughts on... The Inventors Guild]

There's also the fire arrow that is technically a explosive. 

But at the end of the day, this is a game and if anyone want guns in it, someone will have to implement them. 

Someone will have to model, texture, rig, animate, code and play test a gun into the game that feats and like chakkman said, there's always the danger that the existence of guns, will just kill the usefulness of arrows and the Thief like identity of this game.

But if someone wants to do a special separate non canon TDM mission, where guns exist or aliens or whatever then by all means go for it, personally I will certainly applaud it and play it.

[Thoughts on... The Inventors Guild]

14 hours ago, tib said:

Hey, wtf why tdm inventors not invent a classic firearms at most 17'century missions? Can someone explain that to me?

Perhaps you want some in lore special reason why there's no guns but the truth is more simple, is because the developers of this game, didn't wanted guns as a gameplay tool.

This game is a homage to the game Thief (mostly Thief 1, 2 and 3) and in those games there's no guns.

But anyone is free to come up with a in lore excuse why there's no guns, perhaps in this world shooting a iron pellet through a tube is impossible, because of some obscure magical reason.  

[Post your System Configuration here]

I need to try this my self someday.