How can I help?

[Loginnerer]

 

On 3/28/2012 at 11:07 PM, Springheel said:

I don't have any skills
 

As someone who doesn't have skills, I feel like people who have submitted ratings to ThiefGuild's TDM missions (now including myself) - have helped out in a way. It's quite important to know which missions are the best to recommend to new players. 

Or are there other TDM FM rating summaries out there I don't know about? I saw some polls about missions in forum somewhere, but didn't find them again.

[JavaGod]

To all devs - I am an Unreal Engine developer. While UE is heavily templated with macros galore, I do understand the underpinnings of it quite well since I have been studying their source code for the past 3 years. I am currently making some Editor plugin utilities to bridge the gap between newcomers to the engine, and the Engine itself. 

I have loved TDM since I first encountered it a few years ago, but I was honestly dismayed at how few fan missions were being created. That being said, some of these missions in the past year are incredibly well developed, almost to the point that it is amazing to think they were developed in an engine that is as old as it is. But I do believe one of the barriers to entry is that DarkRadiant is a bit daunting for a noob, and I would like to give it somewhat of a facelift to make it a bit more user friendly without affecting the underlying map generation and building processes.

I also have some ideas on how to improve the rendering performance, especially in larger areas with many portals. I am going to implement them into my own local build to really flesh them out, and then submit for review and eventual inclusion to the build.

I am certainly not gods gift to programming, and I am an admittedly terrible thief, but I do have quite a bit of development experience that I believe could be helpful to bring this along.  Just want to give my 2 cents back to a project that has really kept the Thief idea going.

Now to crack open some source and grab a beer...

Thanks!

JavaGod

[I.C.H.I.]

IMO the most of all TDM needs a better lighting, Doom 3 engine never looked great in this regard but such is its legacy.

[chakkman]

Doom 3 was pretty much the ultimate in terms of lighting when it was released.

Edited August 3 by chakkman

[I.C.H.I.]

13 minutes ago, chakkman said:

Doom 3 was pretty much the ultimate in terms of lighting when it was released.

Hell no! One of the ugliest engines ever made IMO. It never looked natural and didn't even try to look natural that's the worst thing about it.

[chakkman]

Ok, that is your opinion, but, fact is that it was praised all over the place for its lighting back when it was released.

That's why it was such a good decision to take it as an engine for TDM, because it did things with lights and shadows no other game did back then.

[Arcturus]

@JavaGod

Stencil shadows were performance heavy and kind of ugly. We have shadow maps now so that's solved. What the game could use is some kind of dynamic indirect light system. Probes or screen-space global illumination, screen-space reflections. Switching to a full blown PBR was deemed too ambitious, but having proper image masks in materials would be nice. There's plenty of little things that could be improved and bugs that could be fixed on the rendering side and also AI.

[I.C.H.I.]

20 hours ago, Arcturus said:

We have shadow maps now so that's solved.

No, it isn't. For good lighting shadows are not enough. When I say lighting I don't mean shadows at all but the response of the materials to the light projected onto them. In this regard TDM does a terrible job and nothing is even remotely close to photorealism. And you don't need PBR to make it better, because even before its universal adoption games still managed to looks photorealistic.

[thebigh]

Suspect yours might be a minority opinion there. This modified D3 engine does just fine for the look TDM needs.

[Arcturus]

3 hours ago, I.C.H.I. said:

And you don't need PBR to make it better, because even before its universal adoption games still managed to looks photorealistic.

There were no photorealistic games 15 years ago and even today you can hardly call newest games that.

[I.C.H.I.]

16 hours ago, Arcturus said:

There were no photorealistic games 15 years ago

Sure about that?

Stalker: Oblivion Lost (2003).

[I.C.H.I.]

16 hours ago, Arcturus said:

and even today you can hardly call newest games that

Really?

Dead Island 2 (2023).

 

[Arcturus]

6 hours ago, I.C.H.I. said:

Even at this tiny resolution (640x480px) nobody would mistake this for a photo.

6 hours ago, I.C.H.I. said:

There are still giveaways typical for real time rendering. Ambient occlusion effect looks unrealistic, those objects on the left aren't lit properly. People struggle with photo realism even in offline rendering. But yes, the gap will slowly close. And don't get me wrong, I am all for improvements in darkmod's engine.

[I.C.H.I.]

9 hours ago, Arcturus said:

Even at this tiny resolution (640x480px) nobody would mistake this for a photo.

This was more than enough for 2003. Try doing the same in Doom 3 engine, that is my main point.

[Baal]

On 8/5/2026 at 7:56 AM, I.C.H.I. said:

Dead Island 2 (2023).

 

This also looks incredibly boring and uninteresting.

[chakkman]

59 minutes ago, Baal said:

This also looks incredibly boring and uninteresting.

Just like the game itself.  

Shame, because, those games could be very interesting (also Dead Island 1). Instead, they're boring, repetitive hack & slash action games. But, I assume that that's exactly what the modern crowd wants.

Edited August 6 by chakkman

[Arcturus]

18 hours ago, I.C.H.I. said:

This was more than enough for 2003. Try doing the same in Doom 3 engine, that is my main point.

From what I read Stalker engine supported light baking, which I guess helps with big daytime scenes like that. That's something Darkmod doesn't have. What else is missing?

On 8/4/2026 at 11:57 AM, I.C.H.I. said:

the response of the materials to the light projected onto them. In this regard TDM does a terrible job

That is something that's testable. You could make concrete comparison of the same 3d mesh lit in different (non-pbr) engines.

[I.C.H.I.]

On 8/6/2026 at 7:55 PM, Arcturus said:

From what I read Stalker engine supported light baking, which I guess helps with big daytime scenes like that. That's something Darkmod doesn't have. What else is missing?

On release Stalker could use both static(baked) and dynamic(real-time) lighting. There is a mod for Shadow of Chernobyl called Oblivion Lost Remake 2.5, it significantly improved weather presets and it looked even better with dynamic lighting enabled.

Under the hood X-ray engine uses deferred shading but I'm sure it's possible to achieve the same result with forward renderer, for example, Godot uses Forward+ renderer and some people do wonders with it.

Here is Oblivion Lost Remake 2.5 with dynamic lighting enabled.

[datiswous]

On 7/30/2026 at 1:38 AM, JavaGod said:

I am certainly not gods gift to programming, and I am an admittedly terrible thief, but I do have quite a bit of development experience that I believe could be helpful to bring this along.  Just want to give my 2 cents back to a project that has really kept the Thief idea going

Sorry, it's not clear to me what exactly you are offering.

Edited August 17 by datiswous

[SeriousToni]

Yeah I too would be interested in the ideas he has about making Dark Radiant more beginner friendly - maybe he should get in touch with Klaus about that later on. But I also miss a more detailed conversation about what he sees as "not beginner friendly" there. I mean there's tons of documentation and videos about dark Radiant there and it's easier to use than some complex thing like the Unreal Ed to be honest. 

[JavaGod]

Hey all - So, I have done a cursory look at some things in the engine, and I have to say that it is amazing that Carmack and Romero created this thing.  What Epic has done with the Unreal Engine is nothing short of miraculous, but they have an entire army at their disposal. These two guys developed this on their own, and it is very impressive for the time.

The code base is actually quite well structured. There is s definitive object hierarchy, albeit simple by today's UE standards. But, you couldn't expect anything else considering the timeframe of when it was created. 

There are some a couple things that really stand out to me.  The first is that there is zero distance culling on the camera's view. That was a total shocker to me, and actually explains why the engine dies a horrible death in open areas. Without any distance cutoff, even if something isn't even on screen because it is so far away, it is still processed like it is because the camera can see it even if we can't.  This is compounded by the design of having to search through open portals.  Because the camera can see all, an open area with many lights and surfaces becomes a giant bottleneck because the engine has to process them all, every frame, even if their relevancy is near zero due to distance. This would actually be a great use of a CVAR in my opinion so that the distance could be adjusted to accommodate different hardware.

The second thing that shocked me is that portals are automatically traversed, regardless of their size. A portal that is far away and only 2 pixels on the screen is still traversed and everything through is computed.  This is actually the other side of the coin for distance culling. Adding in a size constraint on how big a portal needs to be to be traversed would also help greatly because it would keep a ton of worthless calculations out of the pipeline.

So, I saw a couple posts about what I think is not user friendly about Dark Radiant for newcomers.  One of the things I specialize in is UI.  As a general rule, naming conventions and usages internal to the software make poor userland terminology.  Case and point - func_static. From an editor standpoint, the terminology should be simply called a "Prop" or in my world, a "Static Mesh". As a new designer, I had no idea what a func_static was or why it was called that. However, if I had seen the term "Prop", that would have been immediately identifiable.
Same for func_mover.  From a user perspective, it should be called something friendly like "Moveable Object". In a similar way, "worldspawn" has become synonymous with things that seal off the void. That naming should be changed because in today's vernacular, "spawn" means to instantiate something in the world. Maybe a term like "Structural objects/geometry", etc. Note that this is only for the editor presentation. Under the covers, the tool still builds the map using all of the standard naming because it has to. 
There are other things that I am thinking of as well but verbiage is the big one. It matters, and when you are a newbie and just want to make a map, you shouldn't have to know anything about the internals of the engine.

These are some of the things I have seen so far.

Edited September 2 by JavaGod

[I.C.H.I.]

16 hours ago, JavaGod said:

and Romero created this thing

Romero has nothing to do with this engine. More to that, he left id Software shortly after Quake 1 was finished.

 

[datiswous]

On 9/2/2026 at 8:22 AM, JavaGod said:

What Epic has done with the Unreal Engine is nothing short of miraculous, but they have an entire army at their disposal. These two guys developed this on their own, and it is very impressive for the time.

I am surprised as well...

[JavaGod]

Yes - he left id before Doom 3 was developed. But, much if his ideas and designs are still in the engine. So, even though he didn't write any code directly for it, things like CVARs and the .map file are his creations.