stgatilov

I wonder if we should just have one mega-var, which would disable all kind of camera deviations? Maybe even attach it to a checkbox in main menu gameplay settings...

I'm open about GUI engine improvements, as long as they don't break too much existing code. I don't think I want to spend much time on the actual GUI code, aside from fixing planned issues: 5852 5282

If I had such problem, I'd look for the object files of GLAD, where these functions are defined. If they are present, then run objdump to check that the missing symbols are indeed there or missing (they might have slightly different name for instance). If they are missing, then review the whole compilation log for appropriate .c files.

dev16574-10036 is now public. This includes tons of assets fixes, GUI warnings, and BVH-assisted optimizations. Quite a lot of breakage potential

When a light interacts with a surface, Doom 3 engine goes through all triangles of the surface in order to detect which ones are within light volume and front-facing. If the light constantly moves, then this processing has to done every frame. If stencil shadows are used, then engine has to look through triangles once again in order to build shadow volume. This implementation detail means that large static meshes with small dynamic lights nearby can be surprisingly slow. I think this issue happened several times recently: Black Mage: the lava cave Moving Day: rocks in the starting area The workaround was usually to split large mesh into several pieces. The latest dev build dev16574-10036 includes BVH-assisted filtering algorithm, which is enabled by default. It does the same job faster, without the need of touching clearly out-of-volume triangles. As far as I know, it totally solves the original problem, so you no longer need to be wary of how large your terrain mesh is. The new algorithm is enabled by two cvars, which can be changed at runtime: r_modelBvhLightTris r_modelBvhShadows Default values 3 and 1 mean precise filtering with BVH (default), zero values mean precise filtering using Doom 3 code. Note that the new algorithm reorders triangles in static meshes, so it has some influence even if you disable the above two cvars. The total kill switch which disables all BVH code is cvar r_modelBvhBuild, which must be set before starting mission. Here is a test map to show results (Bikerdude stripped for me from NHAT forest). All the terrain and stones are a single LWO mesh: 28 MB size, 127K vertices and 212 K triangles. P.S.: There is no performance difference on most existing missions. You can notice the difference only in critical cases.

The dev build dev16574-10036 includes many engine changes for better error reporting in GUI code. Not that GUI scripting has become any better, but at least now you'll see warning messages if you mess up (my favorite example is forgetting to put a semicolon where necessary or putting it where it must not be). This work is mostly done, although some more changes will probably follow. Notes: If a mission seems to have broken GUI (especially its briefing), please report. Some modifications actually changed behavior of obscure cases, so breakage could happen. If you see a GUI warning which you think does not represent a problem or is unclear, please report too. False warning are usually as bad as lack of true warnings. Also note that I did not introduce any hard errors, only warnings. So the situation when you edit GUI code and engine crashes on start will probably still happen. In this case I recommend enabling "logFile 2" and looking at qconsole.log: most likely some warnings are emitted before crash. UPDATE: There are more changes in dev16599-10071, this time potentially more mission-breaking. It is possible to use arithmetic expressions in GUI scripts and materials. Previously, same-priority operations in such expressions were evaluated in right-to-left order, so a - b - c was evaluated as a - (b - c) = a - b + c. This is fixed in the new version. Also, logical AND is given greater priority than logical OR. Of course, these changes can break stuff I also fixed indexing vector values for individual components, which was totally broken. Another weird mechanics was that if you reference a window register anywhere, then its auto-updates were disabled on startup (really hard to find good example for this). Now auto-updates are disabled only after you assign to this register using Set script command. Lastly, it is now possible to write expressions on the right side of Set script command: make sure enclose the right side in parentheses to use expressions mode. Here are some examples of this new syntax (combined with vector component indexing): set visible (1 - "OtherWindow::visible"); set backcolor (backcolor[0], backcolor[1], backcolor[2], 1 - backcolor[3]); This allows to implement some basic logic purely in GUI. For instance, scrolling in the new objectives GUI code is implemented without C++ interoperability, with button working like this: onAction { set "gui::ObjStartIdx" ("gui::ObjStartIdx" + 1); Yep, it's year 2022 and our GUI engine has just learned how to increment a variable! But keep in mind that all expressions are evaluated before script gets executed, so if you copy/paste this incrementing line several times, the behavior will not change (same for "if" conditions).

If you want that particular video, then downloading the mission and looking inside its pk4 is the only way to do it, I think.

Maybe you don't have C compiler? These files are built along with the rest of our code.

I disabled the feature in svn rev 10033, although it can be enabled back with r_testPostprocessMultiple. The problem is that any window with two-sided warping material previously worked fine, but now will flicker (like test/glass). Also, it seems that the original problem is not going to be solved anyway due to depth sorting problem... better have a feature with clear limitation (one layer copy) than have a randomly broken feature...

I don't think this log will explain anything. If you experienced a crash during gameplay, you can explain where and how it happened, is it repeatable, post a savegame, share a crashdump. Speaking of crashdump, you can run TDM under gdb and execute generate-core-file gdb command after it crashes.

Actually, that's the main reason why all software gets slower over time.

By the way, revisions 9966 + 9967 broke test/glass map pretty bad. It has a glass wall near starting location, which consists of 8 glass windows of different material. Previously, it looked nice from all directions. But now when you look them from behind, they toggle on and off as you walk around.

Yes, that's exactly what I'm talking about regarding BSP tree. World brush geometry can be put into its own BSP tree by dmap, which can be rendered in perfect back-to-front order. UPDATE: But, even static geometry will cause problem with postprocessing surfaces. Because you have to copy renderbuffer befor every postprocessing surface rendered in order to get proper picture, and that's very expensive. With depth peeling, you need to copy renderbuffer after every layer, if there is a chance that next layer will include postprocessing shader.

If you suggest something like depth buffer, then you'll eventually get at the technique called "depth peeling". It works by rendering all translucent surfaces over and over again, rendering exactly one layer of translucent surfaces one every phase, until all layers are rendered and nothing changes. This is quite expensive, although the true cost depends on maximum degree of overlapping. If you suggest something like sorting surfaces from back to front on CPU, then you get a well-known unsolvable problem. The worst thing here is that when surfaces' boxes intersect, their order toggles back and forth as you run around them. In order to perfectly solve depth sorting in general case, you have to split surfaces. For static geometry, BSP tree is the best way to do it: that's how e.g. Doom worked without depth buffer. But adding dynamic surfaces into BSP tree is still an issue.

If they have same material and "sort" value, then they are eventually sorted by surface index. This order is constant in one playthrough, but can change even if you restart the game. And if you have two postprocessing surfaces on the same place, then both of them will be visible if they render in correct order. If the closest surface renders first, then the farthest surface won't be visible.

dev16519-9985 is now public.

I removed DSF_SORT_DEPTH flag and new sorting code. I committed test map to assets SVN as test/5990_render.map. I did a few adjustments to the map, most importantly set "drawSortOffset" "1" on the window: now it renders properly always. However, this assumes that player cannot get into water: it player is inside water, then he won't see glass windows behind water obviously. Speaking of "drawSortOffset", I think it has some issues right now: 1) I have a pool of water, and I know player cannot get into this pool since the level is too low. I'd like to make sure this piece of water renders before all the surfaces with similar material. I set "drawSortOffset" "-1" on the water, and its rendering is totally broken because it is no longer considered "postprocessing", thus framebuffer is not saved. Setting "drawSortOffset" on the window is possible but hardly a good idea: I don't have any guarantees about window, so I should not have to tweak it. 2) drawSortOffset is an integer, so it is not very applicable to ordinary translucents. In fact, the original D3 way of tweaking translucents is by classifying them into "close", "medium", "far", but that's only possible in material. softOffset works well only for afterFog, postProcess, last classes, since their "sort" values are far from each other. But: mapper must know that he cannot set large values, or he'll break everything. Wouldn't it be better if we: Sort by "sort" class first, then by mapper's "drawSortOffset", lastly by surface index. In other words, let softOffset be tie-breaker, instead of a way to break classes in implementation-defined way. Allow mappers to override "sort" class of entity by spawnarg. So if mapper decides that some object is not really "close" but should be "medium", he sets "drawSort" "medium" spawnarg on entity and this is used instead of the value from material. I'm not even sure it p.2 is necessary. Ideally, these close/medium/far classes either should not exist, or should be totally certain so that mappers don't need to override then on per-entity basis.

v141_xp is VS2017 with Windows XP support. You need to run Visual Studio installer and find "Windows XP support" there somewhere, enable it and allow installer to download more stuff to your computer. Then it should build fine. Alternatively, you can change v141_xp to simple v141. If "retarget solution" does not help, then you can close Visual Studio, then find all .vcxproj files (at least two are important), open them in text editor, then search and replace "v141_xp" with "v141" everywhere. Or you can go through all projects manually in Visual Studio, look at their properties, and in General section change Platform Toolset to "Visual Studio 2017 (v141)". Be sure to switch to All Configurations and All Platforms before doing so.

Well, mapper can at least establish relative order between translucent entities of same-kind material. But I think it is not possible to do this in script right now. Yes, it is not perfect, but it should work. It would allow "user-assisted translucency" for those who dare. I don't think there is anything like that. Moreover, SEED is hardly a good piece of code to look for admiration...

@duzenko, how can mappers control render order now, including dynamically from script? Can they set "sort" parameter directly as spawnarg? Can they set something like "renderOrderOffset", which only affects order of surfaces with same "sort" value? Can it be done in script during runtime?

On VirusTotal only one piece of software reports something, and that's not Avira: https://www.virustotal.com/gui/file/3eb8c46eeeb508454457bf392a16bb5ff83e244bfa5cb333cb93a02d3e14e0c3

Then let's remove this sort by some matrix element, and think how to allow mappers tweak order dynamically in such a way that we won't break it in future.

BTW, there is another solution straight from the days of the first Doom: we can use BSP to establish rendering order. But: Our BSP is too large to traverse in realtime, so we should build a separate BSP only for translucent geometry. If some surface is split into chunks by BSP planes, we must not merge it back: we must retain each chunk as separate surface and order + render each chunk separately. Obviously, this only works for world brushes: no entities, no patches, no models. It is not obvious how to merge unsupported translucent geometry into BSP order... maybe by some origin point. This requires quite serious effort on dmap + rendered frontend + integration with backend.

I think the best solution would be to save the current way of rendering objects, but allow mappers to specify tie-breakers in scripts. Don't try to make clever automatic solution, it won't work and won't be easily configurable. If mapper really wants to get complicated translucency work, he can often get away with some simple conditions like: if in area Q, then render A then B, otherwise render B then A if coord X < 1540, then render A then B, otherwise render B then A But for this to make sense, we need to guarantee that we won't try to tweak anything above this tie-breaker ourselves. We won't change "sort" variable in core materials, won't split its values into more classes, etc. All that tweaking that you did in the core game must be stopped, because if you continue, you'll break mapper's translucency tweaks.

After some more consideration, it won't work, even in limited case. Actually, nothing will help. You'll just replace one problem with another, no matter what you do. Translucency is common problem which remains unsolved. If you have ordinary translucent objects with common material, then you can at least do some OIT (like per-pixel lists, depth peeling, or weighted approximation), but if you need to copy background, nothing of it works. Just remember that you should not have more than one heatHaze material per view, and that if you have many translucent objects, they'll probably render in wrong order.