 |
@nbohr1more Seems to work for me as usual on current SVN Quick load in a small room with 1.1 GB used VRAM Noclip and fly over to grow usage to 1.6 GB with obvious stuttering when the textures queue to upload BTW this cvar in its current implementation is targeted for quicker mission load (i.e. game world start) rather than saving VRAM |
 |
Hmm... Maybe it's only broken on Linux? Edit: Forum reports indicate that only Linux is affected |
|
|
Updated the description. This only affects Bloom or SSAO That said, when image_preload is disabled the GUI flickers with messy white textures when transitioning animations too. |
|
|
It turns out that this sequence works live with no restarts: 1) Disable SSAO and Bloom 2) Set image_preload 0 3) Start the mission 4) Set image_preload 1 5) Enable SSAO and Bloom 6) Set image_preload 0 This does still have quirks with GUI elements flashing but it seems to retain the intended design. |
 |
It's fixed on trunk. |
|
|
I can confirm that the game now renders when SSAO is enabled and image_preload = 0 There is one last issue, which is that if you set SSAO and image_preload 0 there will be no SSAO effect when you start the mission. |
|
|
This "feature" is getting on my nerves... Fixed. Seriously, though, we may want to invest some time in proper load time reductions... |
|
|
Fix confirmed! Thank you! Yes, the image_preload dichotomy is a pretty bad implementation. Carmack thought that the normal "asset loading zone" design for open-world games was ugly so he avoided it with all his might. Then he invented "megatexture" as the "better version" of an asset loading design. I guess now that the kinks have been worked out in megatexture he has been somewhat vindicated. |
- Anonymous
