MirceaKitsune
-
Posts
2264 -
Joined
-
Last visited
-
Days Won
35
Posts posted by MirceaKitsune
-
-
Here's one I recently found very worth asking: During testing my maps, I find that a lot of func_static models will cause the AI to get teleported on top or bend in weird ways when touching the model or even break pathfinding. At the same time many func_statics will not cause any bad interaction with an AI. Is there a standard way or guidebook to knowing which do?
I mainly ask so I can easily know what I need to draw a monsterclip brush around. For instance I found I need to monsterclip several stairways and pillars and all other sorts of architecture, yet railings and some furniture are fine. I can't draw a brush around every single map model I place, so it would help to have a more standard prediction of what AI will have issues touching.
-
There is a little issue I keep running into every now and then: It seems that if you move the mouse too suddenly while looking around, the view will sometimes snap to a different angle and you find yourself facing the other way around. I assume it's the mouse cursor getting reset when an edge is touched too quickly, or something among those lines?
If any Linux user on KDE / Plasma can try out the dev build please help to confirm: If you keep moving the mouse rapidly and erratically across long distances, you should notice your view occasionally gets teleported the other way around.
-
Another one I forgot about: Is it possible to set an objective to become visible once another objective is failed or completed? I see that till now I had to trigger an atdm:target_setobjective_visibility to make new objectives appear after I complete existing ones, but it feels like this shouldn't have to be needed for inter-objective dependencies.
-
Don't think I'm gonna write a script just for testing, it's not that urgent only if it was simple to do. This would be a nice feature for map testing, might suggest it on the bug tracker sometime.
-
As I might be needing this to do some testing I figured I'd ask: Is there by chance a console command that can be used to trigger an entity on the map? So if for example I type "thetriggercommand trigger_relay_1" that relay fires as if triggered by a trigger_multiple entity for instance. Never heard of one but the team is intuitive so I imagine it might be there! It would be useful to test some effects before I have their proper triggers in place.
-
Found a little bug worth bringing up: Whenever I highlight a door its doorhandle will also flash the outline for a split second. The effect only lasts for one or a few frames after which only the door is highlighted as is proper, but it's noticeable enough to see the handle blinking when you first look at the door.
-
19 hours ago, datiswous said:
Btw. what Kernel do you use? Sometimes switching to a different kernel can help.
5.12.9-1-MANJARO
-
I was thinking of creating a horizontal portal covering the entire area who's face touches against the top of the bottom-most brush, then portaling multiple small areas against the sides of the same brush: This way the top half would be one portal while lower zones would be divided. I might be able to find a better way though... if not I'll just limit the detail I have outside in a worst case scenario.
-
3 hours ago, datiswous said:
I'm sorry, but I'm using Manjaro linux xfce and I can't reproduce this issue, maybe it's in combination with certain hardware?
That's good to know. It might be in that case: Linux has an issue with my microphone which starts acting up the moment I open Audacity, but with sound output I never had any problems. Sounds like I might need to start messing with the OpenAL settings again to see if anything there fixes it. I didn't get this issue in Manjaro over a month ago when I switched to it (from openSUSE Tumbleweed) and I already had the 2.09 TDM release, so it's likely some driver update that introduced it recently. Let me know if any setting I should try tweaking comes to mind.
-
3 hours ago, thebigh said:
I didn't get any leaks or dropped portals, but it's not obvious to me what doing this sort of thing would accomplish. What are you trying to do?
Thanks. As for why I might need this, let's just say it's part of the struggle to find smart ways to portal large outdoor areas for decent performance when the geometry doesn't make it easy to do so.
-
1
-
-
Playing with mapping again so a question for something I may need: Does the engine allow portals to rest against one another? As in can you form a T shape with two portal surfaces, if one is perfectly touching the center of another?
-
Since installing the latest versions of my system packages, I hear a loud and annoying static noise crackling in TDM audio. This seems to be different from my stuttering sound issue which was caused by a bad period size setting in OpenAL: Normal sound plays fine without interruptions or lag, but I also hear this annoying popping noise in my headphones all the time.
I get it in both the latest release (2.09) as well as latest dev snapshot (dev16269-9407), where the later seems to be producing the noise even more intensely. It's independent of EFX and HRTF, I tried turning both off and restarting but the issue persists. No issues in any other games (eg: 0ad, Red Eclipse, Xonotic) only TDM does this. Persists after restarting my system so it's a permanent issue. My OS is Manjaro Linux on KDE / Plasma. Any other Linux users getting this and know what might be the cause?
-
1
-
-
I fixed the mouse capturing issue and am back on latest dev, thanks again cabalistic for the help! Testing with "r_frobIgnoreDepth 0" I can indeed see the annoyances: Doors as well as drawers only have their outline showing on some sides, it becomes hidden when they perfectly touch the frame and its edges cover the item. Further more they flicker in and out of existence as you move around and change angles which looks very wrong.
What would most likely work is customizing it per item: No depth test for the outlines of doors and drawers and other entities integrated in world geometry, yes for buttons and movable objects and other geometry independent actors.
This could be set via spawnarg on the root entities... an arg to customize the color was already desirable. An entity could have the options "frob_color 1 1 1 0.5" to change the color / alpha of its highlight, plus now "frob_depth 1" to decide if it shows in front of everything or represents an object meant to be hidden by surfaces. It should offer the best results.
-
1
-
-
38 minutes ago, cabalistic said:
You need to reset your darkmod.cfg, or specifically you need to enable in_grabMouse.
Thank you, it fully fixes that problem! I'd lose a lot of settings so I prefer keeping the old config, but every now and then options like this need to be reset. The new window and input manager seems to be working perfectly now: Need to play for longer and do more testing but so far this seems like another great success
I'd note only one little thing I just noticed: When alt-tab switching, the TDM window is properly minimized this time. But I noticed that if I leave the game running instead of pressing esc to go to the main menu, my GPU is still heating up, meaning the game is still rendering. If possible I'd disable the renderer while the window is minimized by the system.
-
1
-
-
29 minutes ago, cabalistic said:
Sort of... you can set r_frobIgnoreDepth to 0, however, this increases rendering cost, and it does not exactly look great in all instances.
Thanks. I had to revert to latest TDM release due to other issues, might try this again later once the latest dev snapshot starts working right on my OS. I'm tempted to cast a vote for disabling r_frobIgnoreDepth by default... if the performance cost is significant and it can end up looking worse, I must at least test it more before having a definitive opinion on that.
-
51 minutes ago, cabalistic said:
It's not that simple. There are different sources of aliasing. TAA, as the name implies, specifically targets *temporal* aliasing artefacts, which happen when objects or the camera move. Neither FXAA nor SMAA (in its purely post-processing form) do anything against those artefacts, but you won't see those in a still image. They become really apparent for e.g. small objects in the distance when you move the camera - you'll notice a very obvious edge shimmering, even if in a still image it might look fine. A good example would be Skyrim when looking at some trees in the distance - here the difference between FXAA and TAA becomes very obvious when moving the camera around.
In its basic form, SMAA is just another purely post-processing effect like FXAA, so the same restrictions and caveats apply. It might do a better job at detecting edges to blur than FXAA, but it doesn't magically have access to any more information than is already in the rendered image, so it's still just blurring edges. It is almost certainly cheaper than TAA and easier to implement, but it also does nothing against temporal aliasing, so it will not stabilize images in motion. SMAA can be combined with MSAA or TAA, though, although at that point it obviously becomes a lot more expensive...
Thanks for clarifying. Temporal AA might be unneeded then, I've never seen movement artifacts. I only use AA to get rid of jagged edges in both still and moving frames.
Considering all this then, I'd honestly be very happy if FXAA and / or SMAA could be implemented for the time being please. I know it's just a targeted blur filter which might seem useless from a developer's perspective, yet what it achieves makes it worth it: It gets the job done for most edges, is very fast at it, popular in many engines, easy to implement as it requires no special passes, and on top of that it also fixes sharp edges in alpha textures not just geometry which is a bonus the others don't offer.
It doesn't need to be on by default as far as I'm concerned. If you're uncertain about it, I'm fine with adding it as just a hidden cvar for now... if it helps I can test it before we decide if it should be in the menu at all; I'd even be happy with it as a hidden setting one can enable from the console. I'm hoping to maximize performance on my 144 Hz screen this way (run at >= 144 FPS) which would help a lot on top of all the new optimizations. Hope you can consider it till other options become easier to implement.
-
Finally gave the latest dev snapshot a try and decided to look at this. I honestly love what I'm seeing! Also I'm on board with the default white color... I'd decrease the intensity / alpha just a little, keep it color neutral otherwise.
I have only one problem with the effect: It shows in front of other objects and there's no occlusion. This can look weird... for instance light switches show through their socket and you can see the outline of the normally hidden bottom of the lever. Is it possible to make it render on top of the model being highlighted, but still occluded by other geometry?
-
1
-
-
I switched to the latest dev snapshot via the installer now that this should be included. Noticed a new issue straight off the bat: The system pointer shows over the game pointer in the main menu. The issue is even worse in-game, where the pointer not only shows and moves over the screen but you can no longer look around when it reaches a screen edge, apparently it's not auto-centered any more. Will have to revert to latest stable until this is resolved. If it's important I'm on Manjaro / KDE Plasma.
-
So far the consensus seems to be that SMAA and TAA would be the better options. They're both popular implementations and the screenshots I'm finding suggest they're pretty good. From what I'm seeing SMAA appears to look best, but this could mean it's also slower as some articles indicate, so TAA may be the ideal middle option.
Is the engine presently in a position to make at least SMAA easier to attempt implementing so far, or any of the other options available to us? Based on how our available render passes and shaders and other core components are set up to work, in hopes that major changes aren't necessary to support either of them.
-
3 hours ago, HMart said:
Is it also as fast? Also, regarding FXAA, on what Cabalistic mentioned earlier and in the initial chat: FXAA is supported by the video driver, however it's not an option you enable at runtime, I looked for a system parameter and couldn't find a way. The engine probably needs a flag to call OpenGL with this feature. If that's the case and I understood correctly, supporting it would be a matter of just implementing a menu option linked to a renderer initialization call. Don't know for certain if that's the case, just what I'm gathering so far.
-
I'm down with TAA or any option. I think the decision should be based on three criteria: How much it reduces aliasing and thus looks as good as MSAA, how much performance it gains us compared to it, and how easy it is for the developers to integrate into the engine so this improvement can hopefully catch the next release.
On FXAA I can only say I noticed a few FOSS games started using it recently, which means it's probably the most popular alternative. The latest version of 0ad has it as a menu option, Red Eclipse I already mentioned, and I recently noticed that even Xonotic (darkplaces engine) implemented it as a hidden setting which I now enabled.
-
Yes, FXAA isn't the only method: There are a few other alternatives to MSAA, which are all worth exploring and testing to see which gives the best results at the best performance with our engine. I believe most are shader based but use different passes to achieve the effect, which IMO is the right way of going about it.
I agree that in theory MSAA is the correct way of doing this. Its problem is that it requires multiple samples per pixel which is a great way of wasting GPU power. If we could have everything running in the most accurate way, our dream of a lighting system based on realtime raytracing would come true... on existing hardware that would run at 1 frame per minute. Point being that sometimes it's better to use estimations, especially when they can offer roughly the same result as the more realistic method.
MSAA should always remain an option... only wishing that other alternatives could be available for those who need the performance benefit. Ideally they can all be put under one slider or drop-down menu, so you have a list that looks like "FXAA, 2x TAA, 4x TAA, 2x MSAA, 4x MSAA, 8x MSAA, 16x MSAA" (prolly a silly example but you get the idea).
Something I forgot to add: I took inspiration for this suggestion from Red Eclipse, the latest version of which uses Tesseract engine (previously Cube). It has all sorts of AntiAliasing options available in the menu, from FXAA to Temporal AA to one I think they created just for that engine. I played with them and FXAA seemed to give the best results, whereas enabling all others at the same time still didn't affect performance as much as enabling MSAA alone.
-
Here are some useful resources on the matter, sharing in case they make this easier to accomplish.
https://catlikecoding.com/unity/tutorials/custom-srp/fxaa
https://catlikecoding.com/unity/tutorials/advanced-rendering/fxaa
http://blog.simonrodriguez.fr/articles/30-07-2016_implementing_fxaa.html
https://iryoku.com/smaa
https://www.geeks3d.com/20111101/smaa-enhanced-subpixel-morphological-antialiasing -
This is useful to know, thanks for sharing! I run most FOSS games from their repositories: TDM is among the only exception due to how it's packaged by its own installer. I might stick to the install manager for game data... the engine I'm already able to compile and use independently if its URL hasn't changed.
One curiosity tempts me to ask: Is there a reason why we're using the much older SVN instead of Git? While at that, do we have an official mirror on Github and / or Gitlab for the engine and its game code? It always felt like development could be even better if users on those popular platforms could clone through them and submit pull requests there.
-
1
-
Newbie DarkRadiant Questions
in TDM Editors Guild
Posted
Thanks @Dragofer for that info! Which brings up one thing I should correct then: I drew monsterclip brushes to encompass the model and not up to the ceiling, might be best to bring it all the way up then. Still curious which models will generally require it, and which meshes are safe for AI... for instance I don't seem to need to MC handrails or door / window frames.
The real issue I have though is with complex meshes the AI is meant to navigate... namely stairs, and namely the large mansion stairs model at that (models/darkmod/architecture/stairs/mansion_stairs_01b.lwo). I tried placing paths on it once but the AI got stuck under the stair instead, can't go up or down those. At the moment I monsterclipped the whole thing which solves that, but if an AI tries to chase the player across floors it would become obvious they cannot.
Onto another little question too: I was wondering how you can make a human AI wonder around randomly without any path nodes, to give a bit of detail to civilians and other decorative AI's who don't need a predefined path. I tried the "animal patrol mode" setting which is the only one I'm aware of, but it has a very wrong pattern: The AI randomly walks and runs into all sorts of directions... it doesn't look like they're idly walking around but more like they're having a psychosis attack. Is there an additional option or an equivalent to animal_patrol but without the running and more suited for idle human characters?