Searching ways for flexible performance improvement on weak devices

performance

#1

Hello guys,

for my scientific work I have to find ways to improve the Performance of Three.js Applications.
For my Tests I used THREE.clock() to get the milliseconds/FPS, that I get/update in the render loop.

Now it’s time to make a Downgrade, if the performance is too bad.
For example:
if (fps < 15) { doThingsToSaveThePerformance(); }

At this momend I have serveral stuff on my list like:

WebGLRenderer:

  • renderer.antialias
  • renderer.precision
  • disabled shadows
  • set a smaller display resolution

Scene:

  • Level Of Detail
  • Prefer BufferGeometries
  • reduce geometry vertices (if possible)
  • group/merge meshes
  • reduce the lights

WebGL Shader

  • custom Vertex Shader
  • custom Fragment Shader

Now my target is to modiy my Scene and my Renderer in the doThingsToSaveThePerformance() example.
Maybe I can iterate through the children of the Scene-Object and have several subfunctions in a priority hierarchy, so it iterates over a list of performance-Methods like:

  1. diasbleRendererShadows();
  2. downgradeRendererPrecision();
  3. disableAntialias();

So my first question: is this a good and performant way?
And could I simply change things in the Scene-Objekt to realize things like:

  • remove all scene children if type contains “Light” (for all lights)
  • add an ambient light to the scene-Object

or

  • get and save all static meshes in Scene
  • remove them from the scene
  • group/merge the objects
  • add new object(s) to the Scene-Object

I’m really not sure if it’s a nice or a stupid idea. :slight_smile:
But maybe you coult clear my mind about my plan and more important things, that are not on my list.

Thanks for your help!

Metapholey


#2

Weak devices usually don’t support shadows or antialiasing in the first place, but disabling these sure can help. A major performance boost always will be reducing the resolution. On high DPI devices it can be even cut by half, depending on the actual devices screen size. Easiest way to do this is setting setPixelRatio on the renderer to 0.5.

I’ve added a optimizer to some appications which tracks the framerate and tries different settings to raise it at least around 24 FPS. I noticed it can be hard to properly measure, since the device will either lost context before it’s measured to take changes or it will stabilize itself after a while, so i needed to do the reverse as well.

Other points you mentioned such as LOD, BufferGeomtries etc. should be considered as standard. Geometries will be converted into BufferGeomtries anyway. In a lot cases desktop/laptop devices perform worse than mobile ones, especially if optimus is active or there is only integrated graphics available.


#3

Thank you for your answer, Fyrestar!

I had tested the setPixelRatio, but not on mobile devices. And because it hat such ulgy pixel results on screen,
I had ignored it as an option. But apparently that was a little too fast. :wink:

I am still not sure if the adaptation of antialiasing and precision in the renderer is worthwhile,
because I made Tests with a Desktop PC with Geforce, a Notebook with Intel DH Grafics and a Huawei Mate 10 Pro and on all devices I get similar Frame values with my Application.

To get the Frames for my .json-Object I use the THREE.clock() Object with a getElapsedTime for my var in the render loop. I am not sure if my measurements are sufficient to say that the use of antialiasis and percision is not worthwhile or at least not provable