QSViewer - A novel way to view BIM models on the web.
Construction 3D models face unique challenges from a computer graphics perspective.
- They require high memory.
- They demand a powerful GPU.
- They exhaust your CPU processing loop.
QSViewer addresses these challenges while providing a lightweight, web-based viewing experience that changes context as you move around. The demo piece is a 800 MB 3D model of a highrise residential development, containing 78k modelled objects, 6 disciplinary layers, and 37 Million triangles, that runs at 60 FPS.
Features:
- BatchedMesh for Draw Call optimization
- Instancing of high frequency meshes
- LOD Control
- Accelerated spatial querying with three-mesh-bvh
How it works:
The engine determines the closest objects to the camera, using a spatial search tree. These objects represent a small subset of the total, and change as the user moves around. The rest of the time, the engine loads the lightweight facade and nothing else.
2 Likes
Feedback is appreciated. Memory usage of the scene is currently high.
Your GLB files on GitHub don’t appear to be optimized, just for a test maybe try either of the following:
- Load all your GLB files into three.js editor, export it as GLB and then use gltf report website to load this exported GLB file, run the available script from the menu and then export it again to GLB format but select DRACO compression.
- Load your GLB files one-by-one into gltf report website, run the available script from the menu and then export each to GLB format but select DRACO compression.
This should reduce the number of draw calls and make files smaller.
1 Like
Thank you so much for the response. I’ll definitely try compressing the files upstream.
I’m also creating an intermediary object to store vertex and instance data for the BatchedMesh object. That’s probably consuming way more memory than it needs to- do you know if there’s any way to also save this data in the GLB file?
I wouldn’t really know about that part.
You need to be careful about grouping geometries into BatchedMesh since it requires identical attributes. Maybe check each of your geometries for present attributes and then decide how to group them.
If i try running your GitHub page then it throws an error stating that some geometry is missing uvattribute in order to be added to BatchedMesh of that particular group - wrapping the code in try-catchwill skip these errors but will show a partial view of the building.
Just ignore my previous post, your GitHub page seems to be functional as it is.
The issue I mentioned appears to be caused by either DRACO compression or by optimizing those files on gltf report website.
If you are to try to optimize your files then either try meshopt compression or no compression at all or modify the script on gltf report website - one combination might just work.