Modern GPU and CPU underutilized by viewer, resulting in poor framerate and sometimes freezes
tracked
Huns Valen
The freezes are especially annoying with vehicles. Some places can cause rendering to stop for most of a second as you move near them.
Specs:
- CPU: Intel(R) Core(TM) Ultra 9 185H (3072 MHz)
- Memory: 65015 MB
- OS Version: Microsoft Windows 11 64-bit
- Graphics Card: NVIDIA GeForce RTX 4070 Laptop GPU/PCIe/SSE2
- Maximum bandwidth setting: 8,000 kbps
Test 1: Standing still
- Draw distance: 512
- Position: NE Albion, looking west towards Abbotts
- Framerate: Stabilizes around 11FPS
- CPU: ~11%
- GPU: ~18%
Test 2: Flying unassisted: Albion - Yamato
- Draw distance: 512
- Framerate: Varies between 4-8FPS
- CPU: ~20-30%, occasional spikes to 49%, depending on object density
- GPU: ~18%
Log In
Kyle Linden
marked this post as
tracked
Beatrice Voxel
The problem isn't the CPU or GPU capability, it's the VRAM.
Because your draw distance is so far out, your system is having to store every texture within the region, as soon as you enter it. In an AAA game that wouldn't be a problem, because all those textures have been optimized. But in SL, textures of objects (and mesh of objects) are all made by fellow residents, many of whom do not know what 'optimizing' even entails.
Couple that with LOD calculations for when you do get close enough to see something (another factor many newbie or intermediate creators don't consider) and yes, your viewer has to figure things out. If the region is populated, you've also got animations loading, people with hundred-flexie skirts (shudders) moving around... it's a mess.
The SL engine is old, and the content is about as varied in age and quality as all of the items at a large flea market. But if you decrease draw distance to below "binoculars" distance (128m should be fine for driving, 256m for flying), and also kick your LOD factor for distant objects down, you'll probably get better performance. It won't be great, but it'll likely be better.
Huns Valen
Beatrice Voxel
I'm not asking for an explanation of what's wrong. I'm asking them to refactor the client to bring it from 2002 to 2026. To get away from the massive single-threaded workload that makes traveling with high draw distance awful. That is the problem, not bus saturation.
They farmed out image decode and a few other things to worker threads, but they still have the meat of the rendering pipeline in one thread. Fixing that is a major overhaul. Not fixing it makes the experience jankier than it could be. The attached image shows about 70 milliseconds in ONE FRAME being spent almost entirely on CPU-bound logic, and that's only the parts they instrumented in the fast timers overlay. (Geo Update is almost entirely CPU, does talk to the GPU concerning trees/water/sky, but these are not significant factors.)
It's bad for me at high draw distance, and I have a 16-core CPU and an RTX 4070. Other people with older/slower machines have to run at very small draw distances, or throttle their network bandwidth severely.
Toothless Draegonne
You're on the madlands with a 512m draw distance. I'm not sure there's a developer studio on the planet that could solve your problem. Especially not with a UMPC-oriented APU and a laptop 4070.
...which, incidentally, is the same laptop GPU I'm quite happy with because I'm not on the madlands with a 512m draw distance.
Huns Valen
Toothless Draegonne I think they should try :)