Low Performance Preset

Programming
1

Based on my analysis of different graphics options used during a playthrough of the latest 0.9 devbuild, I have some suggestions for what settings to use for a Low Performance Graphics Preset.

  1. Disable Microbe Ripple Effect. This is the most performance intensive default setting, and cuts the fps in half in both the early and late game.
  2. Disable MSAA. This gives a significant performance boost across the early and mid game, still giving a useful performance boost in the end game as well. Using FXAA instead did not noticeably change performance any more than disabled AA on my machine, so we could consider using FXAA on the preset instead. but fully disabling AA would be the safer option initially at least.

No other graphical setting seems to make much of a difference to the performance on this machine at least. So these are the only two I can confidently suggest.

There is one last important graphical setting, the resolution scaling option, which does have a big effect on performance. But I am not sure if we would want to set a lower resolution by default in the low performance preset given that monitor resolution can change so much, and this seems to not be a common setting to have changed by a preset. While I think that setting the resolution to 75% on my low performance reference laptop provided a good balance of increased performance for an acceptable loss of resolution, I am not confident that this is a tradeoff that enough players would agree with. I think it is still worth considering though.

The Low Performance Reference machine I used is a 2011 mid-range laptop, with an i5-2520m and Intel HD 3000 integrated graphics.
It ran the game at an acceptable fps throughout the game in the latest devbuild of 0.9, and its performance seemed to be similar enough to other computers mentioned on the Thrive forums that it is representative of the kind of low performance hardware that Thrive is played on. Also, the game seems to now be mostly free of lag spikes and stuttering, and so even when the game has a low fps it is consistent enough to be a smooth and playable experience.

This is the performance the game was getting at the suggested low performance preset settings across editor cycles 2-13, ending with multicellular. Cycle 13 is noticeably lower in fps, but this is due to having a particularly large amount of player cells clumping together, over 20, and so this represents the worst case multicellular fps. I also did testing in multicellular stage and the performance was closer to the previous 17fps average in microbe stage. There is another noticeable drop in performance at cycle 8.5, which is where I zoomed out the camera to maximum due to cycle 8 becoming a eukaryote, and it seems like most players zoom out the camera by now as the cell begins to fill the screen. At this point, typically 20-30 cells are visible on screen fully zoomed out.

image
image635Ă—451 21.2 KB

All testing on this graph was done in the vents patch, but the tidepool patch seemed to have very similar performance on this machine when tested separately. Hhyyrylainen mentioned that the performance on his computer was much lower in the tidepool due to the particles, so this might be something to look into in the future as this difference was not seen on my machine using the latest devbuild.

1 Like
2

Which upscaling mode did you use? On my low-end test machines I can only use like the bicubic filtering for upscaling as FSR 1 and FSR 2 add so much compute overhead that I’d need to crank down the resolution scale to like 30%, but using the simpler upscaling mode allowed me to have a more reasonable resolution scale at 70% and it still improved performance quite a bit.

So yeah, I also don’t know if low settings should have a resolution scale applied because we would need to pick a mode for it and on many low end devices they cannot handle the overhead of FSR (which looks way better than simple upscaling). But then on a little bit more powerful devices FSR 1 doesn’t really impact the framerate whatsoever. And of course then on a proper gaming GPU it doesn’t care if you even use FSR 2.

At least this is my assumption, because my Windows 10 computer has a GTX 1080 Ti in it, and that should still have way more graphics power than an integrated GPU, though it doesn’t have as new features anymore, which is why I’m guessing it experiences a problem. I don’t really have any other explanation than some particles, because when I played in the vents I got basically vsync locked to 144 FPS, but then moving to a surface patch, I only got 40-60 FPS (at best), which is a super weird performance dip.

So yeah, I want to add a graphics option to disable the current particles to be able to confirm if that’s the problem.

1 Like
3

The OpenGL renderer can only support the Bilinear filtering, so that would have to be the default for that renderer anyway.

The oldest Vulkan Compatable integrated GPU I have that I could test out the different upscaling methods on would be a Surface Pro 3 i5 4300U, with HD Graphics 4400, from 2013. This particular system nearly requires the heavy resolution scaling due to the high resolution screen. I can test that out later if we are considering resolution scale on a preset any further.

I have a Windows 10 computer with a GTX 970 in it, which is similar era hardware, so I could also test out that machine if you need a comparison if your investigation of the performance difference between patches is inconclusive.

1 Like
4

Oh right, I did not remember that. So it kind of would be possible to have a resolution preset for OpenGL mode, but like you said that might not actually help that much if people are pairing low end computers with low resolution screens anyway.

5

It turns out that the Intel 4000 series processors iGPU (Haswell) only supports Vulkan in Linux, and not Windows 10. Only 6000 series and up (Skylake) supports Vulkan in Windows unfortunately.

Anyway, it seems like the resolution scaling has broken on my Surface Pro 3 i5 4300U with HD Graphics 4400 machine, as it always drops performance significantly when enabled. Using OpenGL renderer on Windows 10 due to the Vulcan support lacking on Windows.
This occurs on the latest 0.9 devbuild, while the resolution scaling works fine on 0.8.3. I don’t think those settings would have been affected by anything other than the switch to the new Godot version?
It is kind of strange that it broke on this machine, while it worked fine on the previous generation of Intel iGPU on that same devbuild.

It might just be me, but when testing FSR 1, 2, and the simple bilinear on my main PC, I couldn’t really see much of a difference even at below 50% resolution scaling. FSR 1 looked nearly the same to me, and FSR2 was only slightly noticeable, but was not worth the performance cost even on my modern GPU. I think it is because the game has a lot of blurring effects, such as the chromatic aberration and others, that contribute to the output being quite soft. So I don’t think FSR 1 and 2 are especially useful on the microbe stages. (And I don’t think there is anything wrong with the microbe stage being soft, I think it looks right.)
I would suggest that having bilinear would be an acceptable default for the low resolution preset even when using Vulkan. And even if we don’t set the resolution scaling to lower than 100% with the preset, having bilinear be the default option would be better if the player does decide to change the resolution setting manually without testing the other settings.

6

Yeah, the update to Godot 4.5 is about the only thing I can think of that could have caused it. If you can figure out how to trigger the bug, there might still be time to report it to Godot for a 4.5.1 patch release which I think is coming pretty soon.

Interesting. I was testing with the 3D main menu backgrounds enabled, and there is a huge difference in the volcanic vents background in how good it looks, like bilinear filtering makes the foreground, well, ground look totally terrible with like 30-40% resolution scale, but FSR 2 is able to rescue the quality of those elements.

In my eyes the difference in quality is again so huge that we should not set a mode by default that is unnecessary on a reasonable gaming computer. So again I kind of think that these ultimate low end computer users will just have to know how to crank down all the settings, unless we have like a “very low” quality preset where we have truly put everything as low as they go.

7

I was testing just in the microbe stage, so perhaps in the future with the 3D stages the bilinear option would diverge more. Probably because the 3D main menu doesn’t have the softness applied by the filters like chromatic aberration? FSR 2 is kind of magic though in applicable scenarios like the 3D main menu backgrounds, though when testing the 3D menus I still didn’t see much of a difference between FSR 1 and bilinear. And I have not yet found a situation where FSR 2 actually is a better choice performance wise than just having higher resolution, but I suspect that this might occur in the 3D stages.

That brings up a good point, I have been mostly focusing recently on just the lowest performance computers we intend to support. What do you think the highest performance systems that should be using the low performance preset would be? Just to clarify, do you think that “a reasonable gaming computer” would consider using the low performance preset?

Our current listed Minimum requirements on Steam are: Intel Core i5-4570 or AMD Ryzen 3 3300U, and Intel HD Graphics 530.

Do you think the minimum requirements system would typically use the low performance preset?

I can probably test some sort of roughly equivalent system to whatever we think we would consider for the highest performance computer that would use the low performance settings, so it would be useful to know what you think about that.

Also, do we want to consider updating the Minimum and Recommended system requirements before 1.0 is released? I can help test out different systems if we have a target in terms of fps for certain screen resolutions and settings to find out what our Minimum and Recommended systems would be.

8

The HD 530 might be weak enough. The minimum system requirements are kind of what I estimate to be minimum that you actually need to play Thrive at 20+ FPS and low resolution with all effects turned off that you need to hit that performance.

Though HD 530 is not exactly the worst possible integrated graphics, so compared to a truly “very low” preset it might be able to run some additional effects.

I don’t think we can update the minimum system requirements, that would potentially impact many people negatively (including some who have purchased Thrive based on what hardware they have).

1 Like
9

I have a HD 630 system, which should be identical architecture with perhaps 10% performance boost at most. I will be testing that out soon with the prospective low performance presets to see if they fit.

What would you consider to be the minimum fps needed to run with the default preset? I want to find what the highest performance machine is that fails to meet that number, so that I can see how the highest performance hardware meant to use the low performance preset should be.

1 Like
10

I’d say at least 30 FPS. If some people prefer higher FPS then they would need to trade some extra options for more FPS (if they still had some visuals on).

1 Like
11

I just tested a mid range gaming laptop from 2017

Specs: i5-7300HQ 4 core, IGPU: HD Graphics 630, DGPU: GTX 1050

Notably, the specs are very similar to the listed Minimum system requirements on Steam, with the HD Graphics 630 on this machine being only about 10% higher performance than the HD 530 listed on Steam. The processor is also comparable to the listed i5-4570, also being a 4 core, 4 thread processor with only a 3% different passmark score. Both the IGPU and DGPU were tested separately.

First, I compared the difference between tidepool and vents, and the fps seemed to be around the same regardless of graphics settings. This occurred both with the IGPU and the DGPU. The DGPU got around 85-90fps on default settings, and the IGPU got 23-26fps with low performance settings, described below.

When using the IGPU, the settings to disable was: Microbe Ripple Effect, AA, Chromatic, Bloom, and Enable Low Res Background Blur. This gives 23-26fps. Without these settings, the performance was not good, lower than 14fps.

Additionally to the previous settings, setting res to 50% (Native is 1080p) on the IGPU:

50% res bilinear bumps to 38fps
50% res fsr 1.0 bumps to 29-30fps (and does look a decent amount better)
50% res fsr 2.2 drops to 15-16fps

I also tested resolution scaling on the DGPU even though it really did not need it unless you have a high framerate monitor. Bilinear and FSR 1.0 seem useful across all resolution scales, but similarly to all other systems I have tested, the FSR 2.2 does not give a performance benefit unless you drop the resolution way below 50%, and even still it is not useful because it looks so much worse at that low resolution scaling.

My recommendation based on this is that FSR 1.0 should be the default setting for resolution scaling, as I have not seen a case yet where FSR 2.2 is a good option. Perhaps that will change in the 3D stages, but I think we could reconsider the graphics options at that point.