stgatilov

@Daft Mugi, please test the latest source code SVN. I fixed color banding issue and bumped default number of samples. Of course, shadow maps are still as bad as they where, and you won't get less work for you GPU, but I hope most of artifacts in volumetrics themselves are gone now. By the way, you can further reduce GPU load by setting "r_volumetricLowres 2", which would mean rendering volumetrics and quarter-resolution. You might get more blurry or messy look, but it should be noticeably cheaper.

The story about volumetric lights and stencil shadows is rather messy. Initially, we did not force lights with volumetrics from stencil to shadows. As the result, with stencil shadows volumetrics simply passed through all obstacles. And several mappers were disappointed by that, saying that volumetrics leaking through stuff has bad consequences for gameplay. Then we changed the behavior: if player uses stencil shadows, then volumetrics are simply disabled. But since it many cases (especially where old-school transparent geometry was used) shadows are not necessary, we added a way for a mapper to mark volumetric light as "using shadows in volumetrics not required". As the result, mapper could make some volumetrics work even with stencil shadows. Of course, this markup is not very popular, but the particular light that you found most likely has it. Then after 2.10 we implemented a force-switch from stencil shadows to shadow maps for the lights with volumetrics. At this moment, the markup is probably not necessary. The cvar "r_volumetricEnable 0" simply removes all kind of volumetrics without second thought. So in this case volumetric light was used, but it worked with stencil shadows because mapper allowed it drop shadows completely.

Why do you think so? Apple deprecated OpenGL but never removed it. I think they still support 4.1, which is enough for TDM currently. Actually, I'd second the question: can you run TDM on Wine or one of its variants? I think we are speaking about running x86 Wine + x64 TDM with Rosetta translation.

I added a cvar r_volumetricEnable. Note that you should run reloadModels after changing this cvar, just like you need when you change r_shadows. It seems that you don't like shadow maps in general These are the typical pixelization artefacts which I also hate in shadow maps. When there are too many shadow-mapping lights being rendered, some lights are automatically switched to lower resolution, which makes the issue even worse. And one way to somewhat mask this problem is to use soft shadow maps... which are very expensive in TDM right now. Ideally, we should render shadow map with low resolution, then render stencil shadows as usual and use them for shadowing, but use shadow maps for volumetrics. But I'm not sure having both implementations of shadows fits the renderer architecture, unfortunately. This is not noticeable in a still screenshot, but I found this location and I see the problem. I have found a similar case at 3986.7 2463.3 -222.85. I guess I should look into it. It looks like color banding, because volumetrics are computed in 8-bit FBO. I knew about this problem, but it did not look so bad on testmap, and I thought maybe I could ignore it. But in Hazard Pay, there are many places where color banding is strong. I can "simply bump" FBO to 16 bits, doubling memory bandwidth, or adding dithering... I wonder if there is another option. When I flew around this map, the brightness of security cameras looked over-the-top for me too. But now that I look at the map, it seems that volumetric_dust is set to default here. @Dragofer, maybe we should tone down security cameras by default?... Of course, this issue is greatly magnified by gamma-incorrect rendering pipeline, so when several light sources overlap, their brightness gets much larger than just their sum. Not fixable right now I can't understand how a game can be blamed for increased power consumption. Loud noise... probably means that this particular piece of hardware has bad fans. But I agree that this is a sign of greater performance cost in general, which can lower FPS for you in other cases, or for other people. I guess you need to do reloadModels, since this cvar changed shadows model of some lights. It looks like your GPU increases power consumption when you increase memory bandwidth. Computations don't matter that much. It's no wonder you see no performance drop: you have 60 FPS cap. Given that now volumetrics are rendered at half-resolution, number of samples per pixel does not affect performance so badly. Maybe I should just bump them to e.g. 24, I don't know.

I think none of them are correct in 2.11 and all will produce a warning. To be honest, it's better to test if you want to know that level of detail. For the sake of tutorial, the only way that should be advertised is: float <user_variable> 0 <property> 0 This is what Doom 3 expected, and it works reliably both in Doom 3 and all versions of TDM without warning. All the other syntax is playing with fire, and people should not know about it

Yes, with new changes you can hold Creep button, and you'll surely get not sound from moving/rotating an item. And I recall I added a cvar to configure whether this happens always, on walk, on creep, or never.

Yeah, my reaction is directed not towards you, but towards the original author of Doom 3 GUI engine. I won't mind. Perhaps the third thing, along with calling named event and runScript command. https://bugs.thedarkmod.com/view.php?id=6164

Good story, but it does not explain why they copy/pasted the whole section of C++ code instead of adding second string comparison with OR operator in the condition for the existing section.

Does any version of TDM run properly for you? Like 2.08 for instance?

Radeon 3000 is TeraScale 1 architecture. While it technically supports the required OpenGL version 3.3, nobody has made it run recent TDM thus far. I think @duzenko even got such a card and tried to understand what's going on, but to no avail. The only option is to use older version of TDM (and thus better run older FMs too).

Yes, now volumetric lights with shadows by default force shadow maps, but for the lights with volumetrics only. If you find it surprising, you should recall that some lights (parallel and large ones) are always forced to stencil shadows, even if you choose shadow maps in the menu. It has been working like that since the very beginning of shadow maps in 2.06.

@lowenz, could you explain when the issue started happening?

I extracted @lowenz story about performance into separate thread. I think we also have @Araneidae and @MirceaKitsune with issues around stencil shadows and probably screenshots. @Araneidae, do you still have the problem on the latest build?

I still don't understand where is the problem. What else you can try: r_softShadowsMipmaps 0: the new optimization for soft stencil shadows uses more memory, and in some cases might even be slower. r_volumetricForceShadowMaps 0: this flag is for the change where lights with volumetrics are switched to shadow maps even if you have stencil shadows selected. r_shadowMapSize 512: this means using 2x lower resolution for shadow maps. Shadow maps take quite a lot of memory (144 MB at defaults) and fillrate, so lowering it down might help.

Yeah, there are indeed some. It's nowhere possible to make it pixel-perfect and cheap today. The new volumetric shadows are expected to be faster than ones in 2.10. If you have severe performance degradation (e.g. measured with uncapped FPS and max FPS set to 500), we'd better find out at least approximately where it starts and what causes it. I bet some maps like Hazard Pay will look very wrong if you just disable the volumetrics. You can go to 2.10 state with: "r_volumetricLowres 0" and "r_volumetricBlur 0". Did you try setting "r_volumetricSamples 0" ? That should disable expensive sampling: without it the effect would be very cheap.

The volumetrics code is vastly expanded in the latest dev build. They are blurred, and rendered on half resolution. As the result, the annoying pattern is not visible anymore, and the effect is cheaper in terms of GPU work. Enjoy

Well... the temporaries are called "registers" in the code. But since mappers don't see temporaries anyway, I don't think you have to worry. This is just some minor difference in terminology.

Ok, the bug is fixed in the new dev build. Also, we have removed old-style frobstages from core materials.

dev16650-10157 is available. P.S. Clipmodel bug is fixed in it too.

No idea. There is some difference between window properties, but I don't think I fully understand the whole picture. I think there are three types: "nocursor", "font", "forceaspectwidth", etc. --- these are not properties at all. They are like flags: they are applied immediately at the moment of reading, and their parameters must be literal constants, no links/referenced from them and to them are allowed, so no auto-update, no possibility of changing them with Set, Transition. Some specific window types have specific flags, e.g. "stepsize"/"step" in SliderWindow. "backcolor", "rect", "notime", "visible", etc. --- these are builtin properties. They are hardcoded in Window code, and may probably have different behavior. Some specific types of windows have specific flags, like e.g. "cvar" in SliderWindow. Custom window properties, defined with "definefloat", "definevec4", "float". In my understanding, 2 and 3 work the same way and can be assigned expressions or constants. Maybe there is some difference which breaks initialization of one of these, I did not hit any myself. So I don't know. In the original engine, every property must be assigned some value/expression. Writing something like "float myvar;" was illegal by how the code was implemented, because it tried to read a value from semicolon. And since it could not find a variable/property with name ";", it introduced a new variable with such name and zero value, and you got zero initialization. Maybe I am wrong in some detail, but this zero-initialization feature was a lucky side effect from parsing unknown tokens. I legalized this practice: now you can add semicolon instead of value, and parser will just replace it with zero value. Otherwise you'd get a lot of warnings about it now. I don't understand why two keywords "float" and "definefloat" exist. In the code, there are two identical pieces of code for handling them. I found a commit where I changed one for the other, but it seems I did so merely because "float" was used in at least one more case, while "definefloat" was not used anywhere else. Revision: 16558 #5869. Use "float" keyword instead of "definefloat" for compass noshadows register. Note: I have no idea what's the difference. Looking at C++ code, both cases are the same... Yes, it should look like this, but semicolon here is illegal. Script command must end with semicolon, property definition must not end with semicolon. Except for the zero-initialization case noted above (which I'd be happy to not introduce, but too much existing code). Sorry, I did not notice the left side of Set. No, it is not possible to Set only one component of a vector variable.

I noticed it but thought that's because of 400 FPS I have on a tiny map. I guess I broke collision model code during refactoring.

If you look at page about C/C++, you'll see that comparison operators == and != have slightly higher priority than <= >= < >. In GUI code, all these 6 comparison operators have same priority. So if you write a lot of such operators one after the other without parentheses, GUI code will evaluate them left-to-right, while C/C++ will first evaluate == and !=. This is a minor deviation from C standard. I don't think this is ever important, since writing many comparisons in a row is a bit absurd by itself. This was never a correct form. It's just that previously GUI engine did not report any kind of issues to you. Also, that form was never common, I have seen it in exactly one place in our main menu GUI. It works in any expressions. So it covers a, c, d, e, g. But speaking of Set command, it will only work if you enclose right side in parentheses and thus switch it to expression mode. Without parentheses, right side does not support expressions. Transitions don't support expressions, and I don't see anything like indexation support in the code. Yes, it means top-level windows, you can nest as many as you want. When engine loads UI, it takes a single .gui file and parses it. There can be #includes inside, which would make preprocessor copy/paste other files too, but for the GUI parser itself it is single file. This file must contain exactly one GUI window and nothing more (it is usually called Desktop). Inside the top-level window, you can do whatever you did previously, it's just a limitation on what happens outside it.

I can't reproduce it on Bakery Job. At which moment exactly should I press quickload?

I think this is caused by SMP. When the game modes K-th frame, it displays (K-1)-th frame. This works great in steady gameplay, but when something radical happens (e.g. game load), first frame can be displayed with some stale data. Note that if com_smp is 0, then the game still renders previous frame. It would be great to change it back, but we faced some problems with it and it works as it works. So yes, there should be some code to mute such things, but I guess we have not tackled this problem yet.

I refer to Doom 3 in general, at least the original game engine from 2003. All comparisons are operations which are part of expressions. In order to evaluate expression, you need to store temporaries somewhere, and combine them with each other through a sequence of operations. In case of GUI scripts, the temporaries are called "registers". These registers are floats, they simply cannot hold a string. Actually, I have just found the commit where I removed the comparison, and here is what it says: Revision: 16537 #5869. Removed incorrect comparisons with empty string ( == ""). The scripting language does NOT have string values, it only has float values. So when you reference some string variable in expression, it gets value 0.0 if string is empty and 1.0 otherwise. For this reason, there is no sense in comparing to "" (which is actually replaced with 0 because no variable with empty name is found). So the "!=" operator is just a weird way of writing != operator, doublequotes don't change anything. And a string value inside expression is immediately converted into float with 0 or 1 depending on whether it is empty or not. There is no string comparison, but there is checking for emptyness. Multiline macros work as they did, in fact the change is about fixing them! There are several different but related things, and they get into a confusing mix here: Token concatenation used for multiline macros, which comes directly from C/C++ language. String literal concatenation with backslash is optional feature of idLexer --- it does not exist in C/C++ language. String literal concatenation by writing them one after the other --- standard feature of C/C++, disabled in D3 GUI. Here is the full commit message: Revision: 10031 #5869. Don't enable string concatenation by backslash (\) in GUI code. GUI code uses doublequotes everywhere to make names like gui::my_var atomic, since otherwise parser would break them into many tokens. For this reason, string concatenation is disabled in lexer (that's when you can write "hello" " " "world", and C will treat it as single string "hello world"). However, ID enabled special string concatenation via backslash to substitute for it, like this: "hello" \ " " \ "world" The problem with such usage is that it breaks multiline macros. Due to limitations of GUI code, we have to write whole window (even with subwindows) into a macro in order to make it reusable. If any line in such macro ends with a string literal (that's very likely in GUI code), then parsing breaks and whole macro does not work. This can be worked around by moving the first token on the next line to the end of the current line, but it is very messy and totally not obvious. Better just forbid string concatenation altogether. Buy the way, the following way of concatentating string works (at least inside macro): "hello" ## " " ## "world" Note that ## is a standard C way of concatenating tokens, although in C it works on TOKENS, not on string literals --- but here they are mixed anyway. Also, it is even possible to do this: #define HELLO_MESSAGE(index) "Hello, " ## #idx ## "-th user!" Which is very useful to construct variable names inside macros =) The work is finished, although it might get some changes if any related bugs are reported e.g. during beta. I don't think we can give access to single thread. If you miss some info, just ask me and I can copy/paste or explain in my own words. The two references you gave here are about: expression evaluation order fix, expressions in Set command, change in register disabling behavior. They are described in this public post too: