MirceaKitsune

If it wasn't I imagine panic would ensue, as this would be equivalent to starting from scratch and most FM's would be lost forever only playable on archived versions of TDM.

I remember how I spent a month trying to implement bounce light estimation, couldn't keep the lights from leaking through walls though. We concluded this will require a deep engine change to do anywhere near right. Still dreaming for that day

Thank you for your responses. I'm glad there are others wanting to help in this. Clearly I won't be able to do it alone, there are too many new assets and features and special scripts that will be needed to achieve a proper cyberpunk conversion. At the moment I'm sitting a bit on the sidelines, have withdrawn from TDM and most FOSS projects. I've had certain experiences that have me very nervous of being active in other communities at the moment. I may try talking about them in private eventually... if I feel comfortable afterward, I may contribute simple mods and fun stuff again. Thanks for understanding.

Is that cake an interactive food type you can grab and consume? If that would be possible I'd do it just for fun

This was amazing, absolutely loved it! The atmosphere was very pleasant and well established, for such a large mansion map it's well detailed at every point. Scary as it gets too, you definitely play this one nervously and in a good way! I also like how progressive it is in what you discover and where you must go, I'm sure there are more secrets to find. Unfortunately I couldn't complete many of the optional objectives on my first try so I should get back to this and do another run eventually.

It did a good job at that: Small map but it felt detailed, there are FM's with larger environments that don't achieve the same feel and intrigue. It will be nice to see which new FM's you plan on making.

What a nice FM! Played it just now and really enjoyed it, very good especially for something short. Managed to find all secrets as well, was only short of 50 loot

That sounds like a good idea for those who want to turn it off. I'd make the alpha a slider in the menu also. When it's set to 0 though, the engine should know to skip drawing it so it also recovers performance.

Thanks: That would explain why I'm getting it with preset 1 whereas 2 mitigates it. I'd default the alpha to a lower value then if possible, the highlight is pretty solid anyway and less intensity may look better.

No more updates since last time I'm afraid. I can't get it to work right without engine changes, and so far no one has a plan in that regard. I'd really love it but unless a core dev finds a better solution I don't know how much further this can go. I have a proper idea in mind, but it needs someone implementing it. My idea is essentially a realtime voxel cubemap painted from the brightening of surfaces by lights, with each 3D pixel casting some radial fuzz in any zone hit by a bright lamp... a bit like 3D bloom in light casting if you will. That would be the equivalent of one bounce and also take into account the colors of surfaces for more realism. It could be done automatically per-light or with one global light... obviously I prefer the option which enables it on any map without requiring an entity being placed by the mapper, most old FM's will never have this then.

I very much like the new implementation! Sharper and more accurate in many ways. Unfortunately it will not help much with geometry reliant on alpha textures, that might look ugly for a handful of assets. Only one issue I'm seeing so far: It's causing bright speckles at least with my bloom settings. If it's shader based the outline should probably be processed after bloom not before it.

Thank you for your work and implementing all those different methods! I'm glad the feature is still working well by default in one form or another, that's what matters in my opinion. It will be nice to give the new one a test, will let you know what I think after that.

The mod enables it for all of the default lights which was my intent. At the moment this one is on hold I'm afraid: The engine developers don't seem to have a satisfactory solution to fixing the wall leak issue, I'd have to make a scriptobject to resize the light in realtime using traces which would be slow and complicated to do. The mod is usable but at the moment will produce ugly cutoffs in front of portals as well as bad performance.

Not sure if this is the perfect thread for it but: I recently discovered the cubemap sky lights, and love that there's now a system to support detailed global lighting and reflections! There is however an odd problem: All of the default skies (lights/ambientcube/skybox_*) will also produce sharp reflections on surfaces where they shouldn't... if you don't set the intensity lower (_color 0.1 0.1 0.1) you're going to get even people looking like they're made out of glass

I see, so some of it is intentional. I can see this method having its uses, but at the same time it's still making some things a lot harder to work with. Could we have an option in the preferences to get the old functionality please, or perhaps a toggle button in the surface inspector itself? In any case there's definitely breakage: If I use the rotate button on a surface with a texture of unequal proportions, that texture gets stretched out as you rotate it. This occurs solely by clicking the 45* rotate button twice... simply inputting "90" into the rotation field does the same thing.

Unfortunately there's one remaining set of issues left: Texture scaling and rotation are completely broken in the surface inspector, giving random inconsistent results each time the values are changed. For starters, scale values no longer represent the same thing for rotated textures of uneven proportions. In the two screenshots below I'm selecting two different surfaces, both have the same texture at the same scale and no shift just at different rotations: One is accurately depicted at scale X = 0.125 Y = 0.125, yet the second it appears as scale X = 0.03125 Y = 0.5. The rotate button is itself adding random offsets when used. I have the increment set to 45*, the issue appears to not occur when I set it to 90* so it must be something with uneven angles. When clicking the arrow to rotate that face, it gets rotated by the desired amount, however an inexplicable offset is also applied to the texture. In the second screenshot below you can see the face gets a horizontal shift of 237.813 and a vertical shift of 149.961 for no reason... the shift should remain unchanged, both 0 in this case. Clicking on the arrows to scale textures is acting up as well: I have my increment set to 0.125, yet when I hit its button the texture doesn't get scaled from 0.25 to 0.125 as desired, instead it goes from 0.25 to 0.22222. On top of that a horizontal shift of 128 is added out of nowhere in this case as well.

Someone mentioned a new brush management system on Discord, they didn't know it was merged yet so they asked if I'm still on Git master and I said yes. Updated and recompiled, can confirm it's fixed and everything seems to be working well and as intended again. Thanks for the quick solution and another great update too!

Compiles successfully now! Thank you for the help.

Done: https://bugs.thedarkmod.com/view.php?id=5770

Interesting. I do a "git clean -dfx" and use a fresh build directory so it should be as fresh as it gets. Testing again on the map I noticed it with, I can see it's only affecting some brushes, like a visportal for a specific door. I made a copy of the map leaving only the visportal in: Open this map in DR, select the vis brush at the center, then use the rotate Z shortcut button. You should notice the brush disappear and the selection marker stretch out to infinity. test.map

Big bug in latest DarkRadiant Git master branch: Brushes are disappearing when you rotate them or use space to duplicate. If you keep the brush selected, the boundary markers in the 2D viewports indicate the now invisible selection is stretching out to infinity. This must have been introduced sometime this or last week: I updated and compiled DR roughly a week ago and don't believe I was getting this issue, it started occurring after I did so again last night.

I just commented out the lines you suggested in CMakeLists.txt and redid the cmake setup: Same issue. Yet I managed to fix it: Doing a fresh SVN clone resolved this problem. I have no idea what could have gotten stuck in the old one... even after a fresh build directory, no errors from SVN itself, and two different SVN reset commands. Compilation now works up to 77% after which it fails with a standard compile error. To avoid making a new thread I'll just share it here, something in the engine code is unhappy with my compiler or OS libraries I take it? [ 77%] Building CXX object CMakeFiles/TheDarkMod.dir/game/physics/Physics_Player.cpp.o In file included from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/Game_local.h:1248, from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/build/TheDarkMod_pch/precompiled.h:105: /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/physics/Physics_Player.h: In constructor ‘idPhysics_Player::idPhysics_Player()’: /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/physics/Physics_Player.h:980:49: warning: ‘idPhysics_Player::m_bMidAir’ will be initialized after [-Wreorder] 980 | bool m_bMidAir; | ^~~~~~~~~ /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/physics/Physics_Player.h:975:49: warning: ‘float idPhysics_Player::m_fPrevShoulderingPitchOffset’ [-Wreorder] 975 | float m_fPrevShoulderingPitchOffset; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/mircea/Games/Quake/TheDarkMod/engine_SVN/game/physics/Physics_Player.cpp:3021:1: warning: when initialized here [-Wreorder] 3021 | idPhysics_Player::idPhysics_Player( void ) | ^~~~~~~~~~~~~~~~ In file included from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/Game_local.h:1248, from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/build/TheDarkMod_pch/precompiled.h:105: /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/physics/Physics_Player.h:977:49: warning: ‘idPhysics_Player::m_ShoulderingStartPos’ will be initialized after [-Wreorder] 977 | idVec3 m_ShoulderingStartPos; | ^~~~~~~~~~~~~~~~~~~~~ In file included from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/Game_local.h:1248, from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/build/TheDarkMod_pch/precompiled.h:105: /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/physics/Physics_Player.h:273:49: warning: ‘float idPhysics_Player::m_fSwimTimeStart_s’ [-Wreorder] 273 | float m_fSwimTimeStart_s; | ^~~~~~~~~~~~~~~~~~ /home/mircea/Games/Quake/TheDarkMod/engine_SVN/game/physics/Physics_Player.cpp:3021:1: warning: when initialized here [-Wreorder] 3021 | idPhysics_Player::idPhysics_Player( void ) | ^~~~~~~~~~~~~~~~ In file included from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/Game_local.h:1248, from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/build/TheDarkMod_pch/precompiled.h:105: /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/physics/Physics_Player.h:278:49: warning: ‘idPhysics_Player::m_fSwimSpeedModCompensation’ will be initialized after [-Wreorder] 278 | float m_fSwimSpeedModCompensation; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/mircea/Games/Quake/TheDarkMod/engine_SVN/idlib/../game/physics/Physics_Player.h:274:49: warning: ‘bool idPhysics_Player::m_bSwimSoundStarted’ [-Wreorder] 274 | bool m_bSwimSoundStarted; | ^~~~~~~~~~~~~~~~~~~ /home/mircea/Games/Quake/TheDarkMod/engine_SVN/game/physics/Physics_Player.cpp:3021:1: warning: when initialized here [-Wreorder] 3021 | idPhysics_Player::idPhysics_Player( void ) | ^~~~~~~~~~~~~~~~ /home/mircea/Games/Quake/TheDarkMod/engine_SVN/game/physics/Physics_Player.cpp: In member function ‘void idPhysics_Player::PerformMantle()’: /home/mircea/Games/Quake/TheDarkMod/engine_SVN/game/physics/Physics_Player.cpp:5099:50: error: ‘numeric_limits’ is not a member of ‘std’ 5099 | float floorHeight = std::numeric_limits<float>::lowest(); | ^~~~~~~~~~~~~~ /home/mircea/Games/Quake/TheDarkMod/engine_SVN/game/physics/Physics_Player.cpp:5099:65: error: expected primary-expression before ‘float’ 5099 | float floorHeight = std::numeric_limits<float>::lowest(); | ^~~~~ make[2]: *** [CMakeFiles/TheDarkMod.dir/build.make:5856: CMakeFiles/TheDarkMod.dir/game/physics/Physics_Player.cpp.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/TheDarkMod.dir/all] Error 2 make: *** [Makefile:91: all] Error 2

gcc 11.1.0-1, make 4.3-3, cmake 3.21.3-1. To be extra sure I don't have any files from the past breaking it, I did a "svn cleanup . --remove-unversioned" and "svn cleanup . --remove-ignored" which also removed the build directory entirely, and of course "svn update" is up to date with the repo: Still the exact same thing.

Trying to compile the engine from SVN again on Manjaro Linux (KDE Plasma): I did a svn update, generated a fresh build config with cmake without issue. Yet when I run make the console is spammed with lines of messages mixed with weird symbols for a minute, after which I'm given a fail message. I managed to attached a log of it: Had to compress it to get it down to 1 MB, the output is literally 100 MB large. This link should work, let me know if you can't see it. https://cdn.discordapp.com/attachments/323539482605387787/893221858382594078/make.tar.gz [ 0%] Copying header [ 0%] Precompiling header In file included from /home/mircea/Games/Quake/TheDarkMod/engine_SVN/build/TheDarkMod_pch/precompiled.h:99: <thousands of lines of code madness here> make[2]: *** [CMakeFiles/TheDarkMod.dir/build.make:80: TheDarkMod_pch/precompiled.h.gch] Error 1 make[1]: *** [CMakeFiles/Makefile2:82: CMakeFiles/TheDarkMod.dir/all] Error 2 make: *** [Makefile:91: all] Error 2

I have an even better proposal for doing light cutting, aimed at achieving the same two benefits: No wall leaks for my irradiance lights, plus a performance optimization for all other lights by discarding areas they can't reach before calculation. Essentially the same thing but portal independent and done per brush. It's better as it's not regarded as a hack like areaLock, and will also work for brushes that aren't part of any portal (eg: little side walls). It should be about as cheap too since we'd only do this for worldspawn, simple geometry typically involving a few 8-vertice cubes (and we could discard the back-faces). The light simply loops through all worldspawn brushes it intersects preforming the same intersection check: If that brush or a set of overlapping brushes block that direction without leaving any cracks, so that no vertice / edge / face of the light's box reaches past that brush and the brush fully stops it, the light is cut and discards everything behind those brushes.... obviously if the brush in cause is using a non-transparent texture, and we include closed portal doors here. As Cabalistic pointed out, it can (kind of) be seen as duplicating the functionality of shadows, albeit it doesn't feel anything like shadows to me: It's a way of chopping the light before we calculate any lighting and shadows to discard what that light doesn't need to see... think of the light as a normal cubic brush in Darkradiant, then using the brush cut tool to cut 2D planes across it so it doesn't go through other brushes. What I'm suggesting here is NOT volumetric projection as we don't project anything: We'd only cut the light's box to a convex shape (no inner holes) when it can't get past a set of surfaces before deciding what gets included in its calculations.