Amerio.Stephane Posted May 30, 2025 Posted May 30, 2025 Hello, This bug is very easy to reproduce, but turned me bad before being able to isolate it! create a new project (tested with double precision, c++) in the default world, default main player, set the fov,znear,zfar to 70, 0.01, 100000 edit launch_debug as follow: start "" "%app%" -video_app dx12 -main_window_size 800 600 -main_window_resizable 1 -data_path ../data/ -console_command "config_autosave 0 && world_load \"bugfov\"" launch, and try to resize the window. It will turn black on certain size. In our application, this bug can be triggered for various fov/znear/zfar/size combinations, but I couldn't find the real discriminant. Note we do need this znear/zfar combination with large view angle in our specific case. This bug did not occur in 2.16 (or was never triggered at least).
bmyagkov Posted June 2, 2025 Posted June 2, 2025 Hello Stephane, Thank you for the report. Could you please clarify how frequently you need to resize windows in this manner while using the application? If there’s a particular workflow or use case involved, we’d greatly appreciate any additional context as it may help us better understand the issue. So far, we haven’t been able to reproduce the problem on our end. If possible, could you share any relevant details about your setup—such as operating system, hardware configuration or driver versions—that might help us investigate further? Lastly, we’d be grateful if you could let us know how critical this issue is from your perspective, so we can assess its priority accordingly. Thanks!
Amerio.Stephane Posted June 2, 2025 Author Posted June 2, 2025 The bug does not seem to be linked to the hardware (maybe linked to nvidia cards?) as it appears on a variety of setups: quadro, rtx, i9, i7, most recent drivers... Tested on Win10 and 11. We don't really need to resize the window, it's just that the bug is more easily triggered by resizing. For the full context, one of our app was working great in 2.16 and 2.18, and once migrated, the screen simply went full black: only the console and visualizer seemed to work. It turned out in this project the znear and zfar were something like 1cm and 100km with a large FOV (80°) (which was expected for this project, close inspection of cockpit elements while flying). Changing the znear to 10cm fixed partially, unless we resized the window where again everything turns black. We also found that this bug can also be triggered with SpiderVision enabled: the spider view sometimes appears in a smaller 'view' inside the window (couldn't get a screenshot). Resizing the window (F10 key) somewhat fixes it (or not). At the moment, simply changing the FOV from 80 to 79 might hides the bug, but I'm afraid it might appear in our zoomable sensors in a deployed environment, so I'd say quite important/critical.
bmyagkov Posted June 2, 2025 Posted June 2, 2025 1 hour ago, Amerio.Stephane said: The bug does not seem to be linked to the hardware (maybe linked to nvidia cards?) as it appears on a variety of setups: quadro, rtx, i9, i7, most recent drivers... Tested on Win10 and 11. We don't really need to resize the window, it's just that the bug is more easily triggered by resizing. For the full context, one of our app was working great in 2.16 and 2.18, and once migrated, the screen simply went full black: only the console and visualizer seemed to work. It turned out in this project the znear and zfar were something like 1cm and 100km with a large FOV (80°) (which was expected for this project, close inspection of cockpit elements while flying). Changing the znear to 10cm fixed partially, unless we resized the window where again everything turns black. We also found that this bug can also be triggered with SpiderVision enabled: the spider view sometimes appears in a smaller 'view' inside the window (couldn't get a screenshot). Resizing the window (F10 key) somewhat fixes it (or not). At the moment, simply changing the FOV from 80 to 79 might hides the bug, but I'm afraid it might appear in our zoomable sensors in a deployed environment, so I'd say quite important/critical. Thank you for the additional details — they’ve really helped us better understand the issue. It's now clear why this could become a significant blocker for the runtime application. We’ve already forwarded all the information to our QA team in the hope that they’ll be able to reproduce the issue soon. There might be a few follow-up questions from their side as they investigate further. We’ll keep you updated and get back to you as soon as we have any new information. Thanks again!
bmyagkov Posted June 2, 2025 Posted June 2, 2025 @Amerio.StephaneWe’ve successfully reproduced the issue and a corresponding ticket has already been created in our internal bug tracker. It’s likely that the fix will be included in the upcoming SDK update which we expect to release by the end of June. However, if you require this to be addressed earlier in the current 2.19 release, could you please let us know what timeframe would work for you? Thanks!
Amerio.Stephane Posted June 6, 2025 Author Posted June 6, 2025 If you can produce a hotfix easily, then great for me! Otherwise I'll wait a few weeks.
bmyagkov Posted June 6, 2025 Posted June 6, 2025 1 hour ago, Amerio.Stephane said: If you can produce a hotfix easily, then great for me! Otherwise I'll wait a few weeks. We're aiming to include the fix in the upcoming 2.20 update. In the meantime, as soon as the commit is ready we'll send the patch over to you that same day—no need to wait! Thanks!
Recommended Posts