Note : This guide requires the Rhino 9 WIP. This is a work in progress meaning that it is meant for testing and should not be used for project critical production work. The Rhino 9 WIP is available to anyone that owns Rhino 8.
USD files can now be used to encode information for the exchange of BIM information to common workflows. Geometry, Layers, Blocks, UserData and Object Properties will now be transmitted into USD data.
For developers, the RhinoUSD project is open source codebase written in C++ .
Rhino Objects to USD
Here are the changes to USD format and how Rhino objects are encoded into USD. Based on support for USD geometry in general, all geometry objects are exported as mesh objects.
Default Layer - This is the name for the Root prim of the USD file that all other data fits under.
Model Name - This is an optional prim. This can be used to make composing multiple USD files easier.
Include User Strings from Rhino into USD
Userdata on objects within Rhino with the Key:Value pairs. This information is saved on the prims as CustomData in the USD. It is meant to be used for all sorts of metadata that can be explored in other USD viewing apps.
Block Export options
Blocks definitions and their instances are now exported with the USD.
Block Handling Options
Blocks as Separate files - This is the most efficient way to save a USD file. Each Block will create a separate USD file. These files will then reference each other. This can improve the performance of USD viewers.
Ignore - Ignore
Embedded - Block definitions are included within the USD file. This makes it easy to move the file around, but is less efficient for viewers.
Scripting Export to USD
USD export can be scripted in RhinoCommon in Python or C# using code similar to this sample:
using System;
using System.IO;
using Rhino;
using Rhino.FileIO;
using Rhino.Collections;
var desktop = Environment.GetFolderPath(Environment.SpecialFolder.Desktop);
var options = new FileWriteOptions()
{
WriteSelectedObjectsOnly = true,
SuppressAllInput = true,
SuppressDialogBoxes = true,
};
// Block Options
// SeparateFiles = 0
// Ignore = 1
// Embedded = 2
var dictionary = new ArchivableDictionary();
dictionary.Set("blocks", 2);
dictionary.Set("root-layer", "RootPrim");
dictionary.Set("model-name", "MyModel");
dictionary.Set("include-user-strings", false);
var doc = RhinoDoc.ActiveDoc;
doc.Export(Path.Combine(desktop, "usd.usdz"), dictionary);
I’ve tried to export 25 identical blocks to a *.usdz file and it failed until I added a mesh box next to the blocks. Unfortunately I only see one of the blocks and not all instances.
Also the blocks actually contain breps and I’m unsure if I need to mesh the geometry before exporting.
Another issue seems to be whether a block is embedded or linked.
25 identical blocks should create 25 instances, but only one extra external file.
USDZ format is a zipped format. I have not done this, but rename it .zip and see what is inside it.
USDA is an ascii text format
USDC is a binary format I believe.
Both USDA and USDC should have the external blocks showing up in the folder with the main USD.
Meshing should happen no matter if it is the block or not, but I will test that.
The *.usdz file contains just one block when the polysurfaces are not part of the export and just one instance of each block when the polysurfaces are also exported. Colors work nicely.
A small detail: The export options have a default name for Model Name set to ‘test_01’
I would much prefer ‘test-01’ since we with most files the underscore is used to separate different parts of a structured filename. A concatenated file name could be something like this:
Exporting the geometry in my file runs ‘Meshing…’ 699 times, 233 times for each of the three blocks. The resulting file however only contains one pipe and one sphere. I’m using either this viewer or iRhino to view *.usdz files.
I want the file to contain all blocks so I choose Embedded:
Exporting as *.usdz, changing the extension to *.zip and unpacking the file shows a *.usdc file which I’m not sure if it makes sense. Shouldn’t the extracted *.usd? file be human readable?
USDA files are plain ascii and will tend to be larger. But, are human readable.
USDC are binary “crate” files. For faster access and will tend to be smaller.
USDZ is a container for the format in a ZIP structure, used by Apple for 3D and AR applications[3]. There is some streaming and display efficiency with having referenced external blocks with online viewers. So USDz can do this but keep the package as one file.
USD can technically be either ASCII or binary format.
