peter_spy

If the stairs and the wall were BSP, and stairs were touching the wall, errors probably were there due to geometry splits. You should investigate such problems with wireframe turned on.

While the code and software is different case, it's not like companies selling "real" goods aren't tying to exploit that tactic. Some time ago, I saw Bose license agreement, which explicitly stated that you can't resell products you bought in USA; only Bose authorized resellers can do that. IMO that kind of attitude is a good enough reason never to touch anything they make.

They really don't, speaking from experience, 2k textures for everything. And they're not slowing down the editor as it uses quite aggressive mipmapping. +2 seconds to loading time is nothing in comparison to time and space wasted for separate preview textures.

There is no point in using separate jpegs for editor preview, it'a waste of time since Dark Radiant needs only a few seconds to load diffuse textures used for the same purpose. Even with 2048 textures it just takes a moment, and the editor handles them well during mapping, no slowdown or anything like that.

Yup, definitely jpegs shouldn't be used as they cause a lot of problems due to their compression format. You should use either uncompressed .tga or .dds with proper compression mode. And you should always keep original files in your app native format, like .xcf for Gimp, so you can return to it later. If you save your file as .dds and then make changes to it, and save it as .dds again, you'll be stacking compression and lose detail with every such change. Also using levels to get the texture output to pure white or something close to it is better, because then you can control it with light intensity in DarkRadiant. If you leave your white level at e.g. 128 and setting the light to RGB 256 will still be too dark, you'll have to make changes in the image again. At least maintaining some workflow consistency here will help you with more predictable lighting settings.

True, in this case it would be faster simply to adjust the input levels to increase the contrast. You played with that for a while, but then switched to the output levels, and then gave up because you didn't get the desired effect.

Hah, I wasn't literal, if that's the case that would be like 20 seconds Anyway, this is a time-consuming and inflexible method, imagine painting over something like this:

You don't have to struggle like that, at least in Gimp there are two options for simplifying colors: Threshold and Posterize. You can use either of them to have black and white image, and then you can blur it a bit, for projection. And it will take you like 2 minutes instead of 12.

IMO the weirdest thing is that it actually impacts performance on 2.05, which uses only one core. That would mean changing the option messes up the cpu>gpu pipeline somehow.

Yup, I used com_fixedTic for TDM 2.05 as well. IMO it would be great to ask other forum members with Nvidia cards to toggle between Auto and Off for Threaded optimization, and to note their results (using com_showFPS or other frame rate meter). By the way, it seems that newer Nvidia drivers (my version is 398.36) don't have Multi-display/Mixed GPU acceleration option available any longer.

By the way, this section http://wiki.thedarkmod.com/index.php?title=Performance_Tweaks#.28Nvidia.29_Disable_Threaded_Optimizations seems plain wrong for my new configuration, for both TDM 2.05 and 2.06. When I disable threaded optimization, the framerate in Briarwood Manor tanks to 25 FPS again.

I think I have some good news in terms of CPU scaling. Until recently, I had an old 1st gen i7 950@3.02 GHz, paired up with 16 gigs of RAM @ 1000 MHz, with GTX 1060 in 1440p native resolution. Any mission having more than 3500 drawcalls per scene made the framerate go down below 60 fps. Other factors scaled up pretty well, perhaps due to relatively new GPU (300k of shadow tris seemed impressive, where the recommended value is 80-100k). A few days ago I built new Coffee Lake-based rig, with i7 8700 CPU @ 3.2-4.6 GHz (Auto preset), 32 gigs of 3000 MHz RAM and the same GPU as above. Results have improved a lot, and demanding scenes from FMs like Briarwood Manor or Northdale Act I run in 60 FPS now:

Not sure why you're moving from Unreal then, with almost everything UI-based and with blueprints you need less programming background than ever before. Idtech4 isn't super 3d artist-friendly. In ideal situation you'd want to pair up with a programmer, as stuff like shaders, scripts or defs have to be written manually with the notepad.

It's the same as with textures and materials; textures don't work by themselves, you need material file with definitions to tell the engine how to make a surface out of them. Same with sounds. If you want to replace anything there is in TDM, you need to mimic TDM folder structure and file names in your fm folder. You can see how paths look like either in editor or inside p4k packages. Or, you can unpack them all to have direct access to all assets and directories (remember to delete pk4s afterwards).

That's true for Win 7, and also the whole thing with products as services or subscriptions IMO is a big problem nowadays. It mostly a benefit for companies that make them. It's something they want, and not something I need.

It works, thank you! Now I can make gifs or short clips showing models and materials.

I'm back learning camera stuff, studying Grayman's tutorial. While he did stationary and moving cameras, and also stationary cameras following a moving target, I can't find a case where a moving camera follows stationary object. It seems like using target_null doesn't work, i.e. it sets the initial orientation, but the camera doesn't stick to it, as it moves along the spline. I tried using Grayman's method of following the guard with stationary camera, i.e. using the target_setkeyval to update the camera to use target_null every frame, but I get an error at the line where the thread for camera update is used, the error says "unknown value update_cam1": void cs_cam1() { sys.println("Roll1 running"); // debug $player1.bind($mover1); $cam1.activate($player1); // Switch view thread update_cam1(); // Call the function update_cam1() as a thread so it can run in parallel $mover1.time(15); // How many seconds it will take to move along the spline $mover1.accelTime(1); // How long it takes to accelerate $mover1.decelTime(1); // How long it takes to slow down // $mover1.disableSplineAngles(); // Allow the camera to point in different directions as it follows the spline $mover1.startSpline($spline1); // Start the func_mover $mover1 moving sys.waitFor($mover1); // Wait for $mover1 to finish its movement $player1.unbind(); sys.killthread("aim_loop1"); // Kill the thread "aim_loop1" $cam1.activate($player1); // Return control to the player } void update_cam1() { sys.threadname("aim_loop1"); // Gives this thread the name "aim_loop1" so it can be killed later. while (1) { sys.trigger($target_setkeyval_1); // keep cam1 pointed at target_null_1 sys.waitFrame(); // wait a frame before continuing } }

Probably not in the next few months, I'm afraid. Although if you point me to a TDM model and its reference (concept art, photos etc.), I'll see what I can do.

Thanks, it's always nice when someone notices the details and amount of work that goes into this For my project I'm making every model, surface, and texture from scratch, so using 2k textures won't be a problem, but when the model pack gets released, mappers will have freedom to scale it down, if they want to mix it with base TDM assets.

Making new furniture, having fun with shaders, while still getting optimised results. It's great that you can do so much with glass, basically every aspect is covered in the engine. I can control transparency, specularity, add fake cubemap reflections, and control refraction. And I can still do it all just with base set of _d, _n, _s textures and proper unwrapping.

At least from the trailers, the first one looks like a big budget, play-it-safe flick with cringeworthy dialogue. But look, so many graphic designers had to work on this! I'm much more curious about the second one.

It's not about unfinished work in the "abandoned" category, with permissions to be used by the community. I was talking about the loss of talent, and the people discouraged by the way their work was treated. That's why talks like this one, about practices and "work culture", are both interesting and important.

Just to be clear, I never voted for any kind of DRM system in TDM, and I never will Obviously, the community wouldn't tolerate maps being stolen. The real problem is people leaving the mod without making all the things they could have made, or stuff they had in progress.

True, and I'm sure that would work within TDM team or among regular forum members; most people been here long enough to know, more or less, what to expect from each other. It's not that simple with newcomers, though. Case in point: Some1stoleit's map. He couldn't have any idea what he agreed to. He even seemed to be amazed with that kind of "support".