glitches on the ground

[legluondunet]

Hello,
I just compiled today's git croftengine on Linux.
Three things:

• 1°) I use my old french PC CD version but crosoftengine does not seem to be compatible
• 2°) when I launch croftengine , I obtain this error message:
  failed to load translations for QLocale(French, Latin, France) / "fr_FR"
  Where could I find this translations files?
• If I use files from my Tomb Raider 1 Steam english version, croftengine launches but I have a lot of glitches on the ground:
  
  
  This glitches follow Lara when she runs.

I tried to report this issue on youtrack but it seems I haven't permission to do that.
Thank you for your help.

[stohrendorf]

1. What do you mean by "does not seem to be compatible"? Explain what you did, and what happenened.
2. That is just an information that there are no translations available for your locale, it will automatically fall back to English. As of right now, there is no French translation of the engine.
3. That's got nothing to do with the level data. What OS are you on, what graphics card do you use, what version of CE are you using?

[legluondunet]

"What OS are you on, what graphics card do you use, what version of CE are you using?"

I compiled CE from git yesterday.

My config:
OS: Manjaro 22.0.2 Sikaris
Kernel: x86_64 Linux 6.1.9-1-MANJARO
CPU: AMD Ryzen 9 5900HX with Radeon Graphics @ 16x 3.3GHz
GPU: AMD Radeon RX 6600M (navi23, LLVM 15.0.7, DRM 3.49, 6.1.9-1-MANJARO)
Video drivers: Mesa 22.3.5

I own Steam (english) and GOG (english) and even CD (french) version of Tomb Raider 1.

[legluondunet]

"What do you mean by "does not seem to be compatible"? Explain what you did, and what happenened."
If you agree, we will see later or in another report this point and I invite us to focus on the problem of glitches on the ground? The TR1 version I used come from steam. As the CE import feature did not work, I imported manually files, copied/paste folders fmv, data and music. I have attached the result of the tree view with details of the file sizes in bytes.
ce_tr1_tree.txt

[stohrendorf]

Ah, you probably found a commit that broke the graphics, but it's fixed now, although it now has a performance regression. Additionally, 2.0 has a bug that prevents importing the CD images. For importing checkout tag 1.9, then checkout tag 2.0 to play, and everything should be fine.

[stohrendorf]

I'm sorry, I messed up with the versions. You may checkout the latest master, it contains the fixes, but support for non-releases is limited.

[legluondunet]

I will give it a try when I will return at home.

[legluondunet]

Just tried today's git code:

• compilation OK
• launch OK
• import Steam data OK
• audio soundtrack download and playing OK
• glitches ground still present

More than words, this is a video:
https://youtu.be/nG7QYyb8IuE

[stohrendorf]

Oh, that's clearly broken shadow mapping, haven't seen that for quite a while, so I didn't recognize it immediately. As it's probably a race condition with texture access, I'm not sure I can reproduce it on my system.

[stohrendorf]

I finally got my system (partially) running again, and I can't reproduce it, neither in debug mode, nor in release mode. Please note that I was only able to test the amdgpu driver, so it might be because of different drivers. What are your drivers and versions? What is your Mesa version?

[legluondunet]

GPU: AMD Radeon RX 6600M (navi23, LLVM 15.0.7, DRM 3.49, 6.1.9-1-MANJARO)
Video drivers: Mesa 22.3.5
Do you need others info?

I launch CroftEngine directly from compile folder.
My compilation process:

git clone https://github.com/stohrendorf/CroftEngine.git
cd CroftEngine
git submodule update --init --recursive
mkdir build
cd build/
cmake -DCMAKE_BUILD_TYPE=Release ..
make
cd src
./croftengine

[stohrendorf]

Can you take a look at the log files and confirm that the "opengl ..." log lines report that it's actually using that graphics card? I have the suspicion that it's running on some integrated intel GPU, which would explain the problems.

[legluondunet]

I join you my latest log:
croftengine.1.log
Croftengine seems to use my main GPU card.

[stohrendorf]

From what I could find on the internet, the RX 6600 series seems to have a lot of issues and bugs. Many users complain their system won't even boot, others have the problem that the GPU isn't identified correctly, some have crashes, etc., although a few times it was mentioned that updating everything to the newest releases seems to have fixed stuff. I think you got bad luck with your GPU.

[legluondunet]

My GPU card is today well supported now on Linux, since 6.x kernel version.
With kernel version < 6, that was not the case.
I own more that 100 3D games on Steam and all work very well with my GPU, my computer is very stable.
Latest games I played are "Assasin Creed Origins", "StarWars Fallen Order", two games that need strong GPU performance.
The issue should not be there...
Is it possible to activate a more debug mode for Croftengine?

[stohrendorf]

You can try to re-build using -DCMAKE_BUILD_TYPE=Debug, that enables a lot of thorough checks of the graphics calls, but performance may suffer a bit.

[legluondunet]

I just compiled a debug release with today's git.
Issue is still present.
I joined you log file.
croftengine.0.log

[stohrendorf]

Unfortunately, that log file doesn't help. In debug mode, if there's any issue with the graphics pipeline, the engine just crashes, and this means that (in general) the pipeline is working fine for you. Additionally to that, you're the only one who reported this issue, and I'm unable to reproduce it. I looked into the code and couldn't see any issue (but that doesn't mean there is no error). As CE uses some advanced OpenGL features, it might be that it either has a rare bug (which I consider unlikely given on how many systems this runs fine on), or that you discovered a rare bug in the graphics driver. In any way, as of right now, I don't have a solution for your problem, I'm sorry.

[legluondunet]

ok, I let this report open, in case another user have the same issue as me on Linux or Windows. We'll see in several month if I can still reproduce it.
Thank you for your help.

[stohrendorf]

FYI, the recent nvidia and AMD driver updates on my Windows system point towards the engine having some issues with resource handling regarding textures. As the shadowing is (basically) just a texture, this means that it's probably a fundamental engine issue. I'm currently investigating, but as of right now, I only have very vague suspicions what's going wrong. I hope the solution to the issues the engine has resolves your issues, but as of right now, I'm mostly clueless.

[legluondunet]

I just compiled today's git and issue is still present.

[stohrendorf]

Oh sorry, there's no fix yet, there's only hope for a fix now, just wanted to let you know about that.

[stohrendorf]

Can you try the latest master, please? There were some major changes to the render pipeline that might resolve your issues.

[legluondunet]

I just compiled today's git and I have bad news, two things:

• main menu has strange colors:

• Crosoftengine crashed when I launch a new game, log joined.
  croftengine.2.log

[legluondunet]

I joined another log, this time crash appeared when I selected "Details levels"

croftengine.4.log

[stohrendorf]

Thanks, I'm pretty sure I have fixed the crashes. But I'm not sure what you mean with "strange colors", the only thing I can currently imagine is that the texture interpolation is different. Can you please try the latest master again and tell me whether it crashes and possibly fixes your issues?

[legluondunet]

my english is limited but "the texture interpolation is different" is exactly what I meaned.
New compilation in progress...

[legluondunet]

Crosoftengine still crash when I try to access "Details levels"

croftengine.5.log

[stohrendorf]

Okay, here's the first set of tests to try and narrow the issue down. You only need to git fetch and then git checkout the mentioned commits, and then make. Please use the attached quicksave to have comparable results, so I can compare it with the results on my machine.

quicksave.zip

• 6c90e569f12832eaaa6045bac26317d1d922963b - this is a general test for texture access issues, shadows should radically change if that's an issue
• a0bf5d2b16b569f35a80a7b45cbbd8e89905a520 - an internal check for shader issues, may radically change the output, too
• ea1042fe7f13bdfe3af51383e1f5fdf5d6a3dce8 - some shader debugging, please take a screenshot
• 409265ed6d8c954ba593e3e6e7d7f389390da120 - some more shader debugging, please take a screenshot

Big thanks!

[legluondunet]

1° ) 6c90e56
no change, same issue still present

croftengine.0.log

[legluondunet]

2°) a0bf5d2
crash before showing main menu
croftengine.1.log

[legluondunet]

3°) ea1042f
a great change on the issue, deserve a video:
https://youtu.be/xpVu2k6gnmw

croftengine.3.log

[legluondunet]

4°) 409265e
black and white


croftengine.4.log

[stohrendorf]

Thank you very much. The crash with test 2 shouldn't have happened at all, I'll investigate. About tests 3 and 4, these basically replace some rendering outputs with with internal shader stuff that I can test against. Regarding test 3, this confirms that the shader is working correctly at the tested point, so everything is fine here, even if it changes rendering drastically for you.

[stohrendorf]

Thanks, test 4 is an actual issue that is at least a part of the problem. I need to figure out a few more tests to narrow it down further, though. This is very valuable.

[stohrendorf]

Here's the next set of tests, these skip internal stuff and should hopefully not look that broken, except maybe the first one.

• 896307b614a80404d72c8df074f5a7c85163c834
• 640489805bf227b3a9485bb0667134d84667b565
• d39f5012b1b762443d273702e96b6bb7e6add8be

[legluondunet]

• 896307b
  
  
  croftengine.5.log

[legluondunet]

• 6404898
  
  
  croftengine.6.log

[legluondunet]

• d39f501
  
  
  croftengine.7.log

[stohrendorf]

That's worrying. Does 5fdb31535359923364e99fea85eff20aed7f401d change that?

[legluondunet]

• 5fdb315
  
  croftengine.8.log

[stohrendorf]

Dang. How about bfee7da6638e895b8c9aa6c603b11c5067477e4a? If that doesn't work there are only very few places left to check.

[legluondunet]

• bfee7da
  
  croftengine.10.log

[stohrendorf]

Are the artifacts on her arms and legs consistent or do they change/flicker?

[legluondunet]

How to use your save file?

[stohrendorf]

You have a AMD GPU card ? How to use your save file?

As the visuals are that broken right now, it doesn't matter. Anyways, within the launcher, open the "configuration" tab, and select "show data location", it will (hopefully) open your file manager at the user data folder. There's a folder saves/tr1, place the extracted file there.

[legluondunet]

a video for bfee7da
https://youtu.be/cfQw1av5I1A

[stohrendorf]

Huh. That video is actually interesting. How about dee3910c6a914bbcf4dbaa296f3605742598d239?

[legluondunet]

• dee3910
  https://youtu.be/GMmBwFJSbzs

[stohrendorf]

Uhm... I'm sorry to say, but that's probably a bug either with the driver or the graphics card. The video shows stuff that shouldn't be possible with the overall changes in that commit. There's nothing more I can do, sorry.

[Magnutic]

I saw the same issue with RX5700XT, also on Linux (Mesa 22.2.5). I investigated a bit using apitrace, and for what it's worth it seems to have something to do with the use of bindless textures in the vsm-square-pass.

I did a little hack to force using traditional texture binding for this pass. It fixes the glitches on my machine. Here's a patch that can be applied on cd05510: https://gist.github.com/Magnutic/af0b45766530acdfee0c86707fb6e53e

(Disabling AMD debug output was needed to make apitrace work.)

There are also glitches when using the edge-outline outline. I suppose the same underlying issue may be the same, but I have not investigated that.

[stohrendorf]

Interesting. Your patch shouldn't work at all, because you're passing a texture handle name into glBindTexture, which expects a texture name. These are completely different things, and glBindTexture should report a GL_INVALID_VALUE error because it wasn't receiving a texture name.

The OpenGL specs say:

GL_INVALID_VALUE is generated if texture is not a name returned from a previous call to glGenTextures.

...but the handle you're passing in was generated from a call to glGetTextureSamplerHandle. I couldn't find anything about this being valid in the ARB_bindless_texture specs.

As it turns out, it's valid, as written in issue 12 in the ARB_bindless_texture specs.

[stohrendorf]

It might be that flooding the code base with a lot of glTextureBarrier could help, but as this is a rare case of texture corruption, I'm anything but sure.

[stohrendorf]

@legluondunet @Magnutic could you check whether the current revision reduced or, even better, resolved your issues? That would be awesome. Thanks in advance!

[legluondunet]

just tested, no changes.

[stohrendorf]

Thanks for the feedback. This is unfortunate. I'm currently working on refactoring the engine to Vulkan, but it's a lot of work, and I'm just scratching the surface.