Sirius wrote:Tsar Hoikas wrote:With the recent-ish release of the PotS beta executable, I have gained the ability to fully interpret stack dumps from crashes from that particular build of the game.
Oh, cool !
I would have never suspected Uru created textures during regular exploration. I thought everything was in VRAM once the Age was loaded and no new data was created afterwards.philipgr wrote:If there is not enough memory on my graphics card will the game not then an take what it needs from the 32GB on board memory?
Unfortunately, no. The RAM generally does not extend the VRAM (Video RAM), so running out of VRAM will cause Uru to crash. It is however possible to force some applications to use software rendering only (rendering with the CPU instead of the GPU). This is much slower so you'll have less FPS, but means you will use all your 32 gigs of RAM.
Lowering the texture resolution should be much easier though. It's best to try it before attempting software rendering which has its own issues.
Uru loads all textures into system memory on age load. Further than that, it is difficult for me to say since the rendering pipeline was upgraded from Direct3D8 (PotS) to Direct3D9 in EoA/MOUL. In the EoA/MOUL pipeline, textures are loaded into DirectX's "managed" pool. The managed pool is very convenient -- DirectX copies the resources into its own system memory and ensures they are always available for rendering. So, for example, if there is not enough VRAM, DX will take care of ensuring textures are moved from system to video RAM so rendering can proceed. I note philipgr asked specifically about using the system RAM -- for sure on MOUL that works just fine.
What I cannot say is that the DX8 pipeline uses the managed pool, or if there even was a managed pool in DX8 at all. I am, after all, unfamiliar with DX8, and finding documentation on pre-DX9 graphics technologies (read: 20+ year old code) is challenging at best. However, the released Plasma source code allows an interesting window in history that goes all the way back to 1997. There are lots of comments in the DX9 pipeline about the default pool and lots of old bugs around things like the GeForce2, Savage, and Windows 2000 (fun). The default pool does not attempt to help you at all. Everything is sent directly to video memory. If the device is lost by, for example, Alt+Tabbing away from the game, you have to reload the resources yourself. I expect this is how the old DX8 pipeline works primarily.
dendwaler wrote:i have done all what i can to lower this, the engine does not support "streaming graphics " There are many visregions used in a way to avoid loading graphics of areas you can not see from your point.
VisRegions do not prevent the loading of "graphics," rather they turn on/and off the rendering of geometry.