I have a WebGLMultisampleRenderTarget working with EffectComposer, based on the example, and with UI to set the number of samples used. Currently I’m recreating the entire composer each time the samples count changes. From a quick pass through the source it looks like the setup of the render targets on the composer isn’t accessible anywhere except the constructor. But maybe I’m missing something. Is there a better way to update the samples without recreating the entire composer? Thanks!
The samples parameter can not be changed on the fly since it is used when renderbufferStorageMultisample() is internally called. So if you change the samples property after the render target’s initialization, it won’t have any effect.
May I ask: Why do you want to change it in the first place? I’ve never seen that this is actually done.
OK, that’s what I thought. Thanks! Though given your question maybe I’m not using this as intended. As far as I can tell, the multi-sample render target creates an anti-aliasing effect, and based on this comment, I got the impression it would be faster than SSAA. I was also having rendering issues in a particular browser with SMAA, hadn’t tried SSAA yet. But I want the user to be able to set the level of AA in use, which corresponds to samples, right?
Yes. The default is 4 which is 4xMSAA.
Four is not always enough to remove aliasing. I’ve encountered a couple of scenes where I had to increase this to 8. I didn’t notice any performance hit from doing so (on my laptop at least).
By the way, I was under the impression that WebGL MSAA uses 8 samples. I cannot find any docs for this, however. Perhaps it’s per-browser/platform/GPU?
Sorry, my question was not clear. It’s okay to define a sample value when an instance of WebGLMultisampleRenderTarget is created. However, changing this value on-the-fly is something one should avoid. I was actually referring on this point in my first post.
The problem is that the number of samples can’t be easily changed like texture parameters via WebGLRenderingContext.texParameter(). Instead you have to re-create the whole renderbuffer which is obviously something you want to avoid if possible.
1 Like
I’m not sure how to respond differently. The use-case is the same. For example, in a video game I can often pull up a settings menu and choose a different option for AA. Typically it’s not necessary to close and reopen the game in order to get the settings to apply. Similarly I don’t want the user to have to reload the page in order to change to a different AA setting. What’s the harm in recreating the renderbuffer? Right now that’s what I’m doing. Recreating the composer and adding the passes to it again each time the user changes the AA setting.
Nothing is stopping you from reloading the webgl, and subsequently the three.js context without reloading the page. Your issue would probably be keeping track of all the relevant state, and reapplying that. I’ve played plenty of games that required restarts on certain graphics changes.
You don’t have to refresh the browser or restart the app. You just have to create a new WebGLMultisampleRenderTarget, and dispose of the old one.
1 Like
You don’t have to refresh the browser or restart the app. You just have to create a new
WebGLMultisampleRenderTarget, and dispose of the old one
Yep, that’s what I’m doing. @Mugen87 just seemed to think that was something to be avoided (“you have to re-create the whole renderbuffer which is obviously something you want to avoid if possible”).
1 Like
Sorry for not being clear. I just wanted to highlight the implications of this operation.