peter_spy

That's a good practical example you can analyze. If it isn't too much to ask, you can try taking stats screnshots from the same spot and camera angle with: 1) both light and objects visible 2) light entity hidden and objects visible 3) light visible and objects hidden 4) all hidden The biggest stat difference will be between 1 and 4 obviously, but you should observe much bigger performance gain between 1 and 3, than from 1 and 2 or 3 and 4.

Not really alternative, more like "historically established" and widely known If you take a look at various descriptions and definitions from other engines, all LOD systems are about the same thing: https://forums.thedarkmod.com/index.php?/topic/17283-hide_distance-broken-again/page/4/&tab=comments#comment-463315 and TDM follows that. You can argue that it's a bit broken here and there, or it has some quirks (like with absolute distances from the model instead of relative ones, like everywhere else), but otherwise it's there And in your example, you could simply hide stuff these lanterns light, because, as proven in the last screenshot in this post, the cost of your lights will be minimal: https://forums.thedarkmod.com/index.php?/topic/17283-hide_distance-broken-again/page/4/&tab=comments#comment-463272 That's the thing, and I'm really curious to see this looking good and giving meaningful performance boost at the same time. Since other engines have been around for so many years, and none of them is doing that, I think it's pretty safe to assume that other developers already tried it and it wasn't worth it / looked awful. As I said, it would be great to see a meaningful example, but so far we've got a lot of talking and examples that had nothing to do with the subject matter, despite explaining the thing several times over. Let's hope Kingsal comes up with something nice

You don't see a reason because you lack experience and knowledge, you're so focused on "me me me, I want this, gimme!". I'm focused on the big picture, i.e. not being in a bubble, using the common knowledge and language, and working with what has already been established in gamedev, so the engine uses known workflows and isn't weird and insular for anyone coming here from outside. Not sure, but if you use hide 1 on an AI, it stops patrolling. It is there e.g. playing random barks, although it does not appear on the showtris view

Lol, performance has nothing to do with feelings, it's about hard data And since you've been so stubborn in pushing your agenda, you should at least show that it was worth the effort and make an example scene where this looks good. Also, hide distance worked for AI for ages, but if you took more than a few seconds to examine how this works, it makes AI stop patrolling. If you use timing in your AI patrols to influence player pacing, and create interesting gameplay, this option is completely useless. It's only slightly above the feature that makes AI stop thinking when it's outside player view.

Lately it's mostly level design stuff and trying to find interative workflow that is good for me. After hours of blocking out and discarding stuff, I finally got the first draft of a hub location that may actually work. Just finished gluing one of the other locations to it. Now onto designing the third one.

That plan is good; if possible, I'd probably move the lighting phase onto the first place. If you focus on placing shadow casters so they don't overlap, and using noshadows lights as often as possible, you should have fewer performance problems down the line while adding more objects and geometry (you should be less restricted in doing so). That said, it's worth noting is that with stock TDM objects achieving good performance is an uphill battle, as they're not optimized like they typically are in games.

Stuff like load map file preference is something you probably set once and forget about it. Wouldn't it be more convenient to have most of such options in a Preferences section instead of a widget? This way you could have just a minimal set of buttons/icons over the perspective window.

@HMart you should be able to have detail textures with certain material keywords. You can do this by e.g. stacking normalmaps with addnormals, or by using gl blend modes. I'm using something a la detail noise texture in Rage, since one of the gl blend modes seems to work like Overlay mode in photoshop: Edit: sorry, you can't really make detail normalmaps with addnormals, since this is image programs territory and there is no option to tile the second normalmap there. It's quite confusing, because there's a scale keyword for image stage, which is responsible for tiling, and there's a scale image program function, which acts as a multiplier for image RGBA values. Two completely different things.

By the way, I guess you'll see that in the code, but the way the lod_fadeout_range works right now makes it unusable with anything but LOD 0 models. Maybe it's because it uses hide_distance as a starting point instead of fading out to hide_distance? In any case, you can have a model with e.g. LOD 0 that is 3k tris and cast shadows, then LOD 1 that is 1k tris and noshadows, and when you reach the hide_distance, the model switches to LOD 0 again. Not only can this look bad, with shadows suddenly popping in before the model fades out, but I guess it can also generate unnecessary performance spikes, going from properly optimized models to full quality in the last stage.

Note that mipmapping still applies here, although that still means keeping the base (highest resolution) texture in memory. Otherwise you can set different materials for different LOD levels, so they could use lower resolution textures, but IIUC, TDM would need to have texture streaming to use that effectively.

I'm only mean because my god you're annoying To be fair, I much rather see such proof of concept from @kingsal who also showed interest in this feature; he's in touch with modern gamedev, and he knows the proper level design tips and tricks. Plus he already has experience with making such lights in his maps, so this way we'd be sure we're on the same page and his example is relevant.

No, noone cares about you solutioning developers on how a feature should be implemented, you giant confused dummy Since you're so good at extrapolation, how come it didn't occur to you that you can simply emulate the LOD system for lights with trigger brushes placed at certain distances, to toggle lights on and off?

You don't see the difference between making assumptions and extrapolations in your head and doing actual experiments because you're not doing anything with these maps. Read the above posts until you get them, and make a map with actual lights toggled with distance, not with a switch and everything going dark, because this way you prove absolutely nothing. Also, to make it even more literal for you, why do you think noone in gamedev spent time on including lights in the LOD systems? Maybe they experimented with that, and found out there is no way to use it without it looking awful? And/or the performance gains were minimal? Do you think you're better or more experienced than people making Unreal, Unity etc.? Then feel free and supply us an actual proof, not a map that is 50% there, and 50% your feelings, preconceptions and extrapolations.

Nope, that's still making stuff up. Show us a map with lights that can act as standard LOD system, as described above (without impacting visuals), and present us the hard data on performance improvements. Otherwise, you're derailing the conversation.

I think it's ok to end this part of discussion, as it becomes noise. You're just making stuff up now; none of this has any confirmation in any systems used in game engines, past or present. As for overlapping shadowcasting lights, this is what causes performance issues, in any game engine, and it's on you to optimize the lights. And you still don't understand that your map demonstrates nothing. So, to reiterate: LOD system changes model geometry when it's away, in order to save performance, but while maintaining the visuals relatively unchanged. In order to demonstrate that lights with LOD system make sense, you'd have to make a map where they're toggled on and off, perhaps with scripts and triggers placed at certain distances, and in such an environment, e.g. with certain fog settings, where this would also maintain the visuals relatively unchanged. So far you have done none of that.

...And to give you some perspective on that: https://developer.valvesoftware.com/wiki/LOD https://docs.unrealengine.com/4.26/en-US/WorkingWithContent/Types/StaticMeshes/HowTo/LODs/ http://wiki.polycount.com/wiki/LOD https://docs.unity3d.com/Manual/LevelOfDetail.html And in general: https://docs.unity3d.com/Manual/OptimizingGraphicsPerformance.html https://docs.unrealengine.com/4.26/en-US/TestingAndOptimization/PerformanceAndProfiling/Guidelines/ These guidelines^ can be applied to idtech4 as well. As you see, there are performance optimization tricks for lighting, but there's literally nothing there on using LOD for lights. By the way: Perhaps in the old days, but having a few thousand of LOD entities in a scene costs CPU next to nothing, while providing substantial savings for the GPU. It's more likely that you'll run into any other bottleneck much sooner.

Perhaps restructuring/rewriting the wiki entry could help as well. It's not even filed under Connection Feature yet. Anyway, 2-3 sentences on what it does, then setup instructions, and then the technical bit for the curious.

I'd rather be worried that with the number of responses being this low, people simply aren't using this feature. And yeah, I'd still blame complexity for that Or perhaps not being advertised enough?

Again, you kind of did the same as in the previous example: you have multiple overlapping lights hitting tons of objects, and everything gets better when you turn them off. Perhaps you should give us a hint on what you understand an LOD system is, because I suspect it might vastly differ from what it usually means.

That's just your interpretation, you said that ss2 was the origin of these games, while I'm just repeating what developers were saying about their inspirations in various documentaries.

Main inspiration for the DS was actually Resident Evil 4 and Event Horizon. Even the creators called it "RE in space" in interviews and documentaries.

FWIW, you can use the stop time cvar to see how the LOD system works even with lights being rendered. So you start here and stop time: As you go further, the number of objects and stats go down: And you finally end up beyond the hide distance range: So even if there are lights there, they don't do much to lower the performance. Lights are not expensive until they hit something expensive.

Ok, so you turned off some overlapping and shadowcasting lights, which obviously got you some performance gains, but drastically changed the look of the environment. So, what's that got to do with an LOD system?

https://youtu.be/hDZSD5XbiN8 That's still 2.08, by the way, and it was recorded @1440p. But yeah, that would confirm my suspicions, other engines don't do LODs for lights because there's no need to. Those ridiculously bad models could be replaced with optimized ones and with more geometrical variety, plus other effects needed to make an FM look complete. Open areas are already possible in this engine, it's a matter of level design and game art tricks

Out of curiosity, did a small experiment with awfully unoptimised nature models in a huge room 4096x4096, and with proper hide distance, lod fade and fog values you can have many lights and still manage performance. This is a top down view: Again, these models are horribly unoptimised, but even with these dreadful stats the game was able to hold 60fps on the gtx 1060: