I’m loading a gltf model (from Cinema4D with baked materials) using the standard GLTFLoader method from the docs/examples. Looks exactly how it should in threejs.org/editor and gltfViewer, but I’m getting strange depth issues with the materials (or maybe vertices) when I load into three.js.
I’ve tried a the latest r125 - same issue. It seems to happen on all models (that ship with the master files) so I’m wondering if I’m missing something obvious, maybe enabling depthTesting on materials (though I have tried a couple of ways and nothing seems to work).
Hi Mugen. Sure, it’s only a test model I threw together to test the C4D > Three.js workflow but here they are (might not be positioned or scaled properly)
work in my case , i ve just changed material cause i wasnt able to see if there is a problem with original ( too light cause your emmisive input )
so i have imported in blender change color to green , and i ve seen your house is clean and have the same result in web … ( dont forget to reset origin of your object ) house2.glb (16.9 KB)
Thanks for the replies guys, it’s obviously user error but good to know the model exporting/loading works, thanks for that!
I’ll start from one of the examples files that works and see how I get on. If I’m still missing something I’ll let you know. I’ll do my best to solve it first though.
Right I’ve finally got it all working but with some interesting findings/anomalies - maybe there’s a simple explanation for them.
This code works fine, the model loads perfectly with no artefacts, but only when I work in very small scale in Three.js - scaling my model down by 0.00009:
loader = new GLTFLoader();
loader.load( 'models/house/house.gltf', function ( data ) {
gltf = data;
const object = gltf.scene;
// scaling my models right down removes artefacts
const modScale = 0.00009;
object.scale.set( modScale, modScale, modScale );
scene.add( object );
}, undefined, function ( error ) {
console.error( error );
} );
However if I try and work in a larger scale in Three to closer match my scale units in C4D - where I’m working in centimetre scale - so less scaling down of the models, I get this sh*t-show:
which is easily fixed by enabling the logarithmic depth buffer, but is there any overheads to either approach; Either Scaling everything down by 0.00009x, or enabling the logarithmic depth buffer and working on a larger and more manageable scale?
I can’t see any difference in performance between either approach but my scene is too lightweight at the moment I’m guessing.
It seems that your modeling has an issue if you need for a simple house model a logarithmic depth buffer. I suggest you author the model in real world sizes, then things will work out of the box.
I’m not sure I follow @Mugen87. do you mean change my modelling world scale to meters for example - real world scale? Then my models would need even greater scaling down in Three?
Is there an overhead for using logarithmic depth buffer and working at larger scales? Would be handy to know before I start modelling the whole environment.
In three.js (and most other engines) one world unit is considered to be 1 meter. A single-family house with let’s say 150 square meters living area should have a AABB with a size of maybe (10,7.5,10).
That’s great that’s a metric I’d much rather work in, it’s just at the moment my model is 60x50x40cm, but when I try and render it at it’s native size with the camera positioned accordingly and a further camera.far limit I get all the crappy artefacts (with logarithmic depth buffer disabled), but scaling it down to minute size it renders fine.
So if I were to work in meters so my model is even larger, I’m only assuming I’d have the same issue or worse and would have to enable logarithmic depth buffer?
I won’t push my luck on this thread, I’ll do some experiments later and see what’s what - I’m relatively new to a modelling + Three.js workflow so just picking up the best practices.
