Do fewer polygons always mean better performance?
No. Materials, textures, transparency, animation, draw calls, hierarchy, loading strategy and the rest of the business page all affect performance. Test the complete experience.
Summary: Model optimization is more than reducing polygon count. Set target devices, spatial scope, key tasks and acceptance conditions first. Then address asset selection, geometry, textures, materials, instancing, hierarchy, tiling, on-demand loading and caching, and retest with the same representative data.
Before changing models, record target devices, browser or client, GPU and memory, network, display resolution, business charts loaded alongside the scene and key actions. A demo on a powerful office computer cannot replace acceptance on an actual showroom controller, standard PC or intranet.
Classify buildings, devices, pipelines, terrain, landscaping, signs and animations as interactive essentials, display-only, simplifiable at distance or unnecessary for launch. Record source formats, coordinates, component properties, update frequency and owners. Compressing without an inventory can preserve invisible detail while removing object IDs needed for sensor-point binding.

A single building or small park can load by building, floor, system and device. Large geospatial datasets call for an assessment of tiling, levels of detail and view-dependent scheduling. OGC’s 3D Tiles standard supports streaming and rendering large-scale 3D geospatial content; Khronos’s glTF specification supports efficient transmission and loading of 3D scenes and models. Confirm whether either format fits the coordinate system, source models, updates and client capabilities.
After optimizing the model, define what loads on the first screen, when distant objects load, whether switching floors releases old assets, whether textures and API responses can be cached, and how failures retry. Charts, video and live data also use bandwidth and memory. Test the complete page, not an empty 3D scene.
| Acceptance item | Test conditions to record | Suggested evidence |
|---|---|---|
| First-screen usability | Target device, network, model and first/cached visit. | Screen recording, timing and network log. |
| Key interactions | Rotate, zoom, locate, switch floors and select sensor points. | Action path and response record. |
| Resource use | Run the complete page over a sustained period. | Memory, GPU memory, CPU/GPU observations. |
| Error recovery | Slow network, failed assets, API timeout and repeated switching. | Error messages, retry and recovery results. |
| Version tracking | Model, texture, application and configuration versions. | Version IDs, change log and delivery inventory. |
Agree thresholds against the project environment. One frame-rate target or load-time figure should not become a universal standard for every digital twin.
No. Materials, textures, transparency, animation, draw calls, hierarchy, loading strategy and the rest of the business page all affect performance. Test the complete experience.
Usually, first select components and attributes, then convert formats, simplify geometry, organize materials and hierarchy, and test on representative devices.
Record at least test device, network, model version, first-screen usability time, interaction smoothness, memory, error rate and response for key actions.
No. Large geospatial content may benefit from tiles and level-of-detail scheduling, but the format depends on coordinates, data scale, updates, devices and technology stack.
How to Choose Among WebGL, Cesium and UE5 for a Digital Twin, How to Accept a Digital Twin Project, Digital Twin Technology Selection Matrix.