MirceaKitsune

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?

Glad to hear it's not just me who still wants this. I believe others stated they find DOF useless or not worth the effort; I didn't agree either but seeing everyone was against it I stopped focusing on the matter. I'd still love Depth-of-Field as a feature: I have no doubt it would make every FM look even more beautiful and amazing if done right. I'm remembering a bit of what I did in my final test. I think I never shared it at the time, I should do so as a template for others to experiment with. I don't think I can get more done on my own, please see if you can make anything of it. DOF.zip To test it I believe you'd unpack that in the active FM then set "g_testPostProcess dof" in the console to activate it. Use "reloadDecls" and "reloadGLSLPrograms" to test changes without needing to restart TDM, this way you can just Alt + Tab switch to make a modification then see what it does. I think in that archive I was able to copy the basic blur filter used underwater and draw the depth pass: It draws copies of the view with slight offsets to create the illusion of blur. What I got stuck on is making the depth pass influence this blur, I couldn't find a way to convert the brightness of the depth image into custom coordinates for the offset passes and distort them accordingly.

I haven't made any updates to this recently, and generally I'm bad with names: Feel free to give it any name you wish in the mod pack! Thank you and I'm happy you like it, hope others will enjoy giving this a go in practice

Ahhh, got it! I wasn't sure if it's for universal mods or FM specific mods only: We get deeper customization in some missions but rarely any global mods you can run with every FM. Very happy global modding is getting some attention! In that regard I once made a complex damage system which allows taking damage per limb, inspired by the first DeusEx game. It later included support for augmentations that give you special abilities as you upgrade them... problem is I think that part remained unfinished, and the upgrade items would have to be placed by maps which is an issue. The two scripts should be easy to separate though... I guess I'll share it too in case anyone can make use of my final work on it.

Is this the right place to suggest including a mod? If so I'd like to propose the keypad I made: The mod introduces keypads that require a code to unlock, eg: 1337 then press confirm. Comes with two versions: A modern looking one (supports typing words in SMS style) and a steampunk variant that looks older and worn out, both use existing textures and only include simple models for the keypad body and buttons. Created for a somewhat scifi campaign I'll likely never finish and I'd like other mappers to easily find it and benefit from this too.