Remote Desktop and Virtual Machines

VRGS runs over Remote Desktop and inside virtual machines, but only when the session has a real GPU with the vendor's own driver behind it. Almost every report of "VRGS will not start remotely", "the 3D view is black" or "it is unusably slow on our VM" comes down to the same thing: the remote session replaced the graphics card with something that cannot do 3D.

This page explains how to confirm that in about a minute, and what to change.

What VRGS needs

The 3D view is the only part that is fussy. Everything else — importing, interpreting, exporting, the trees and panels — is ordinary Windows software and behaves normally in any remote session.

The 3D view needs one of:

• Vulkan 1.2, with a driver that registers a Vulkan driver (an ICD), or
• OpenGL 4.3 (Core)

A generic display adapter provides neither. That includes the Microsoft Remote Display Adapter used by RDP, the Microsoft Basic Render Driver, and the synthetic video adapters in Hyper-V, VMware and VirtualBox when no GPU has been passed through.

VRGS tries to rescue the situation on its own

At startup VRGS checks whether Vulkan can actually work. If it cannot, VRGS falls back to OpenGL for that session rather than failing. The saved setting is left alone, so installing a working driver restores Vulkan on the next launch. You will see this in the Messages panel:

[WARNING] Vulkan is not usable on this machine - using the OpenGL renderer for this session. Update the graphics driver to restore Vulkan.

That warning is not itself a fault. It becomes one when OpenGL has no real GPU behind it either — which is the usual case in a bare remote session.

Find out what you actually got

Do this first. It replaces all guesswork.

Open the Messages panel, or the log file at:

%LOCALAPPDATA%\VRGeoscience\VRGS\VRGSDebug.LOG

Look for the line beginning Render thread GPU:. It names the vendor, the renderer and the GL version the 3D view is genuinely running on.

What you see	What it means
Render thread GPU: NVIDIA Corporation | NVIDIA RTX A4000 | GL 4.6.0 NVIDIA 551.86	A real GPU. If VRGS is still slow, the problem is elsewhere — see Working with Large Models.
Render thread GPU: Microsoft Corporation | GDI Generic | GL 1.1.0	No GPU driver in the session at all. The 3D view cannot work.
... | Microsoft Basic Render Driver | ...	Windows' software fallback (WARP). It renders, very slowly, and can draw incorrectly.
... | llvmpipe | ... or softpipe	A software rasteriser. Same conclusion.

VRGS calls this out explicitly when it detects it:

[CRITICAL] WARNING: the 3D view is running on a SOFTWARE renderer (...). Your graphics card is not being used, so 3D will be slow and may display incorrectly.

These are the other lines worth searching the log for:

Log line	Meaning
the Vulkan loader (vulkan-1.dll) is not installed	No driver on the machine offers Vulkan at all.
vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)	A driver is present but predates Vulkan 1.2. Update it.
the loader is installed but reports no Vulkan-capable GPU (0 physical devices)	The classic VM and Remote Desktop signature: the loader is there, a GPU is not.
Failed to initiate an OpenGL 4.3 context	The OpenGL fallback failed too. Nothing will render until the session has a GPU.

Remote Desktop to a physical workstation

This is the most common case: the machine has a good graphics card, but VRGS behaves as though it does not.

When you connect over RDP, Windows disconnects the console session and gives the remote session its own display adapter. The physical GPU is still in the machine; your session simply is not attached to it.

Three ways out, in order of how well they work.

1. Use a remote tool that attaches to the console session

The most reliable fix, and the one that needs no policy changes. Tools that mirror or stream the existing console desktop — rather than opening a new RDP session — leave the real GPU driving the display, so VRGS sees it normally. Screen-sharing and remote-support tools, and the GPU-accelerated streaming protocols sold for remote graphics work, generally behave this way.

A headless workstation still needs a display

A machine with no monitor attached may fall back to a basic adapter even at the console. Leave a monitor connected, or fit an inexpensive display emulator dongle (sometimes sold as a "headless plug"). Some GPU vendors and remote tools also install a virtual display driver that does the same job.

2. Allow the GPU into RDP sessions

On Windows Server with a GPU installed, enable:

Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Remote Session Environment → Use hardware graphics adapters for all Remote Desktop Services sessions

This lets RDP sessions render on the physical adapter rather than the Microsoft Remote Display Adapter.

The driver decides, not just the policy

Whether OpenGL and Vulkan are actually exposed inside an RDP session depends on the graphics driver. Professional workstation drivers (NVIDIA RTX professional and Quadro, AMD Radeon Pro) have long supported this; consumer drivers historically did not, and the behaviour has changed across driver versions. Do not assume either way — connect, start VRGS, and read the Render thread GPU: line. It tells you what you got.

3. Keep VRGS off the remote session entirely

Where the work is genuinely interactive 3D interpretation, running VRGS locally against data on a network share is usually a better experience than any remote protocol. Projects, meshes and point clouds can be opened from a mapped drive or a UNC path.

Virtual machines and virtual desktops

A VM works with VRGS when — and only when — a GPU has been made available to the guest and the guest runs the GPU vendor's driver.

Setup	3D view
GPU passthrough (a whole PCIe card assigned to one VM)	Works. The guest sees a normal GPU.
Partitioned vGPU — NVIDIA vGPU/GRID, AMD MxGPU, Intel GVT-g	Works, given a suitable profile and enough frame buffer. Choose a profile with the VRAM your models need.
GPU cloud instances — Azure NV-series, AWS G-series, GCP GPU VMs	Works. These present a real GPU with a real driver.
Hyper-V, VMware or VirtualBox with the default synthetic display	Does not work. No Vulkan, no OpenGL 4.3.
The "3D acceleration" checkbox in a desktop hypervisor	Not sufficient. These emulate an older OpenGL feature level and do not reach 4.3.

Two things to check on a VM that should work:

• The guest has the vendor driver, not the hypervisor's basic adapter. In Device Manager the display adapter should name the actual GPU.
• The vGPU profile has enough VRAM. Small profiles carve out a fraction of the card. Treat the profile's frame buffer as the VRAM figure in Hardware Requirements.

Licensing on a VM or virtual desktop

Node-locked licences bind to the identity of the machine. A virtual machine's identity is not as fixed as a physical one, which produces two recurring problems:

• A cloned, re-provisioned or non-persistent VM looks like a different machine. The licence does not follow it, and each new instance can consume another activation.
• Changing the virtual NIC or the VM's board serial changes the identity. The on-premises licence server derives its fingerprint from the CPU ID, the motherboard serial number and the first MAC address, so altering any of them breaks the binding.

What to do about it:

Situation	Approach
Persistent VMs, one per user	Node-locked is fine. Pin the MAC address and SMBIOS serial in the VM configuration so they survive a reboot or a migration.
Non-persistent VDI, pooled desktops	Use cloud-floating, or an on-premises RLM server. Node-locked activation cannot survive a machine that is rebuilt at every logon.
Retiring or rebuilding a VM	Deactivate first: Home ribbon → Update → License Status → Deactivate. That returns the seat. Destroying the VM without deactivating leaves the activation stranded.
Air-gapped VMs	Offline activation works normally — see Licensing Options.
Non-commercial site deployment from an image	Bake the VRGS_LICENSE_KEY environment variable into the image; VRGS activates itself on first launch without a prompt.

If an activation is stranded on a VM you no longer have, contact VRGeoscience support to have the seat released.

Performance, once it works

A session with a real GPU still behaves differently from sitting at the machine.

• The 3D view is the worst case for a remote codec. Rotating a large model is full-motion video at full screen. Reducing the remote session's resolution helps far more than any VRGS setting — do not run a remote session at 4K.
• Latency changes how navigation feels. Rotation and zoom lag the mouse. That is the protocol, not VRGS.
• Prefer streamed over resident data on a shared GPU. On a vGPU profile with a modest frame buffer, Load Into Memory on a large mesh can exhaust the VRAM you have been given. See Working with Large Models.

Non-persistent desktops re-download everything

Two caches are rebuilt from scratch when a profile or an image is discarded:

Path	Contents
%LOCALAPPDATA%\VRGS\CesiumCache\tiles.db	The online 3D-tile and basemap cache, roughly 1–2 GB
%ProgramData%\VRGeoscience\models	Downloaded AI and machine-learning models, several GB

The tile cache is per-user, so it is wiped with the profile. Redirect or persist it in the desktop image if your users work with online tiles; otherwise it is re-downloaded at every logon.

The model cache is machine-wide by default, which is the more useful of the two when building an image: download the models you need once while preparing the image, and every user of that image gets them without a download. If VRGS cannot write to %ProgramData% it falls back silently to a per-user %LOCALAPPDATA%\VRGeoscience\models, so check the permissions on the %ProgramData% folder if models keep being fetched again.

What will not work remotely, at all

Feature	Why
VR	Needs an OpenXR headset physically attached to the machine running VRGS, plus the Vulkan renderer.
GNSS field navigation	Needs a receiver on a serial port on the machine — see GNSS Field Navigation.
Ray-traced shadows and the path tracer	Need a ray-tracing-capable GPU in the session. A vGPU profile may not expose ray tracing even on a card that has it.

Working through it

1. Start VRGS and read the Render thread GPU: line in the Messages panel or in VRGSDebug.LOG. If it names a real GPU, your graphics stack is fine and the problem is something else.
2. Software renderer, or GL 1.1? The session has no GPU. On RDP, use a console-attaching tool or enable the hardware-adapter policy. On a VM, arrange passthrough or a vGPU profile.
3. Real GPU, but the Vulkan warning appears? The driver is too old or too incomplete for Vulkan 1.2. Update it. VRGS runs on OpenGL meanwhile, and some features are Vulkan-only.
4. Need to force OpenGL deliberately? Uncheck Project Properties → Advanced & Diagnostics → Use Vulkan Renderer, or start VRGS with -opengl. Both persist, and both take effect at the next launch.
5. Licence refused after a VM rebuild? The machine identity changed — see Licensing on a VM or virtual desktop above.

See also

• Hardware Requirements — what the machine needs, GPU included.
• Graphics Settings — choosing the right GPU on a multi-GPU machine.
• Why Is This Greyed Out? — including which commands need which renderer.
• Licensing Options — activation, deactivation and licence types.
• On Premises Server Setup — floating licences behind a firewall.
• Working with Large Models — performance once the GPU is working.