Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to configure your browser for maximum performance #1

Open
denisbogol opened this issue Jun 14, 2019 · 10 comments

Comments

@denisbogol
Copy link

commented Jun 14, 2019

Light Tracer's performance mostly depends on the graphics card used, but there are some other important factors. Below, we will briefly describe how to configure the browser for maximum performance. Please note, that currently, Light Tracer works on desktop versions of Google Chrome and Mozilla Firefox and requires WebGL 2. Other platforms are not officially supported.

Use latest graphics drivers
It is important to keep your graphics drivers up-to-date, because browsers may not enable WebGL 2 for old driver versions.

Use discrete graphics card (if available)
If your PC has several GPUs, or your laptop is equipped with NVIDIA Optimus technology, please ensure that Web browser is running on the most powerful graphics card. The simplest way to identify the GPU used for rendering is to check the https://webglreport.com/. Here, in the field "Unmasked Renderer" you may see currently using graphics card. Also, please ensure, that your browser supports WebGL 2 which is required to launch Light Tracer. If your browser uses integrated GPU instead of powerful discrete graphics, please try these instructions:
How to run WebGL on discrete Nvidia GPU for notebooks with Nvidia Optimus

Use native OpenGL
Also, since Light Tracer is implemented in WebGL 2, it is highly reasonable to switch underlying 3D API to OpenGL. This will not only improve the performance but make shader compiling process much faster.

In the case of Google Chrome, you can find Chrome flags by just typing “chrome://flags” or “about://flags” in the Omnibox (address/search bar). Once "Chrome flags" is open, you will see a list of features that you can enable or disable. We need "Choose ANGLE graphics backend" setting that should be set to OpenGL (instead of ANGLE). After changing it, click on “Relaunch Now” button that will save your changes and restart Chrome with your changes in place.

For using OpenGL in Firefox you need to change the runtime option. Type "about:config" into the address bar. In recent versions of Firefox, find "webgl.disable-angle" variable. By default, it is set to "false": native OpenGL is not used. Set it to "true" to start using OpenGL (browser restart is not needed).

@hb3p8 hb3p8 pinned this issue Jun 14, 2019

@stefkeB

This comment has been minimized.

Copy link

commented Jun 17, 2019

Is this supposed to also work in Safari on macOS? I can activate WebGL2 as an experimental feature and confirm this from the WebGL website, but to no avail. Only a black screen.

@denisbogol

This comment has been minimized.

Copy link
Author

commented Jun 17, 2019

Indeed, it is supposed to work with enabled WebGL 2.0 in Safari, but to the moment we were not able to identify & fix the actual problem. As a temporary solution, you may use Chrome on MacOS.

@hb3p8 hb3p8 added the hints label Jun 19, 2019

@ArixCuirax

This comment has been minimized.

Copy link

commented Jun 27, 2019

Hello Denis and Danila, 0.9.3 doesn't seem to work in Chrome for me. It's showing a black screen. It does seem to work in Firefox. Running a Vega 64 on Windows 10 64 bit 1903. All my previous renders were in Chrome on 0.9.2.

It seems to work fine in Firefox though (never used it before I started getting the black screen in Chrome). There is a slight chance this may be due to my customised GPU driver settings and/or application profile for Chrome which I just set up in Radeon Settings. I'll update if I manage to rule that out as a cause.

BTW, here are my driver settings :

image
image

I have temporarily de-activated the Chrome application profile and I will also be updating my driver shortly and rebooting as well. Then I'll try reverting Chrome settings to default to see if that helps.

Also, here's what I'm getting in Chrome after updating to 0.9.3 :

image

@ArixCuirax

This comment has been minimized.

Copy link

commented Jun 27, 2019

Very peculiar. Seems I just needed to Ctrl+F5. Updating the video driver to 19.6.3 didn't fix the issue. Neither did disabling the custom profile I'd made for Chrome in Radeon settings. LT also worked fine in Opera. I then tried Ctrl+F5 in Chrome and now on 0.9.3 and LT displays again.

@denisbogol

This comment has been minimized.

Copy link
Author

commented Jun 28, 2019

Hi @ArixCuirax ,

If I understood correctly, v0.9.3 works normally after Ctrl+F5 (clearing the cached version of the page)?

Thank you for reporting this issue. Before next release, we will try to find some way to notify the browser that cached version is outdated and cannot be re-used.

Please let us know if you notice any other issues.

@ArixCuirax

This comment has been minimized.

Copy link

commented Jul 3, 2019

Me again, I have a few questions.

  1. What does the RN coherency setting do? Setting it to 0 seemed to produce better renders quicker.

  2. What does the Unit of length setting do? Does it play a role in scaling the model as far as the light travel path is concerned?

  3. How does Light Tracer build the rendered image? Does it average the results of all samples for a given screen pixel over time? If so, does this mean that the render improvement is asymptotic - it improves quickly at first and more and more slowly over time (because every additional sample has an ever decreasing contribution to the average value which has already been achieved for that pixel)?

If so, could an additional setting be added which controls how much weight a given new sample's contribution to the existing colour average of a pixel's colour is? And if we want shorter render times we can make the contribution of each new sample to the existing pixel colour average larger and if we want more accurate end results we can set the contribution of each new sample to the pixel's existing averaged colour to be smaller?

@denisbogol

This comment has been minimized.

Copy link
Author

commented Jul 3, 2019

Hi @ArixCuirax,

  1. In fact, 0 coherency leads to more smooth images with more "natural" noise. But, rendering performance (i.e. FPS) will be lower with such a config (not too much, maybe ~30%). If coherency is high (close to 1), ray paths have become more coherent (similar) which is good for GPU and lead to higher performance. But, in both cases, the final image (when there is no visible noise) is the same. So, please adjust it according to your preferences.

  2. Unit of length is needed to treat parameters of Camera Lens (e.g. focal length, which is defined in mm). So, the unit of length specifies units used by scene (your model), and thus it defines how we should re-compute focal length to scene units. Changing this setting does not lead to any recomputations of geometry, accelerating structures, etc. It only affects camera treatment.

  3. You are absolutely right, it uses Monte-Carlo integration to estimate the color of each pixel (it is a quite common approach for photo-realistic renders). And the error in the image (noise) decreases proportionally to ... sqrt ("number of samples"). So, to decrease noise in 2x you need 4x more samples. In order to minimize computation time, we try to use some smart importance sampling techniques whenever possible.

In fact, your proposal regarding control of minimal contribution is very natural and already planned for the next version.

@ArixCuirax

This comment has been minimized.

Copy link

commented Jul 3, 2019

Thank you for your comprehensive and detailed explanation. I appreciate you taking the time to provide this information. It's fascinating and gives insight into how your path tracer works.

I prefer leaving the RNG coherency set to 0 because the image seems to be become nicer quicker even though reading your explanation I now understand this is actually slowing render times. The noise just seems to be more difficult to spot. I will be using it from now on.

Also, very nice to hear that control of minimum contribution is already a planned feature of the next version. I really appreciate your excellent work, thank you!

@ArixCuirax

This comment has been minimized.

Copy link

commented Jul 3, 2019

Can we please also have Render settings saved to a cookie in a future version as well? :)

@ArixCuirax

This comment has been minimized.

Copy link

commented Jul 5, 2019

Actually, that might not be a good idea after all, at least for me, because I always turn off the tile based rendering and generally use 32 bounces and everything graphics related becomes quite chuggy and skippy.

That's ok while performing the actual render but not something I'd like to have stored in a cookie and applied automatically when I first open the renderer and haven't yet imported my model, created a floor or assigned materials.

Unless there was also a pause function or button which defaulted to on when you first launch the renderer so as to allow the user to set up the scene in rasterization mode only rendering before the gpu starts being put to work actually path tracing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.