I’m working on a converter of .ifc files to .gltf files. It’s working fine, but now, I try to improve the performances, because as you may know, .ifc files can be huge.
So, I use InstancedMesh to do improve it. The issue here, is that I have not the same behaviour with my three.js viewer or with others. When I load the new .glb file, my instanced meshes are not positioned where they need to be, as if the matrix had not been updated.
So, I guess it comes from my loader. I use the loader from Three.js:
import { GLTFLoader } from 'three/examples/jsm/loaders/GLTFLoader.js';
At first I thought it was from the ‘EXT_mesh_gpu_instancing’ plugin of glTF but the loader seems to understand it pretty well. My file is a binary file and is draco compressed. I do nothing special when loading the file except changing materials to a transparent one. Do you have any clue?
The screenshot was done with the current version of the three.js editor. Don’s glTF viewer as well as the BabylonJS sandbox render the asset in the same way.
So basically, I load the gltf file, apply a specific material (shader material with transparency) but I didn’t in this fiddle, and then calculate a wireframe and apply it.
Here the wireframe is red and you can see the issue with the wireframe at the origin of the scene (inside the building). I couldn’t reproduce the issue for the building though, only the wireframe.
Instances of ShaderMaterial are not automatically compatible with InstancedMesh, only build in materials. When using custom shaders, you have to add the respective shader code for instancing by yourself.
Besides, when you rendering wireframes, you render lines which are no instanced meshes anymore.
If you have issues with writing your shader material so it is compatible with instancing, consider to enhance a built-on material with Material.onBeforeCompile() according to your needs.
