MirceaKitsune

I realized a fun change we could consider for the lightgem, which should also be fairly easy to implement if agreed upon. We know how aside from the amount of light shining on the player, some FM's increase the lightgem based on movement and crouching, you become more visible while walking and especially when running. I'd like to ask if anyone thinks we should additionally support a slight increase to the lightgem based on mouse movement. Explaining how the idea came to mind is the best way to illustrate why I feel it would make the experience more fun. The player often hides in a dark corner waiting for a hostile AI to pass right by as they patrol: In any real scenario you'd be holding your breath as to not make any sound or the slightest movement, even breathing would stand out slightly and could get you spotted. Thus from a perspective of realism, it feels out of place that I can zoom the mouse all over without any consequence... merely turning your head would draw a bit of attention, let alone looking behind which implies the player turning their whole body around. Meanwhile from a gameplay perspective, it could be a welcome challenge having to not move the mouse when a guard is right next to you, keeping your mouse steady similar to how you'd hold your breath as you wait till the danger passes to look away... this would feel more exciting and add a new form of tension, especially as many players complained the AI feels too easy even on the highest difficulty settings. Obviously the increase should be minuscule, possibly just 1 lightgem point: We don't want players feeling they can't look around while hiding, just not doing it too much when an enemy is right in your face. The best way seems like making it based on the movement speed: Moving the mouse very slowly could have no penalty, whereas jerking it suddenly could increase the lightgem by a few points so even in total darkness the AI sees something and may even catch you if you keep looking around rapidly while next to them. Another debate is whether this should be a spawnarg new missions have to configure, similar to some existing visibility properties and lightgem offsets. Personally I'm in favor of defaulting it to a low value, just 1 lightgem point increase if it's fixed or something like 3 if it's speed based. Alternatively we could tie it to the difficulty setting... if it's controversial maybe just implement it as a hidden cvar we can try out? Very curious what you think so let me know your thoughts, I'd definitely like to at least see the concept tested!

Very enjoyable FM overall! I got stuck on the main objective but managed with some hints. Plays well and looks very beautiful: If you noclip you can see several mapping artifacts but it's not a serious issue.

From what I understood last time, lights now use portal culling and solid walls to dump unreachable entities, correct? So if a torch is located in a room and its radius box covers entities in a neighboring room but the light doesn't also touch any portals through which it can reach that room, those entities are ignored. I'm curious if lights also use a projection check like the player view. So even if a room is opened by portals from the perspective of the light, an entity is still ignored if the light's origin can't shine over the bounding box of the entity through any open portals leading to it. Hopefully this is the case by now, hope it's planned if not as it sounds optimal. Last time I asked, it couldn't be determined if spotlights still calculate entities in an omnidirectional 360 field like normal lights, instead of only looking at portals and entities within their cone. If this is the case I support making some of the default hooded lights targeted as an optimization, given some are omnidirectional and self shadowed in a way that the upper area is covered but still calculated. An obstacle I remember encountering is at the moment, there's a limitation in both DarkRadiant and TDM engine that prevents targeted lights from having an origin offset, even if the origin spawnarg is set the center falls back to the entity's position making this unusable on some lamp models.

And completed! Amazing FM overall, it did a lot with a relatively small space. One of the creepiest FM's I've played, even if Exhumed is the one I remember terrifying me the most many years ago.

Had to wander in and out several times to find that one. If you want a clue...

A nice FM for a quick run, I liked it. The architecture seemed a bit surreal at first but it's in a good way. Seems to have slight performance issues compared to the average FM, though this is unavoidable when working with large areas so it's understandable.

Oh, I see it now! Does this FM...

Was going to try this one out but apparently there's an error that doesn't even let the map load: FM installed from the official mission download menu, TDM dev16829-10455 on Linux.

Congratulations on your first FM! Not bad for a first one: It was simple and a little rough in places, but played very well and did what it intended to. I'd definitely like to see a continuation and what happens next after the events here.

What a beautiful FM! This absolutely rivals some of the best made recently such as Seeking Lady Leicester. It's filled with secrets and unique interactions, as well as a huge city divided into differently themed areas which is something I love about such city hubs. It was lovely to go through and offered quite a few days of fun, thank you! I suspect I found most secrets in terms of hidden areas items and objectives, though with how large and complex the world is I know I must have missed something and still would if I played for months. Other than that...

I was just thinking about this last night and mentioned it on Discord: One of the advantages of leaning should be that using it to peek past a wall shouldn't make you so visible to an enemy AI. If there's a light past the corner, leaning will currently increase your lightgem about as much as just strafing there, which begs the question why should you even use it instead of just strafing? A strong light should make you visible even when leaning, but only a fraction as much as walking there. I'm thinking of it like this: Leaning should be like sticking just your head beyond a wall. It makes you a little visible if the area is well lit and the AI close by to see you, but far less than your whole body sticking out and being spotted.

All in all I like the new mode judging from that video. Hope we can give it a try in the next dev snapshot! Pro: More movement over rotation... more logical and realistic, before it's like your head was just falling to the side. Con: The overall distance seems to be a little bit less than before, which may make leaning less efficient than it was.

I turned off both bloom and sharpness filter, yet AA continues to generate fully sharp edges around that newspaper. Now it's really peculiar... wonder if anyone else can reproduce this? FM Iris, getviewpos: 4251.78 123.7 -271.75 9.2 -30.5 0.0

Is bloom causing it? Didn't think to try that: Just started the FM so next time I pass by the area I'll try that as well. Also the sharpness filter even if it's at a low setting, I'll feel silly if that was literally undoing the effects of AA I was thinking the newspaper being so bright compared to the background might have something to do with it. Though IIRC AntiAliasing scans geometry edges only and shouldn't care about brightness per say.

There's at least one thing I felt I need to ask about: I keep seeing this and it's making me think even conventional AA must be broken sometimes. In any case it's clearly not doing its job right at the moment. I enabled 4x MSAA just to alternate. As can be seen on most objects, it usually works as you'd expect. But then why do I get such sharp edges only on the newspaper? It's not an alpha texture, the model is fully opaque and this is its geometry edge... it should this be subject to AA as anything else, yet it doesn't seem to be affected and still looks jagged. I see this effect on bright lamps sometimes. I didn't report it as I presumed it's a high-res alpha channel which I know current AA can't address. But this clearly isn't the case so now I'm curious what's happening? Edit: The forum insists on scaling the image to a lower resolution so here is the full res.

Right. And if the pointer reaches a screen edge or corner and can't go any further, the view wouldn't be able to keep moving / turning and get stuck... you'd need to disengage then click again to grab it which would be very annoying. I'm well out of ideas. If only the "export GDK_BACKEND=x11" hack wasn't partial: It fixes it for the main views only leaving the model viewer broken, but for some reason activating the clipper to cut brushes breaks that as well and I need to restart DR every time after using it. Maybe we can see what the clipper does to trigger it and patch at least that bit out? One last thing comes to mind: Is there a build flag to force DR to compile without Wayland support? Maybe I can try that to force the whole software to be x11 exclusive which should resolve this, granted wxWidgets allows it.

Thanks: Really sounds like that bug must be the case and what I'm experiencing. Question is if we can use any workarounds on DR's end, which like you said is itself very questionable. I think there would be one way actually: What if DR didn't require cursor wrapping at all? Just translate mouse movement as it happens and don't care where the mouse pointer is located! If the flag is available snap the pointer to the center of the windows / screen for sanity's sake, but if not let it go everywhere without translating the view based on it. At worst this could be done by comparing the mouse movement only between every two frames / ticks, instead of caring about the pointer's start position and expecting it to be in the center?

Oh gosh: That looks incredible when seeing the full image! The FPS it must cost though... so sad it's not practical Technically speaking though, it's an easy way to achieve DOF as well as antialiasing in one go: Just jitter the camera angle which will cause greater differences between pixels (thus blur) the further something is. Meanwhile interpreting light sources at slightly offset positions per sample offers an alternative way to get distance based soft shadows, some performance would be recovered by no longer needing multiple samples per light. There's quite a few things multiple renders per frame can achieve! Is it possible to at least reuse some render data between samples for some kind of performance optimization? Actually I wonder: What if we use past frames so that we don't have to render extra ones in between? This might be what temporal antialiasing does, except we could use it for even more things! I'm actually intrigued in an experiment to test this For example: Let's say we set it to 16 frames. This means the past 16 frames that have been rendered are blended together and you see a mix of their total on the screen. At the same time each frame interprets the camera and lights at an ever so slightly different position / angle using a seed, causing the end result to be a soft average. One problem I see is with fast camera movements: If you look around or run too fast it will likely cause some form of motion blur... then again this might be a feature not a bug, we don't have any motion-blur anyway and it's not like it would be wrong to even if ghosting is the bad sort. Another problem is you could see flickering as lights are interpreted at randomized positions... the way I'm imagining this may cause everything to appear as if it's vibrating which is no good.

I did at some point wonder if the same shader could be used to achieve both effects. My idea was we could have a single blur post-process: Its minimum range would be something like 0.5 pixels to anti-alias sharp edges (both geometry and alpha textures) on top of which the depth map may increase it to also achieve distance blur. Would be a neat trick to solve two problems at once, but it surely won't work the way I imagine it and either not be effective or blur too much. Thus DOF should probably be its own thing, with antialiasing done as a separate shader if and when that happens... at best they may share and inherit from a single component if that's optimal.

Interesting to know! Such jittering could have technically addressed both AA and DOF the right way. But since it means multiple renders per frame that would be extremely slow and not worth it as a solution. The simple and realistic fix seems like a simple Bokeh filter who's intensity is controlled by a range in the depth pass. I remember getting my custom shader to read and render the depth image as a test, it just needs an actual blur shader running with it and to be done in the engine. Then it can also be used underwater and optionally when taking damage or low on health.

So it should be possible to find a generic GLSL shader for Gaussian Blur and / or DOF and integrate it. Just not something I ever worked with and understand well, especially as it requires engine changes. This discussion also came up on Discord though and several other players mentioned they want this, so there's hope and a reason for it happening after all... just hope there's someone with knowledge in shaders who can and wishes to help out.

Wasn't TDM moving away from ARB to GLSL? Actually I think it was but the transition was incomplete so we're still using the former. Wonder what it would be best to do this under today, seems like the later is ideal if it's supported by both post-process as well as material shaders.

My goal was to make / find something that works both as a screen post-process filter for DOF, but can also be placed on transparent surfaces for blurry glass like condensation. We have distorted glass but still no glass that blurs, especially not by using a grayscale map to determine the level of blur so you can have realistic stains.

I should keep this in mind, though note that a custom shader can only be done into the base game: It requires editing the engine and adding this to the post-process phase. The technique I'm using for testing is a custom variable to test custom shaders, it even relies on a fake material mapped to the screen. At the moment I'm stuck on this project, especially as I have little to no experience with shaders... I only shared it in hopes someone else can make use of it. For proper quality this should be done with a Gaussian Blur or Fast Gaussian filter, which the underwater view should also be switched to at that point. Do we have one compatible with the shaders we're using? Maybe Doom3BFG already did something we can use and we could snatch it from there?