Revit families, FBX and OBJ — what to send and how to package it.
| Format | Notes |
|---|---|
.rfa | A Revit family. The best input by a distance — it carries types, parameters and material assignments, so the configurator and the specification readout come out of it for free. |
.txt | A type catalogue, uploaded alongside a family. Not a model on its own. |
.fbx | Geometry and materials, no types or parameters. Options can be defined by hand afterwards. |
.obj | Geometry, with materials if an .mtl comes with it. |
.zip | Any of the above with the files that belong to it — a Revit family with its type catalogue and textures, or an FBX or OBJ with its textures and .mtl. VUE looks inside and routes on what it finds. |
.adsklib | A Revit material library, imported into your material library rather than as a model. See materials. |
FBX and OBJ import is a plan feature. If your plan does not include it the upload page only offers Revit families.
Upload the family as it is. You do not need to open it, purge it or prepare it — VUE reads it directly.
Two things make a noticeable difference to the result:
Finish becomes a good label; Param_07 becomes a bad one. You can rename them in VUE afterwards, but starting from the right name saves the step.A type catalogue is the .txt sitting next to a family that lists its types and their parameter values. Revit uses it so a large family does not have to carry hundreds of types inside the file.
If your family has one, upload it. Without it, VUE only sees the types embedded in the .rfa — which for a catalogue family is often a single placeholder. This is the most common reason for “my family has 40 sizes but VUE only found one”.
The catalogue also supplies parameter types — that a column is a length in millimetres rather than free text. That is what lets VUE sort a size dropdown numerically instead of alphabetically, and recognise a material column as something that should be shown as swatches.
A mesh file has no types and no parameters, so it arrives as a single default type. That is fine for a product with one configuration, and if you want options you can define them by hand — duplicate the type, then add a control and give each type a value. See types and the configurator.
Export with metres or millimetres as the unit and the model roughly at origin. VUE frames the model on load, so scale errors show up as a product that is correct on screen but wrong in AR, where real size matters.
Revit does not embed bitmaps. A material stores its texture as a path relative to a texture library root — something like 1/Mats/Plate_1.png — and only Autodesk’s stock libraries exist on the conversion machine. So a family using your own textures converts with those materials as a flat colour: right in Revit, grey on the web.
Select the image files alongside the `.rfa` in the upload picker. They are sent with the family and searched before the stock libraries, so your Brick.png wins over a stock one of the same name. An .adsklib can be sent at the same time; the two do not compete.
Send the images under the names the materials reference. If a material asks for Brick_Red.png, the file must be called Brick_Red.png — the folders it sat in on your machine do not matter, but the filename does.
The conversion report says how many of your images were found and used. A material still showing flat after an upload means the name did not match what Revit asked for — check the appearance asset in Revit for the exact bitmap name.
An FBX references its textures by path — a path on the machine that exported it, which does not exist here. So an FBX uploaded on its own converts without them.
Either:
.mtl for an OBJ) and upload the zip — the reliable option; orEither way the names must match what the model references. A texture called oak_diffuse.png will not be found by a model asking for Oak_Diffuse.PNG on a case-sensitive server.
This works differently depending on how you publish, and the difference matters.
From the Revit plugin. Publishing a family VUE already holds replaces that model in place: same address, same embed, and everything you set by hand comes with it — renamed option axes, material overrides, per-type presentation, hidden parts, visitor options. Your live embed picks the new model up with nothing to repoint.
Through the studio. An upload always creates a new model with a new address, even of a file VUE has seen before. Your settings stay with the old model; the new one starts from what the file says. So you either repoint your embed at the new model, or delete the old one first and re-upload if you want to keep the name.
If you have spent real time on a model's parts, materials and presentation, that is the argument for publishing from the plugin rather than uploading by hand.
Either way, settings are stored against stable keys rather than against the converted output, so within a model they survive the family being converted again. If a type disappears between versions, VUE keeps your settings for it and shows them as orphaned rather than deleting them silently. A type that is new appears with its raw name for you to relabel.