cabalistic
-
Posts
1579 -
Joined
-
Last visited
-
Days Won
47
Posts posted by cabalistic
-
-
46 minutes ago, stgatilov said:
How can you explain that the problematic spots stick forever?
No clue, but to be honest, since neither of us can reproduce the issue, we'll just have to have both hypotheses tested. I imagine having a shader fix tested is slightly easier, so I would start with that, but if it's not that, then do try yours
-
6 hours ago, stgatilov said:
Our bloom implementation does not disable blending. In only sets blending function to (dst * 1 + src * 0).
It looks like src * 0 is always zero and this equation is equivalent to disabled blending. Except that in 64-bit mode we have floating point values in framebuffers, and floating points numbers have special values like inf-s and nan-s, which don't become zero if you multiply them by zero.It's possible, but it sounds unlikely to me. I would expect any sensible driver to not actually sample the existing framebuffer if its blendweight is zero. Could be wrong, of course, wouldn't be the first time
My personal hypothesis is that we may have negative values in the input color framebuffer. This has actually happened in another place where I already put a workaround for the resulting issues in place, so this isn't too far-fetched, even though I don't fully understand the cause. Now, if there is a negative value in the input to bloom, it would probably get smeared across the bloom stages and then added to the final image, which, if the negative value is high enough, would explain why it ends up as black.
This is potentially simpler to test and workaround; all we'd need is a check in the bloom_downsample.frag.glsl brightpass function that returns 0 if the brightness is negative.
-
3 hours ago, nbohr1more said:
No value that I adjust in frob_flat.frag.glsl causes any change.
Wrong shader, look at stages/frob/frob_apply.frag.glsl. Though honestly, returning to fresnel feels like we are moving in circles... If that had worked well and not be ugly as fuck, we wouldn't be where we are right now
-
1
-
-
Well, obviously. The outline was always meant as an alternative, not an addition, to the existing highlight.
-
8 minutes ago, wesp5 said:
So you are saying that even with the outline, we will have some objects highlighted completely while others show nothing but the outline? How can this be considered a fix for the problem?
Because the outline *is* the highlight in that case? I don't know what you are saying here.
-
7 minutes ago, wesp5 said:
I don't see the problem. Frob Outline to me is kind of a Frob Easy Mode and TDM supplies easy modes for AI and lockpicking already! In my patch I replaced the Frob Helper with this menu, which was a Frob Easy Mode as well.
An outline for frob highlight works independently of the object and its material. Without a frob outline, we are back to the status quo where highlighting an object is dependent on its material to work properly. If frob outline is deemed an optional feature, mappers need to design for it to not be present so that their objects highlight properly without the outline. Which kind of defeats the reason why the feature was implemented in the first place.
On the other hand, if they wanted to keep some objects "hidden" as a secret, the outline makes that harder. So again, it's kind of difficult to design missions around both options, hence not both should be offered as approved options to players.
-
2 hours ago, kingsal said:
Also I agree with this, I know its a pain to support all of them but it would be awesome if players can choose.
Would it, though? Mappers need to know what to design for. I don't mind advanced players playing with cvars to do whatever, but any UI option means we "officially" endorse that particular mode. And then maps should work in any of those modes, which, judging from prior mapper comments, isn't as trivial as it might sound. Especially the choice between "on" and "off" is quite impactful here.
Which is why I must again strongly object to any UI choices on the feature. Either implement it or scrap it. No half measures, please.
-
1
-
-
Sounds like you may have a malfunctioning gamepad/joystick connected? That would explain the cursor movement. Try disconnecting any non-essential input devices.
-
1
-
1
-
-
Thanks, but just so you know, development is temporarily on hold because I'm busy with other projects. Hopefully I'll be able to get back to it some time next year
-
4
-
-
There's no support for keybinds with modifiers, and it would be rather painful to implement.
-
1
-
-
4 minutes ago, kano said:
But still, since TDM is all open source, path tracing is probably closer than you think. As in, at least it is possible that we will see it one day.
No, I can assure you it is quite far away. OpenGL has no support for ray tracing, so you'd first need to write a Vulkan renderer for it. And that is most certainly a very daunting undertaking.
I mean, one day we'll migrate to Vulkan, sure, but that's not close in any meaningful sense of the word, I'd say
-
1 hour ago, Alberto Salvia Novella said:
Are you sure there isn't a standard way to check which color formats are supported?
Yes, because we request and require OpenGL 3.3 and don't run on anything prior. And 3.3 requires 64 bit color buffer support, so there's no separate way to query the support. This is - plain and simply - a driver bug.
-
The 64bit color buffer visibly reduces banding in fog and other particle effects and is also a requirement for the Bloom effect to work properly. No HDR screen is required to benefit from either of those.
-
1
-
-
Yes, but the default framebuffer is never directly copied to from the multisampled render FBO. There is always a resolve FBO in-between.
-
8 minutes ago, stgatilov said:
I wonder if something like this could happen in our case.
That would surprise my. The resolve framebuffer is always created with the same resolution and format as the multisampled one. If there were an error in the code here, this would be an error that would most certainly also happen on our own machines, because I've seen these kinds of errors when I messed something up
-
Well, that'd be that, then. Unfortunately, fixing the menu elements to use an index buffer isn't an entirely trivial fix, or I'd have done it sooner, but I guess we'll have to put it on the agenda somewhere
-
18 minutes ago, stgatilov said:
We never found what was the reason behind this issue.
It broke after we started asking for GL 3.3 instead of GL 3.1, and it does not break in compatibility mode.I wonder if it's related to index buffers. Menu elements are (afaik) the last elements that are drawn from a CPU-provided index list instead of a GPU index buffer. Far as I know, the spec doesn't require one, or at least I couldn't find anything to the contrary, but it's possible some drivers expect them, anyway?
-
2
-
-
No, the updater is outdated and afaik does not download the hotfix (?). Please use the new tdm installer, download it if necessary: https://www.thedarkmod.com/downloads/
-
Please run the tdm installer again and upgrade to the 2.09a hotfix release. It fixes the particular error you've encountered. Can't guarantee that it won't run into a different error, but we won't know until you try
-
58 minutes ago, HMart said:
Strange that I have that off?!
It's an experimental setting, it's not in the menu and not enabled by default. Shadow maps are still a work in progress.
-
1
-
-
If you want shadow maps to have comparable performance, you need to set "r_shadowMapSinglePass 1". In its default mode, it's well known to be slower than stencil.
-
11 minutes ago, wesp5 said:
Okay, so the frob outline has been completely disabled in the latest version. I thought the idea was to add an option for it instead of the frob helper? Is this coming in another version or has it been discarded altogether?
As long as the feature is broken, it will not become an option or officially supported in any way, hence why it is disabled now. The only reason it's even still in the code is the vague hope it might be fixed at some point in the future.
-
1
-
-
The cost scales with the complexity of the highlighted object. A simple gold coin isn't really a concern, but a guard or other complex geometry may be a different matter. So be sure you test the right thing.
Also, the hack means that while the outline is generally hidden by depth, it is not a perfect match. It will often slightly protrude into the depth-occluded region, which is not a critical concern, but it does look a little ugly to my eye.
-
1
-
-
1 minute ago, wesp5 said:
Nobody ever asked for this feature to be removed completely. Some people like it, others don't. So we should do what was already suggested, replace the "frob helper" option which probably nobody ever uses with a "frob outline" option which is default off and everybody should be happy with nothing have been wasted!
If it were just personal visual preferences, sure. But if it being on actually impedes mappers due to stuff being visible that shouldn't be, then making it optional does not in any way solve that problem. Therefore I consider the feature broken.
-
3
-
TDM not seeing 3070?
in TDM Tech Support
Posted
Please try the 2.10 beta. It has a different window and renderer creation path and might give better results.