I’m working with Rhino 8 + V-Ray and using V-Ray Generic materials with external textures (albedo, bump, normal, HDRI) that are correctly linked from a project textures folder.
What I observe is:
Rhino seems to create its own viewport/preview texture copies for V-Ray materials
These appear as support files and trigger the warning “You are attempting to embed XX MB of support files” on save
This effectively duplicates texture data (once for V-Ray, once for Rhino)
As a result, the .3dm files become very large, much larger than expected
If I delete the Rhino textures, the viewport preview breaks, but the warning disappears
After reopening the file, Rhino recreates the textures and the warning comes back
What I would like:
Keep Rhino viewport previews working
Keep V-Ray textures external / linked
Avoid embedding or duplicating V-Ray textures, and avoid large .3dm file sizes
Is there a recommended workflow
or setting to prevent Rhino from treating V-Ray textures as embeddable support files, while still keeping viewport previews?
Thanks in advance for any clarification or best practices.
@wim Any idea what’s going on here? I’m running into issues with large textures in Rhino 8 + V-Ray: even with relatively simple 3D models, the file size grows extremely quickly once textures are involved. For example, a model that’s around 120 MB becomes over 1 GB after including textures, and saving takes noticeably longer.
What you’re observing is true, but not entirely correct. When you use complex V-Ray materials—especially those with color corrections or procedural textures—Rhino is not capable of displaying them accurately (or at all) on its own. In such cases, V-Ray samples the textures by running them through its render pipeline to produce a result that more closely matches the final render appearance.
This sampling process takes time and consumes system resources, as it involves evaluating the full texture graph. The sampled textures are then saved to disk and made available for Rhino to display in the viewport. Sampling is performed once for a given set of texture parameters and will only be repeated if any of those parameters change.
Depending on your settings, the sampled textures may or may not be embedded in the .3dm file, although by default they are. That said, Rhino itself is not duplicating anything— it is V-Ray that copies and modifies the source textures in order to display them correctly in the viewport.
By default, source textures are sampled “as-is,” meaning that a 4K source texture is sampled into a 4K display texture. You have full control over this behavior via the vrayTexturePreviewSettings command.
The following options are available:
BakeResolution – The size, in pixels, of the sampled textures.
MatchBitmapResolution – When enabled, BakeResolution is ignored and textures are sampled at their source resolution. This means 4K textures remain 4K after sampling, which can result in gigabytes of image data.
ImageQuality – JPG compression quality for the sampled textures.
The most common reason a .3dm file grows uncontrollably is the sheer number and size of textures. You can disable texture embedding, in which case V-Ray will sample the source textures only when necessary. This keeps the .3dm file smaller, but it also means that textures may take a moment to appear in the viewport, since they must be generated on demand. Additionally, you’ll need to manage the external texture files if you move the .3dm file to another machine.
Keep in mind that Chaos Cosmos materials and HDRI environments are not imported as black-box assets like Cosmos geometry. As a result, those materials’ textures may be sampled and potentially embedded in the .3dm file when required.