1
\$\begingroup\$

Which of following approaches will have less performance overhead(using threejs renderer)?

I am currently have an issue with z-fight for distant objects, while my near/far plane is already set to most optimal setting to show close and far objects. I am thinking to apply some more advanced techniques for z-fighting. Also I've check depth configuration, and it is set to 24 bits already by default.

I am still planning to do performance testing to see which will work better. However I would ask a question in advance, if anyone already had an experience with that, and can suggest which of the approaches has less performance overhead.

More details about both approaches can be found here: https://cesium.com/blog/2018/05/24/logarithmic-depth/

  1. Most simples approach from coding perspective, is to enable logarithmicDepthBuffer like on manual bellow https://threejs.org/docs/#api/en/renderers/WebGLRenderer.depth - and I am planning to start prototyping using it, however the drawback it will disable this https://www.khronos.org/opengl/wiki/Early_Fragment_Test kind of optimization.
  • My concern if I will start scaling my scene with more object and shaders, it could be a performance issue then.
  1. So I was thinking about alternative approach, so called Multi-frustum rendering - basic idea is to render same scene multiple time, with different near/far plan setting without clearing color buffer.
  • It will keep Early Fragment Test enabled
  • However this approach is not for free, I have to render my scene multiple time.
  • I still can do some extra-optimization, by rendering only certain object for certain near/far plan settings.

What approach should have less performance overhead for the same scene?

UPD: I've made performance test on tiny scene, and didn't noticed any difference ~3000fps in both scenarios, however still don't know what to expect on bigger scales?

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Most questions of the form "which is better for performance, A or B" can be answered more conclusively by profiling. It is entirely possible that A performs better in one game, while B performs better in another, based on all kinds of details of the types of rendering loads each game uses, their particular pipelines, etc. So your best bet is to profile one solution and stress-test it (add extra content to your scene — it doesn't have to be real final content), then measure whether the performance is adequate. If not, try the other, or try to isolate the bottleneck and ask how to fix that. \$\endgroup\$
    – DMGregory ♦
    Commented Sep 6, 2021 at 14:39
  • \$\begingroup\$ HI @DMGregory, performance is the plan, however software engineering design is all about asking questions, instead of making stupid decisions that will not scale well in future. \$\endgroup\$
    – Dmytro Brazhnyk
    Commented Sep 6, 2021 at 15:29
  • 1
    \$\begingroup\$ It is. And the most conclusive way to answer those questions is to test them and measure the actual results on real hardware. \$\endgroup\$
    – DMGregory ♦
    Commented Sep 6, 2021 at 15:45
  • \$\begingroup\$ @DMGregory do you have any performance benchmarking result to share? By the way I've made one before posting this question on simple scene, and didn't notice any difference. I don't know what will be on bigger scale, that's why I am asking this question. \$\endgroup\$
    – Dmytro Brazhnyk
    Commented Sep 6, 2021 at 15:52
  • 1
    \$\begingroup\$ I haven't profiled both these specific features in WebGL before, and I'd suspect that given our low traffic numbers on this site, it's unlikely that someone who sees this question will have done so either. That's why I'm recommending profiling as the best way to get a trustworthy answer, quickly. Since you already have your test scene set up, you can stress it by ratcheting up the number of objects you draw, or the amount of transparency to test your overdraw and fill rate bounds. If you still don't measure a difference even when far exceeding your expected load, then either should suffice. \$\endgroup\$
    – DMGregory ♦
    Commented Sep 6, 2021 at 16:34

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .