Working with Large Models
Large models are the single most common source of "VRGS feels slow". The frustrating part is that slow has at least five different causes, and the fix for one makes another worse. Decimating a model does nothing if the problem is texture memory. Generating LOD does nothing if the problem is that picking is slow. Buying a bigger GPU does nothing if the model is streaming off a network drive.
This guide is about finding out which problem you have, and then fixing that one.
If the model has just arrived and has never been cleaned, start with Preparing a Model for Interpretation. A model full of degenerate triangles and duplicate vertices is slow for reasons that no display setting will fix.
Work out what is actually slow
Before changing anything, decide which of these describes your problem. They have different answers.
| What you see | What is probably wrong | Go to |
|---|---|---|
| The view stutters while you rotate or pan, but is fine when still | Too much geometry drawn per frame | Too many triangles |
| The view is slow even when nothing moves | Textures or effects, not geometry | Too much texture and Turn off what you are not using |
| Everything is fine until you click on the model | Spatial index, not rendering | Picking and interpretation are slow |
| Detail pops in late as you navigate | Streaming, not raw performance | Streaming and tiles |
| VRGS uses all your RAM and then crawls | Residency and how much is loaded | Memory |
| It was fine yesterday and is slow today | Something in the project changed — a new dataset, or the wrong GPU | When it was fine yesterday |
Two quick measurements are worth taking before you start:
- Triangle count. Select the mesh and read it from its properties. A few million triangles is comfortable on most machines; tens of millions needs the techniques below; hundreds of millions needs tiling.
- Which GPU is doing the work. Open Task Manager → Performance while VRGS is running. If the integrated GPU is busy and the dedicated one is idle, nothing else in this guide matters until you fix that — see Graphics Settings.
Too many triangles
There are three different answers here and they are not interchangeable.
| Technique | What it does | Cost | Use when |
|---|---|---|---|
| Decimate | Permanently removes triangles | Detail is gone for good | The model is genuinely more detailed than the work needs |
| Level of Detail (LOD) | Keeps the full model, draws a simpler version when far away | Disk space, one-off processing | You want full detail up close and speed at range — most cases |
| Tiles | Splits the model into pieces that load and draw independently | Restructures the model | The model is too big to hold in memory at all |
Level of Detail
Right-click the mesh → Optimization → Level of Detail (LOD) → Generate.
VRGS then builds progressively simpler copies of the mesh. As the camera moves away, it swaps to a simpler one. The switch is driven by average triangle size on screen: when the current level's triangles shrink to about one pixel, the next level takes over. Choosing the threshold this way is what stops LOD changes from visibly "popping".
To see it working, switch on Wireframe in the triangulated mesh group properties and navigate towards and away from the model — the triangle density visibly changes at each transition.
Optimization → Level of Detail (LOD) → Remove deletes the layers again.
Decimating, remeshing or otherwise editing the geometry after generating LOD invalidates the layers — you have to generate them again. Make LOD the final step of preparation.
Tiles
Right-click the mesh → Convert To → Tiles.
Tiling splits one mesh into many independent pieces, each with its own geometry and its own level of detail, loaded only when it is on screen. This is what makes very large models workable: VRGS never has the whole thing resident.
Tiled models carry a LOD Factor property — a scaling factor on the distance at which each tile refines. Lower values switch to coarser tiles sooner, which is faster but shows the change more; higher values keep detail further out at the cost of frame rate. Leave it alone unless you have a specific problem.
Streamed 3D-tile services (Cesium 3D Tiles, ArcGIS I3S/SLPK) have their own equivalents. I3S datasets add I3S LOD Scale Factor, which divides the per-node pixel thresholds published in the dataset, and I3S Fallback Pixel Diameter for nodes whose LOD metric is missing or invalid.
Too much texture
A model can be modest in triangles and still bring a GPU to its knees if it carries several gigabyte-scale textures. Symptoms: the view is slow even when completely still, and slowness scales with how much of the model is visible rather than with how fast you are moving.
- Check the texture, not the mesh. A 30-million-triangle mesh with one 8k texture is usually lighter than a 5-million-triangle mesh with forty of them.
- Prefer shared textures over per-tile atlases. When converting to tiles, VRGS asks whether to build a texture atlas per tile. Keeping the shared textures is normally the better answer — an atlas per tile multiplies total texture memory.
- Bake the texture to vertices (Textures → Bake to Vertices) if you only need the colour for context rather than for detailed interpretation. Per-vertex colour costs no texture memory at all.
- Hide the texture-heavy layers you are not interpreting on. See below.
Turn off what you are not using
Several display options are free-looking but expensive. All of these are in the Display Properties panel.
| Setting | Cost |
|---|---|
| Enable Shadows | Ray-traced on the GPU. Genuinely expensive, and only works on the Vulkan view with a ray-tracing-capable GPU. |
| Enable Ambient Occlusion | Hardware-traced rays every frame, independent of shadows. |
| Bloom, Procedural Clouds, Time of Day Sun | Cosmetic full-screen work. Fine on a fast machine, the first things to turn off on a slow one. |
| Eye-Dome Lighting / Curvature Shading | Cheaper than shadows, but still per-pixel. Worth keeping — they often let you turn textures off and still read the structure. |
| Full-Resolution Tiles While Interpreting | Forces tiled models to maximum detail while you interpret. Accurate picking, but it defeats LOD exactly when the model is under load. Turn it off on a very large model. |
The cheapest performance win of all is not drawing things: switch off datasets in the project tree that you are not currently working with, and save the combinations you use as scenes so you can get back to them.
Memory
Two commands on the mesh and point-cloud context menus control what is loaded.
- Optimization → Load Into Memory makes the object fully resident instead of streamed. Faster to work on and to interpret against; costs RAM proportional to the object's size. Some operations require it, which is why they grey out until you run it.
- Hide (Keep in Memory) on the item menu is the counterpart: stop drawing an object without unloading it, so showing it again is instant. Use it for the model you keep switching between, and a plain visibility toggle for one you will not need again this session.
If VRGS is using all available RAM and paging to disk, no rendering setting will help — reduce what is resident, or tile the model so it does not have to be.
Streamed online tiles are separate again: their memory budget is
Max Cache (MB) under Cesium 3D Tiles → Memory & Performance, with a local
disk cache of roughly 1–2 GB under %LOCALAPPDATA%.
Picking and interpretation are slow
If navigation is smooth but clicking on the model is not, the problem is the spatial partition tree, not the renderer. Every pick, snap, intersection and interpretation query goes through it.
Right-click the mesh → Optimization → Rebuild Partition Tree.
Rebuild it after any significant edit to the geometry — decimation, cleaning, merging or a coordinate conversion all leave the old index describing a model that no longer exists.
Two other things to check:
- On a very large tiled model, Full-Resolution Tiles While Interpreting makes picking accurate but slow. It is a genuine trade-off, not a bug.
- The Basic Interpretation tools pick against whatever is visible. Hiding datasets you are not interpreting on makes picking faster as well as rendering.
Point clouds
Point clouds have their own level of detail with per-region frustum culling, so a large cloud does not need converting to anything — but it does respond to being thinned.
| Command | What it does |
|---|---|
| Filters → Voxel 2D | Keeps one point per X-Y cell. Good for ground/terrain clouds where vertical density is wasted. |
| Filters → Voxel 3D | Keeps one point per 3D cell. The general-purpose thinning filter. |
| Reduce Overlap | Removes the redundancy where scan positions cover the same ground several times. Often the biggest single win on a multi-scan survey. |
| Clip Range | Discards points beyond a range from the scanner — usually the noisy, sparse ones. |
| Operations → Generate Level of Detail (LOD) | Builds the cloud's LOD layers. |
| Reload Original | Undoes all of it and starts again. |
Eye-Dome Lighting deserves a special mention for point clouds: it makes an un-coloured or thinned cloud far more readable, which often means you can work at a lower point density than you thought.
Streaming and tiles
If detail arrives late rather than never, you are tuning streaming, not performance. The Cesium 3D Tiles section of the display properties has the controls, and the trade-off runs in one direction:
- For the sharpest result on a fast machine and connection: lower Quality (Screen-Space Error), raise Max Cache (MB) and Max Concurrent Downloads.
- For the smoothest experience on a slow link: raise the screen-space error and switch on Preload Ancestors, Preload Siblings and Prevent Holes, so something is always drawn while the better version loads.
Frame Budget (ms) caps how long each frame may spend uploading newly arrived tiles. Lower it if the view hitches while tiles stream in; raise it if you would rather they appeared faster.
Navigation aids (OpenGL view)
The 3D model's Display menu carries three options aimed squarely at large models:
| Command | What it does |
|---|---|
| Filter on Move | Draw a decimated version of the scene while the camera is moving, and the full version once it stops. On by default — it is why navigation stays responsive on a model that is heavy when still. |
| Distance Filtering | Stop drawing geometry beyond a distance from the camera. Switching it on also switches Filter on Move on, and sets the cut-off from the project's own extent. |
| Auto Set Centre | Automatically re-centre the view on new objects and polyline interpretations as they are created. Not a performance setting, but on a big model it saves a great deal of navigating. |
They are handled by the OpenGL view only, so they have no effect in a Vulkan view (the default). The Vulkan view's equivalent is the per-object LOD and tiling described above, which works whether the camera is moving or not.
The renderer
VRGS renders through Vulkan (the default) or OpenGL. Both are fully supported, but they are not identical:
- Vulkan is the default, is required for VR, and is where ray-traced shadows, ambient occlusion and the post-processing effects live.
- OpenGL handles a few commands the Vulkan view does not, and can be worth trying if you hit a driver-specific rendering problem.
Change it in Project Properties → Advanced & Diagnostics → Use Vulkan
Renderer, or from the command line with -vulkan / -opengl.
The renderer setting takes effect the next time VRGS starts. It does not switch the live 3D view.
When it was fine yesterday
- Windows moved VRGS to the integrated GPU. The most common cause by far after a driver or Windows update. Check Task Manager and set VRGS to High Performance — Graphics Settings.
- A driver update. Both directions happen. Note which driver was good.
- The project grew. Something imported since is now being drawn every frame. Switch datasets off one at a time to find it.
- The project database has bloated. Lots of editing and deleting leaves dead space. Set Vacuum On Next Reload in Project Properties and reload.
- The data is on a network drive. Streaming a large model over a network share is slow in a way no setting fixes. Copy it locally.
- An AI or analysis job is running in the background. Check the messages panel.
Quick reference
| Symptom | First thing to try |
|---|---|
| Stutters while navigating | Generate LOD; check Filter on Move is on |
| Slow when still | Turn off shadows and ambient occlusion |
| Slow with one specific model | Check its triangle count and its texture count |
| Slow to click on | Rebuild Partition Tree |
| Runs out of memory | Convert to Tiles; unload what you are not using |
| Detail arrives late | Raise Screen-Space Error; enable the preload options |
| Point cloud is heavy | Reduce Overlap, then Voxel 3D |
| Slow on a laptop | Confirm the dedicated GPU is being used |
See also
- Preparing a Model for Interpretation — cleaning and sizing a model before it reaches this stage.
- Hardware Requirements — what the hardware can reasonably be expected to do.
- Graphics Settings — making Windows use the right GPU.
- Display Properties — the full reference for every setting mentioned here.
- Project Properties — renderer, mesh storage and database maintenance.