Please implement dynamic View Distance and Environment Detail settings; They are by far the most CPU-taxing settings and are currently static only (can’t set them to dynamically change based on current FPS).
In Valdrakken when crowded I can’t even get to a stable 60fps – I get 50~60 fps with everything set to max settings and ray tracing on. This is what I observed while changing settings in that scenario with my system specs (pay attention to the absurd difference by changing only the last two settings):
Resolution: From 4K to 720p – <1% fps difference
AA: From CMAA2 + MSAA 4x to Disabled – <1% fps difference
Ray Tracing: High to Disabled – ~5% fps difference
Shadow Quality: From Ultra High to Low – ~5% fps difference
Particle Effects: From Ultra to Disabled – <1% fps difference
SSAO: From Ultra to Disabled – ~1% fps difference
Ground Clutter: From 10 to 1 – ~1% fps difference View Distance: From 10 to 1 – ~45% fps difference Environment Detail: From 10 to 1 – ~40% fps difference Both View Distance and Environment Detail: From both 10 to both 1 – ~90% fps difference
My specs:
AMD Ryzen 5800X3D
32GB@3600MT/s
RTX 4090
Windows 11
Yeah, you’re CPU bound. That $330 5800X3D gets beaten by even a $95 i3-12100 in single threaded tasks(~6% faster). Those settings do specifically make mention of their demand though.
It would be kind of nice to have it dynamically scale those things based on frame rate, but it’s quite a bit more complicated than that. Changing environmental detail and view distance levels forces a hard blank on all materials and objects. This is likely a hard set value that gets set into the materials of everything for things like material LODs, mesh LODs, etc. It’s likely recompiling parent shaders, that the child instances derive from and which also need to recompile. Change the slider and click apply, you’ll see everything disolve and then reappear, which is evidence potentially backing up my claims.
When you’re making shaders, you want as few non-static and non-collapsible things as possible because they all get folded into simple optimized high speed functions. Based on the fact that changing these settings cause a blanking in all the objects, this likely isn’t a variable that can be dynamically changed without serious overhead costs or some complete rewrite of the rendering thread.
Oh and I also left out other important systems that would be affected as well like queries and occlusion, etc etc.
I won’t really rant much more at 6am chugging coffee while trying to unglue my eyeballs, but if you want to learn more, you’d have to look at how flow control works in shaders. Branch(doesn’t play well with gradient functions and texture sampling) and flatten(execute both sides of a statement, so you’re always paying more cost and there are some other limitations as well). If they were easy things to dynamically scale at runtime, without hitching things or causing visual issues, they would have likely already tied them to the target framerate system.
I appreciate the passionate and educative comment, so thanks for that I’m a software engineer [as well] though, so I understand those things.
You’re probably right about Environment Detail, but I doubt View Distance would have the same issues – if it does, then they’d better redesign their system. There are also some compromises they could do, such as evaluating on a longer timestep or per zone (many MMOs do this). Which gets to my point: this is a feature request for the development team. I’m not here to ask players whether they think this is viable or not (not my intention to come off as rude just want to emphasize that it’s their responsibility to make the game better, not ours :p)
No problem. And yeah view distance causes the blanking as well, likely because it’s forcing a z-pass to cull out stuff obscured by the fog. And in most other mmos, like ff14, you’re just in a glorified big room; since each zone is basically its own instance. So it’s kind of apples to oranges if you’re trying to compare.
Anyways, if you want them to potentially take your suggestion more seriously, it’s best to do it in game from help window where you can submit suggestions. The actual devs don’t seem to pay as much attention to things here on the forums. I know I wouldn’t want to if I were them because it’s all doom and gloom here and would likely demoralize the hell out of some of them.
The issue with WoW though is probably with the way they split and merge the terrain into chunks. Not sure if/how they still do this, last I looked was several years ago. Probably a good decision in 2004, though I doubt it still is today if it’s the same system.
Don’t know about FF14 but I’ve played other MMOs in the past that were completely open-world, no loading screens, no instancing shanenigans and still they implemented this. The graphical change is usually jarring (and sometimes comes with a big stutter), but it’s better than sitting at 50fps the whole time while in the city. And again, there are simple compromises you can implement to avoid the jarring changes/stutters, such as debouncing, async recompilation… which, again, their job…
Btw, about this, talking with friends and other ppl online with 13600k, 13900ks, and similar CPUs, they get only marginally better perf in the same situation (specifically around 70~80). As you probably know, performance is not only about whether it’s ST or MT – CPU architecture, cache, latency, code and memory layout, branches, all play a big role. Wow is not Cinebench R23 after all
Usually, but there’s likely a lot of other stuff going on under the hood. I don’t know the inner workings of their engine by any means, I’m just kind of using knowledge of related things from working mostly with UE4/5 and I’m by no means a rendering thread engineer lol… (Though I do know quite a bit from a medium to high level perspective)
They already have quite a few. One of the main theories I have about why the “per object cost” went up so much with DF is likely due to how they changed the engine to handle the very high speeds for dragon riding. There is a lot of evidence of it like how “doodad” level assets sometimes hard-pop in, rather than doing the fade in vs how that kind of stuff was handled before the DF prepatch. There are a bunch of other tells of changes like this as well.
There’s a big difference in flying around on a static mount vs zooming from darkshore to silithus in less than a few minutes, so a ton had to change under the hood. But like I brought up earlier about shader and engine optimization stuff, the elements that are needed to pull off things like dragon riding, likely added a flat overhead cost on everything and I’m not sure how it scales as you add in more objects. Hopefully it’s not some O(n log n) type scaling or something.
Valdrakken is an extremely thread bound zone due to all the NPCs and with it being up high and having clear view of the world, it’s a nightmare on draw calls. Though if they really wanted to slap a big bandaid fix on it, they could just throw in some trigger box for the city so that if you enter it, it will automatically cap distances to something like no higher than 5, no matter how high you have it set and then when you leave, it goes back to normal.
It’s baffling to me how they never learn. Dalaran LK, then Dalaran legion, now Valdrakken. The engineers should just accept the band-aid at this point as the designers clearly don’t value perf enough.
Well the reality is that the majority of gamers are still using 60hz displays and play with the game with vsync, since it’s the default setting. Going from 60 to 50fps isn’t a big deal for people playing like that. Also, your average GPU is an rtx3060 (steam hardware survey) and most players likely play with default graphics settings, so maybe 3 or 5 or w/e it defaulted to on their PC.
Interally, I imaging they target 60fps and don’t care how much FPS ceiling they clip off beyond that, since it doesn’t affect or doesn’t bother the vast majority of players.
I’m a software engineer [as well] though, so I understand those things.
just want to emphasize that it’s their responsibility to make the game better, not ours :p)