I did some framerate comparisons with different hair curve densities, and noticed that the relationship wasn't simply "more density = less fps". In fact, I got better performance with a high density than a low density, which was pretty weird to notice.
First, I tested with the Simone hairstyle by RenVR which I happen to use regularly, with sim on/off and collision on/off, and with vertex versus pixel lighting:
Vertex lighting seemed to exaggerate the difference in framerate between low-mid and high-mid curve densities.
Toggling hair collision while sim was enabled didn't seem to matter a lot: in both cases (red and yellow lines) the frame rate was highest around density 32 and lowest around 12 or 16.
Disabling hair sim, the frame rate scaled more linearly with curve density. Since the GPU load from the hair physics sim was removed, all of the difference was purely down to rendering. This implies that the physics sim itself is responsible for those the ups and downs in the mid range, at least with this particular hairstyle.
Next, I wanted to figure out if other factors would affect the result. The below tests were done in a different VAM session than the above tests, but in the same scene. Sim and collision were enabled and lighting was pixel.
Hair multiplier
For contrast with the Simone hairstyle, I picked a short straight hair - the short4 base style from short hair4 by @ddaamm .
With the short4 hair, the optimal density for performance was 16 instead of 24 (disregarding the ugly very low densities).
Camera position
Continuing with short4, I tested if the result was different from Simone because of how much hair was being rendered per area of screen by moving the camera closer.
Inconclusive result... Moving the camera this close, curve density didn't really matter.
Curl scale and frequency
I thought increasing curliness could bring out differences between different curve densities, but it's likely that the camera being too close was preventing that.
Conclusions...
Based on these initial results, the optimal curve density seems to depend most on the hairstyle and the viewpoint's distance from the hair.
In general, low densities below 24 seem to be not worth using. 24 to 32 is probably always good, and in some cases, high values of 40 and above can perform as well or better than values below 24.
However the results in the first graph with the Simone hairstyle, showing a significant improvement in fps above density 24, need reproducing.
Many more hairstyles could be tested and collected into a single graph. I'll try to find time to do that since it'd be interesting to get a clearer picture of how much the effect of curve density on framerate varies, and if there's a pattern that emerges.
Setup
Hardware: Ryzen 7 3700X, 32GB DDR4-3200, RTX 3080 10GB
The framerate was recorded as a rolling average over 15 seconds, waiting at least 20-25 seconds for the average to fully stabilize after changing settings. The built in performance monitor isn't really optimal for quickly getting averaged readings like this, I used my own plugin for that (Perfomance Overlay, paid).
Your thoughts?
First, I tested with the Simone hairstyle by RenVR which I happen to use regularly, with sim on/off and collision on/off, and with vertex versus pixel lighting:
- The screenshots show how close the camera was to the head - the hair filled up the height of the window.
- Hair multiplier was 64 to emphasize the impact on fps.
- The lights were normal InvisibleLight atoms.
Vertex lighting seemed to exaggerate the difference in framerate between low-mid and high-mid curve densities.
Toggling hair collision while sim was enabled didn't seem to matter a lot: in both cases (red and yellow lines) the frame rate was highest around density 32 and lowest around 12 or 16.
Disabling hair sim, the frame rate scaled more linearly with curve density. Since the GPU load from the hair physics sim was removed, all of the difference was purely down to rendering. This implies that the physics sim itself is responsible for those the ups and downs in the mid range, at least with this particular hairstyle.
Next, I wanted to figure out if other factors would affect the result. The below tests were done in a different VAM session than the above tests, but in the same scene. Sim and collision were enabled and lighting was pixel.
Hair multiplier
- Hair multiplier has no effect beyond just lowering the overall performance, curve density has the same effect.
- It's odd that there was less of an improvement in the midrange this time, just a small spike at 24.
For contrast with the Simone hairstyle, I picked a short straight hair - the short4 base style from short hair4 by @ddaamm .
With the short4 hair, the optimal density for performance was 16 instead of 24 (disregarding the ugly very low densities).
Camera position
Continuing with short4, I tested if the result was different from Simone because of how much hair was being rendered per area of screen by moving the camera closer.
Inconclusive result... Moving the camera this close, curve density didn't really matter.
Curl scale and frequency
I thought increasing curliness could bring out differences between different curve densities, but it's likely that the camera being too close was preventing that.
Conclusions...
Based on these initial results, the optimal curve density seems to depend most on the hairstyle and the viewpoint's distance from the hair.
In general, low densities below 24 seem to be not worth using. 24 to 32 is probably always good, and in some cases, high values of 40 and above can perform as well or better than values below 24.
However the results in the first graph with the Simone hairstyle, showing a significant improvement in fps above density 24, need reproducing.
Many more hairstyles could be tested and collected into a single graph. I'll try to find time to do that since it'd be interesting to get a clearer picture of how much the effect of curve density on framerate varies, and if there's a pattern that emerges.
Setup
Hardware: Ryzen 7 3700X, 32GB DDR4-3200, RTX 3080 10GB
The framerate was recorded as a rolling average over 15 seconds, waiting at least 20-25 seconds for the average to fully stabilize after changing settings. The built in performance monitor isn't really optimal for quickly getting averaged readings like this, I used my own plugin for that (Perfomance Overlay, paid).
Your thoughts?