Closed HawkenKing closed 2 months ago
I'm not sure this is from MSAA - since pixelate is a post-process, I believe everything is still rendered at full resolution, then averaged down to the low-res output. So I believe this kind of super-sampled AA is just how the pixelate function works (correct me if I'm wrong). It sounds like you'd rather just render at extremely low res (which would be a lot faster anyway). This feels a bit more Three.js-level of API - can you help me understand your use case?
I'm not sure this is from MSAA - since pixelate is a post-process, I believe everything is still rendered at full resolution, then averaged down to the low-res output. So I believe this kind of super-sampled AA is just how the pixelate function works (correct me if I'm wrong). It sounds like you'd rather just render at extremely low res (which would be a lot faster anyway). This feels a bit more Three.js-level of API - can you help me understand your use case?
Hi, I checked out the MSAA filter, this is set to off as default so I don't think it's from that. The Renderer applies a base anti-alias as default I believe. This usually can be turned off with the following code in threejs:
renderer = new THREE.WebGLRenderer( { antialias: false } );
I understand that because this is part of the core renderer setup process, it's not augmentable later on in a script so the switch would need to be part of a model-viewer embed tag. If this could be set to false by the user, the noisy edge would be removed from the pixelate filter.
I hope this helps explain the use case. Many thanks.
I don't think you understood my comment. The base anti-alias the renderer applies by default is MSAA. I still believe what you're seeing is due to the pixelate function, not our anti-aliasing. Can you make a simple example using just the pixelate function from postprocessing (no MV) to show your desired behavior? I believe you'll find the same problem there.
I don't think you understood my comment. The base anti-alias the renderer applies by default is MSAA. I still believe what you're seeing is due to the pixelate function, not our anti-aliasing. Can you make a simple example using just the pixelate function from postprocessing (no MV) to show your desired behavior? I believe you'll find the same problem there.
Hi, The example I posted uses the following code, the pixelate effect is the only filter active https://modelviewer.dev/examples/postprocessing/index.html:
<example-snippet stamp-to="setup" highlight-as="html">
<template>
<!-- Use the <effect-composer> component inside the <model-viewer> element -->
<model-viewer autoplay ar camera-controls touch-action="pan-y" src="../../shared-assets/models/Horse.glb" scale="0.01 0.01 0.01" alt="A 3D model of a horse galloping.">
<effect-composer>
<pixelate-effect></pixelate-effect>
</effect-composer>
</model-viewer>
</template>
</example-snippet>
I'm going to close this as intended behavior - this is how the pixelate effect works, which we didn't write; it comes from another library.
Description
When using the pixelate filter, anti-aliasing is also upscaled into the result, this can create an unwanted noisy edge on models. Currently, there isn't a way to turn off anti-aliasing in model-viewer. Being able to set antialias: false would remove the noise artefacts from the pixelate filter, and for other uses where anti-aliasing isn't desired.
Live Demo
Edge of running horse gets white pixels on outline of horse. https://modelviewer.dev/examples/postprocessing/index.html
Version
3.4.0
Browser Affected
OS