peter_spy

Thank you! I'll look into it as soon as I finish sculpting base models.

I'm making candles right now, and I guess I'll have to give them some basic functionality like flame and smoke particles, as well as the ability to be extinguished by player, whether by frob or water stim. Any idea where I should start looking that kind of stuff? I tried to use candle_tall as a reference, but couldn't find it, neither in defs nor in light scripts.

The problem is, it's often the same industry veterans who ask for money. Tim Shaffer distorted the whole idea in the very beginning: devs ask for cash and go to publishers next, which defeats the whole concept of crowdfnding. AFAIK, crowdfunding works better for stuff like independent movies or theatre plays.

I believe that's way too much to ask of anyone. That would be enormous amount of work. That's why no one ever did it.

It's not that easy, I'm afraid. A lot of things were locked out and hardcoded, either because it was some proprietary tech, or to meet performance limits or constrains, e.g. for original Xbox. There's practically no way to patch or reverse it.

Oh, so you can do that? That's actually a standard thing for many games (at least I see it a lot in third person titles). I just didn't think it was possible for TDM.

For reference, this is Thief Reboot control scheme (I don't like it much tbh):

It's a slightly changed Dishonored control scheme, so it's not like I came up with it entirely on my own, or only for my taste. Also, you can't bind all the keys to a gamepad, obviously. You have to give up some of them. Edit: Not sure what you mean about analog speed controls, but I didn't find the way to have analog movement controls, only camera uses that in TDM. WSAD (or WASD) keys are just two-state. If you just meant switching camera controls and movement, that's mostly your subjective preference. I feel like this convention has been in games for decades now, I can't remember a game that would use anything other than left stick for movement and right stick for camera, and that applies to all the genres, at least for X360/One controller.

I have most keyboard controls remapped to my liking, so my Xprofile isn't super useful, but using Dis2 control scheme I came up with something like this: Left stick: W, S, A, D Right stick: mouse Right stick button: walk/run (toggle in_alwaysrun 0 1) Dpad up/down: previous/next inventory item Dpad left/right: previous/next weapon X: frob Y: use inventory item A: jump/mantle B: toggle crouch LTrigger: parry/manipulate Rtrigger: attack Left and right bumper: lean left/right Start button: ESC Back button: map I think that's pretty good starting point, works good in game.

Not really, it just has quite a few keybinds. But so does e.g. Dishonored 2, which can be easily played with gamepad. Instead of trying to reinvent the wheel, I'd just take a look at one or two control schemes and try to make something similar for TDM:

While there's nothing wrong with liking and playing TDS (I still do that), making maps for it will end with frustration, disappointment, and a lot of your time wasted on everything but mapping.

Yup. I ended up using 52 AIs, a small army of pagans and builders With time stopped the framerate was 60 FPS and DCs were around 2,5k. Animations or AI thinking (or both) brought framerate down to 19 FPS.

Yup. If you want to create TDS mission based on original content – this stuff uses 256 or 512 px textures. It looks horrible today. John P's pack helps a bit, but not much. While graphic capabilities seem to scale with hardware a bit, actual process of making new content is a chore. You need 3dsmax 5.1, excactly this version, with some dev plugins included in the editor. This stuff doesn't work with win 7, so you'll need win XP on VM. The software itself is a horrible modeling tool, by any standards now, so it's only reasonable to use it as annoying middleware for exporting meshes and materials. The editor itself isn't hard to use, because it's Unreal 2.x, but everything that lies underneath isn't. If you're good at creating maps and game content, I mean really good, you might even create something decent, at least visually impressive (I had several WIPs like that). But, for almost everything you do, there's a tricky side or workaround or limit that you need to keep in mind. In essence, T3 doesn't let you make any mistakes during production. While the entity limit is twice as big as in TDM, it has this weird thing, where anything you place in the map, whether it's a brush, model or AI, "leaves a mark". You never get back all the entities used by properties of a thing you place in your map even if you delete it later. It basically means you can't learn or experiment, at least not in your main map. Even if you want to be like the pros and use brushes to prototype stuff and then replace it with static meshes, that entity thing makes it difficult. Also using BSP for anything else than carving out empty spaces is a problem, you'll encounter missing triangles and glitches every time you'll try to make something more complicated than a brush box. As for static meshes, should be able to make much better models than in base game, but you'll have to deal with broken material options. You can have diffuse and normal textures, alphas, emissive maps, and cubemaps will work to some extent. There is no proper specular suport. If you haven't worked with speculars before, you have no idea how important that element is to a surface definition. It's a game-changer. If you take your time to experiment with major TDM material components (diffuse, specular, normal), you'll discover beautiful synergy that will make your surfaces look stunning, in both direct and ambient light. Making stylish shaders is a lot fun, and you don't even need complicated material definitions for that. There are many more things like that, i.e. in TDS you can't even build too far away from 0,0,0, because for some reason shadows start to look weird. Never measured the actual distance, but I encountered that problem several times. Debugging scripts is a nightmare, at some point I placed a bell sound at every script stage to see whether it worked (imagine the headache when all bells rang, as everyting worked for a change). There's no way to know for sure why some solutions work, and some don't. That kind of applies to everything T3ED-related, so maybe I'll just leave it at that The biggest problem though is gameplay. It's not even about lack of water (I never cared much for that) or even rope arrows, although they can be a powerful player tool, if map is designed right. The biggest gameplay-related problem is player movement itself. It's supposed to be smooth, seamless, and fun. Floating Garrett bug, along with broken "body awareness" makes it a shadow of what it's supposed to be. Mantling is a game of chance. Because of the way body turns with the camera, you can't even walk and turn around on beams or ledges (they need to be wider than 32 or 48 units, which is insane). While I don't think Garrett's supposed to be an acrobat, in T3 he's almost a cripple.

Huh, I only got to 20 AIs in a blank box, and the framerate is already down to 35 FPS. It gets back to 60 PFS when there are 15-16 AIs walking around. No crowdy places then

Probably not, or only to the extent that operation of drawing triangles is part of CPU to GPU pipeline. In that regard I have to include CPU being busy with both drawing triangles and other tasks. Still, I'm not a programmer, so it's more guesswork than scientific results. I might do that AI test as well. Rendering tests apparently show huge capabilities and engine scalability, at least on Intel/Nvidia based systems like mine.

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.