Rendering artifacts

I’m having screen artifacts on exported .glb models. How should I attack this issue?

if u r using blender, make sure the model materials are double sided and disable back face culling.

@Ranao Thank you!

I’m using CLO3D. I’ll see how to achieve this in CLO.

its best practice to export from clo3d as fbx then import in blender to export as glb, blender makes the best gltf for threejs.

1 Like

So I guess I should import it to Blender, then do double-sided materials and disable back face culling, then export. Thank you!

1 Like

That doesn’t look like the typical Z-fighting artifacts to me. Are you using DRACO compression by any chance?

How would you explain the square artifact area in the shirts right chest/shoulder, which moves along as the model is rotated? This seems to me to be somehow “geometry-aware”, which I would assume to run counter to the compression theory? :thinking:

The square is a kind of virtual template for me to put Team Badge (when my skill is up to it later :-))

1 Like

Camera near set 1, because if set 0.01 will be z-fighting from small distance.
Into renderer can set logarithmicDepthBuffer:true.
Into material maybe like for Decal geometry add polygonoffset, depthTest, depthWrite: false.

const decalMaterial = new THREE.MeshPhongMaterial( {
map: decalDiffuse,
depthTest: true,
depthWrite: false,
polygonOffset: true,
polygonOffsetFactor: - 4,
} );
1 Like

Z-fighting usually has directional banding, like parallel lines that run perpendicular to the direction of depth:

This video doesn’t demonstrate that behavior. It looks more like random noise without direction. But I’ve also seen this before when using DRACO compression. I had compressed the UV coordinates too much, leading to neighboring UVs sharing the same coordinates. This gave me broken texture interpolation with noisy texture sampling, kinda like the video. Anyway, that’s my hunch, at least. I’m not 100% sure. Maybe it’s all the triangles fighting each other in different directions?

@charleslcso Any chance you can share the .glb file so others can take a look at its geometry? Do you know if the file has been run through any compression algorithms?


I’m checking in CLO3D whether DRACO is used. Takes a bit of time as I’m new to CLO.

Sure, here it is: 52.6 MB file on MEGA

1 Like

1 Like

Thank you!

Yeah, all online editors don’t show the artifacts…

I guess our threejs editor code is the source of the problem.

1 Like

Choosing a higher camera.near value or lower camera.far could help if this is a depth buffer precision issue. Those values need to be tuned to your content.


Tested here three.js webgl - GLTFloader

1 Like

Nope, I was wrong :frowning: . It was z-fighting of randomly-dispersed vertices that created that randomized noise pattern. It wasn’t the UV compression that I originally suspected.

@charleslcso I tested your mesh on the three.js editor and your layering problem should be fixed if you make your camera’s depth range a bit narrower. Something like:

camera.near = 0.1;
camera.far = 100;
camera.updateProjectionMatrix ()

when u export it in clo3d reduce the poligon counts, or do retopology in blender, that much poly causes lags on low end devices.

1 Like

I cannot express how thankful I’m to everyone who helped me here! Thank you all very very much!

In our editor, we used just camera.near = 1, and the artifact is gone!



Hi! Have you tried to convert glb to gltf with the facebook binary tool ?