peter_spy

Btw. if you have the console printing on, you'll see that "remove degenerated triangles" takes a lot of mission first loading time. That seems to be true for missions using a lot of brushes, but I saw these messages too when I kitbashed several .lwo models. I seems like idtech4 just likes all triangles to be positioned nicely and with as little clipping or z-fighting as possible.

The thing is, you can't do that. Missions are packed in resource files (*.ibt), and this is a one-way operation. You need source files (*.unr map, *.tim meshes, *.dds textures, *.mlb materials, etc.) to be able to edit missions, and these aren't distributed in FM packages (as they'd double their sizes). Only TDM allows you to unzip .pk4 package and edit mission source files.

That's a nice idea for some dream sequence I did some more tests, and while this probably won't hold for a full complex map, it might be some sort of indicator when it comes to complexity of a single scene. First, I tried to push tris count and shadow count as much as I can, but separately. It looks like my machine can handle as much as 6 million tris or 500k shadow tris, before it drops below 60 fps. But these values alone don't mean much, as missions are more complicated than that. That's why I added things like fog, 7 AIs, patrol points, and a few skins for these boxes to account for bigger material complexity per scene. Even with thinking AIs I was able to reach almost 5 million tris and 400k shadows, as long as drawcalls were low. One of the factors was the number of AIs actively searching for me. With detection or combat the number of tris wasn't a problem, but with 4-5 AIs looking for me, the scene had to be around 3 million tris and 300k shadows to hold 60 fps. Drawcalls were around 600-700 at all times.

While this test is purely synthetic, it kind of shows how tris and shadow tris can scale with hardware. There are 9 copies of one mesh here, set of chamfered boxes, 27k tris each, with one light inside. Lights are slightly overlapping. There's also ambient_world here. As you can see, as long as everything else is low, tris and shadow count per scene can be huge. Also, this image was shot with FXAA enabled in nvidia drivers and downscaled from 1440p, it also uses postprocess effects.

It probably requires more tests. I can see huge difference in shadow tris tolerance for my machines. The most complicated shadow scene I had on my desktop was 230k shadow tris. My laptop handled around 130k shadow tris. Both are way above current recommended limit (80-100k)

Exactly, if I stick to one simple material per mesh, the DC count stays low. It's either additional stages in material definition or multiple materials per mesh (e.g. when using multiple tiling textures) that seem bump the DC count pretty high. Drawcalls seem to be the bottleneck right now. I only have 2 machines (one decent i7 desktop and one older i5 laptop), but 3500 DCs seem to be the place from where FPS starts to drop on both systems. (I know it's unfair, but in comparison, a single DX11 thread is capable of 35 000 DCs on the same desktop.) Number of tris and shadow tris per scene seem to scale with hardware.

Hmm, I did another test. I created several wood planks with brushes and one wood material, converted it into func_static, then made identical .ase model and imported it in DR. In that regard, results are basically the same. It seems overall big difference in DCs between my models and TDM stock assets comes from the difference between how models were made. I make fully unwrapped models, typically with 3 textures (_D, _S, _N) and one relatively simple material (often just texture declarations). TDM assets often use multiple materials with more stages, so that's where the key difference seems to be.

I put countless hours and a lot of work to make a few things in TDS. Unfortunately, despite great dedication of people like Beleg or Snobel, it's hard to make anything when you're constantly fighting the engine. It wasn't made for modding, it was unnecessarily hard to make custom content for it. Not to mention getting help has been more and more difficult over the years.

While I was prototyping my main location for the demo, I encountered something that might be worth checking further, especially if you use a lot of brushes in your map. I was using multiple brushes to approximate a model for my target location. It had a lot of DCs, so I thought I'll convert it to func_static, so every face isn't counted as a model (which is typically the case with BSP vs static meshes). I did the conversion and compiled the map. When I ran it again, stats actually showed a bit higher DC count, while tris and shadow tris went down a little bit. Tried deleting all the files (.map, .cm, .proc) – no effect. There might be something wrong on my end, so I encourage you to test this on your own. But if this is normal, then it means Convert to func_static is much less useful than I thought. There's not much of a conversion going on here. I mean, you can still do it to add noshadows 1 option for shadow optimization, but that's basically it. That means making "models" in DarkRadiant should rather be discouraged, since the engine has pretty low drawcall limit.

If you just using someone's model packs, then sure, although I know from my experience how long it takes to make good such models. Especially architectural/structural parts require a lot of thought, so they tile properly and on higher grid sizes.

IMO saying that making maps for stealth game like TDM is easy makes a good PR line, but nothing is further from the truth From all types of FPP games, making levels for light-based stealth games is the hardest. You have to think about stuff like player jump and mantle height all the time. Lighting isn't there just for aesthetics, it needs to be a part of conscious gameplay design, as it makes player invisible. The mere setting determines available types of surfaces and types of noises player will make while traversing such spaces (e.g. forest and nature maps are typically easier in comparison to levels with more stone, tile, and metal, so you need to find a way to offset that with lighting, AI placement etc.). None of this is easy, especially in comparison to e.g. maps for FPP shooters

In virtually all modelling programs, objects can only exist on one layer, so that's not a problem, as there's no other command like that. Only DR allows objects to be on several layers.

This is only my experience, so please speak up if you have other ideas. What I would do is either: 1. Remove current Add to layer option entirely, and leave Move to layer only. Right now I can't think of a practical situation, where the former would be useful, especially since you can't expand the layer to see what's on it. Typically, objects can exist only on one layer at the time, at least in all other programs I use. Optionally, to make it more consistent with other apps, I'd rename Move to layer to Add to layer. That's how this option is called e.g. in 3dsmax. But then again, this is my experience, other mappers please speak up if this is too confusing. 2. Leave Move to layer as it is, but rename Add to layer to something else, like Clone to layer, maybe? Maybe someone who really needs that function will have a better idea on how to call this.

IMO that would be most annoying, if I had to dismiss a popup window like that every time I want to move stuff to another layer. That said, I think the distinction between Add to layer and Move to layer should be communicated somehow. First option adds selected entities to a defined layer but it also leaves them on the current layer, which is confusing. I bet most people would expect Add to layer to behave like Move to layer.

Actually, from my experience TDM handles higher fidelity surprisingly well, for engine this old. The thing is, and this is actually true for any engine out there, you need to make a whole map with static meshes. And they have to be optimised for your engine, both in terms triangle count and shaders / materials they use (i.e. they should use as few materials as possible). Some things seem to scale with hardware, like triangle or shadow count or texture memory (although we're probably limited to something like 8192px textures by the engine itself). What doesn't change is the drawcall limit, at least in my experience with different hardware. The easiest way to clog your video pipeline is to make static meshes with high number of materials, which a lot of TDM models do, whether it's modules or decoration props. I understand the reason for that was to use as many versatile tiling textures as possible, to make the mod package easier to download. Also that method was widely used around Thief3 era, where textures were 256 or 512px at best, and making UVs in that texture space was less efficient. The thing is, while games like Thief 3 used 2-3 materials per mesh on average, to save on performance. TDM went wild that count, often using 8 or 10 different materials per mesh (15 was the highest value I've seen in the model browser). That's way too excessive. Add complicated, multi-stage materials, and multiple or overlapping lights (something easy to miss, if you're inexperienced mapper), and you have a recipe for disaster. That is what is both the source of performance problems, but it also presents huge opportunity for future improvement. To tackle these problems, you have to take the path basically all post-Doom3/Thief3 games took, and switch to "environment sets" (let's forget about lightmaps for a while ). Usually, such set contains modular architecture pieces, versatile background props/decorations, and unique models ("hero meshes"), along with a few tiling textures, if need be. They are as flexible as possible, and the new props or decorations are modelled along the way, or mixed/taken from other asset packs. They are also fully unwrapped and use as few textures/materials as possible. None of this is easy though. It requires a lot of time, and a knowledgable modeller, something TDM never really had in ample supply (at least that's my impression after a few talks with fellow mappers and TDM team members).

To be on the same page, I don't demand anything. I noticed low framerate in ERH+ screenshots, assumed that he has a machine capable of running the engine in 60 FPS (and I'm aware I can be wrong in this), and pointed out a possible solution. Whatever ERH+ will do, it's his choice. It was Melan's dismissive attitude that triggered the whole heated discussion. It's true that I'm very opinionated about certain things in level design, and I know more about this stuff in theory that I can prove with maps (although they still run in 60 FPS, even on that old crappy TDS engine ). I love this community for its energy and support, but I admit situations like that are bit frustrating for me. Both here (sometimes) and TTLG seem to live in some kind of knowledge bubble. I look like a crazy person, and I feel like that a bit, but only because I have to preach about stuff that is 100% duh-and-obvious everywhere else in modding/level design communities. And, I've never seen such active resistance, hostility almost, to learning this stuff. I don't know, maybe it's me phrasing it in a wrong way.

These are subjective simplifications, to say the least. E.g. I see a huge difference in framerate up to 45 fps. Sure, stealth gameplay is slower, at least until you get caught and have to improvise. So that assumption is pretty risky. Also, the difference will always be noticeable, even with slow gameplay, because player can always turn camera to a view where it's 60 fps. That kind of fast jumping between ranges looks bad. That's also why I proposed an FPS limiter in TDM bugtracker. If you don't care about even framerate, the least you can do is to have an upper limit brought down to e.g. 30 fps. That will make gameplay much smoother than constant jumping between 30 and 60 FPS. For one, I was criticising your models and the Matter of Hours, and there were very good reasons for that.

I just got Xpadder myself, but none of the profiles here is intuitive or in line with controller layouts used in other FPS games. Typically, left stick is for movement, right stick is for moving camera around. B is for cancelling things or crouching (in some games it's RStick button, but it's quite uncomfortable to use frequently). RTrigger is for attack, LTrigger for block/reload (usually). A is for accepting things, using stuff, activating things, or jumping. X is also good for using stuff, activating etc. Y is sometimes used for jumping too. RStick for zooming is ok. D-Pad is fine for selecting weapons and/or inventory stuff, although with X360 controller, especially a new one, you have to press these directions quite hard to get an input. Start button is always the menu button (ESC). Back button is ok for maps, or maybe objectives? I'll try to come up with something of my own, if the time allows

I agree about the question of art style, fortunately DR allows for different methods of world building, from the old-school all-brushes approach to the usual "bsp blockout -> all static mesh" workflow. What I disagree though is on dismissing technical aspects of your work as irrelevant, especially with that kind of "Trust me, I'm an expert, 35 FPS is fine" attitude. Now that's counterproductive. Also, it would be laughed off on virtually every other gaming, modding or dev forum in the world, and the OP would be asked not so politely to go away in any general direction

None of our creations is perfect, ever, and that's fine But, making sensible assumptions and learning about the tech and the tools first is exactly what people do before jumping to anything. It's what both pros and amateurs do, and it's exaclty what I was doing before I started making anything more complex in DR. It's not unrealistic, and it's not some arkane knowledge. TDM engine has all the measuring tools needed for that, and you have learning material on that freely available on the Internet, whather it's TDM wiki, mod wiki, or level design sites or youtube channels. Nothing is stopping you from finding them, except for your own attitude of course. And what is most important, it's good both for you and your players in the long run. For you, because if you maintain constant high fps, minor problems won't matter that much. You have a script that brings performance by 5 FPS, and you can't find what it is? Not a huge problem, if everything else works fine. When you have the same scene running in 15 fps, that is a huge problem. What will you do, delete lights, cut your art or other content to compensate, or just leave it like that? You know well how hard it is to cut content you spend so much time on making. If you leave it like that, players will be frustrated. You release something, ask for their precious free time to play it, and then you waste it with technical problems that could be avoided entirely. Again, stuff like that is not some unachievable goal. These days it's the norm, and there's no use fighting it. (Why would anyone want to anyway?) Learning and practising these things will only lead to you being a better mapper.

I made two TDS missions, although the first one I made was downright terrible, as often first missions are That said, you can indulge yourself in a typical TTLG self-congratulatory fashion, but I don't see why we should pass this toxic atidude to new authors. There's no reason they should be discouraged from making decent things and being technically proficient. And you know, actually learning level desing-related stuff that's really helping them in the long run.

It's a kind of an argument, when you kept making the same spelling or grammar mistake for 10 years, and when someone's calling you on it, you boast on how long you have been writing. The mistake is still a mistake, even if made for 10 years without anyone pointing it out. In this case, all the world of both amateur and professional level design is against what you say. Or, to frame it in another way, it's kind of like making a 4k movie and display it on old 10" CRT. You're not respecting your own work. In this case you also don't respect the players. And you prove that you haven't mastered your craft well enough.

Nope. Unless you run TDM on a 6-year old laptop, this is not fine and never will be. It means the engine is struggling with something. It's also much better to strive for target FPS (so 60, with vsync on) all through your mapping / production process. If you leave it for later, the situation will only get worse, as you'll always run into other problems and won't have time for everything.

Have you tried using LOD system, at least its hide_distance option? Configuring proper LOD sure is time-consuming, but it helps a lot. AFAIR, you can even hide lights this way.

I wonder why the framerate is so low, the geometry doesn't seem complicated.