USD for 3dsMAx 0.5 has been released. You can see how it has progressed in the What’s new section of the official documentation. Even tho it is still in a beta stage, it is actually pretty production-ready in terms of both features and stability.
I think it is a good time to review what USD for 3dsMax can do at this point. Also, we probably need to have some time to understand what USD is, how different it is compare to other data exchange formats. USD is a little bit complicated animal. Then, we also need to see what kinds of new workflow it would bring.
So, I decided to have a few blog post about the current status of USD in 3dsMax. I originally just try to have one post. Then, it was getting too long. I decided to split to multiple post. This is #1 – Export.
So, what is USD?
USD stands for “Universal Scene Description.” It is a system for encoding scalable, hierarchically organized, static and time-sampled data, for the primary purpose of interchanging and augmenting the data between cooperating digital content creation applications. USD also provides a rich set of composition operators, including asset and file references and variants, that let consumers aggregate multiple assets into a single scenegraph while still allowing for sparse overrides.
It is a bunch of C++ libraries and specs for making a scene assembler. This is why it is called “Composition Engine”. Yes, it also provide data exchange format. But, that’s just part of USD. Pixar even said it is not just another file format. NVIDIA Omniverse is an implementation of this library as an application.
Therefore, utilizing USD is not exactly same as using Alembic or FBX. Yes, you can just simply use as another data exchange file format. But, you can also take advantage of new possibilities to improve your workflow(not necessarily reinvent your workflow). USD world is big and complicated. Keep in mind that this is made by Pixar for Pixar. There are a lot of Pixar-ness in it which is not necessarily align with a 3dsMax users. You can start with learning some concepts and terms.
You don’t need to feel pressure of “I must use USD because it is the future”. It has its own pros and cons. In the end, it is just a tool, you just need to utilize as you need.
Lastly, I must admit that I’m not an expert on USD at all. I just learned while beta testing USD for 3dsMax. Just take my post with a grain of salt.
Export
USD is a scene assembler, so we gonna have some data to assemble, right? USD actually can read some existing file formats such as Alembic and Obj. But, even Alembic is not enough to store all the data that USD need to store. Also, it wouldn’t be 100% efficient for new framework to use legacy formats since they were developed before USD developed. Therefore, USD also provides a very comprehensive data exchange format.
It supports mesh with various attributes, transform animation, deformation animation, topology mesh changing animation(like Alembic), and also skin and morpher(like FBX). It can also store lights and cameras with more parameters, shader trees and more. Think it as Alembic + FBX and more. BUT! Remember it is still all BAKED CACHE. It can’t store a live character rig. It can only store baked transforms. Like it or not, this is the only way to achieve Interchangeability. No, you can’t rig in Maya and use it in Max. It will never happen. No, you can’t keep the modifier stack from Max to Maya. It will never ever happen.
Since 3dsMax is primarily a “Digital Content Creation” program,The development focus for USD for 3dsMax has been more on generating USD(Export) than consuming(Import). In this article, I’ll go over where we are at for exporting USD data. You can find the official document here.
Geometry
- Obviously you can export your mesh/geometry.
- Mesh Format – You can choose to export as Poly(Convert to Polygons) or Trimesh(Convert to Triangles) or as is in the scene(Preserve Existing). If you wan to export everything as you see in the viewport, use Convert to Polygon to since USD doesn’t care hidden edges.
- You can choose to Bake Offset Transform(You shoudl always) and Preserve Edge Orientation by converting curved faces in your scene to trimesh.
- Normal – can be exported As primvar or As attribute or choose not to export(None)
- Vertex Channels – As you can see, all UV and vertex color channels can be exported as PrimVar. One cool thing about this implementation is that you have complete control over which channel to export with what name and type.
Wait a second. Let’s take a break here. I have very important thing to mention. When you import/export between application using a data exchange format, both import and export need to work together. Even tho your exported data is perfect, if importer is not good, you will NOT get all the data correctly.
When the formats were very simple like .obj, it was easy since it carried very limited data such as static mesh, normal and single uv. FBX was more complicated format. But, it worked ok because it was closed format and everybody had to use the the same SDK.
When Alembic came out, all hell broke loose. It can have all kinds of data. But, it didn’t have much of spec or standard about what the data means. For example, Alembic only has one official uv channel. Other uv can be saved and loaded using arbGeomParams. But, as the name suggest, it is arbitrary. There is NO agreement on what would be uv channel 2. There is no spec for what vertex color channel name should be. Every DCC have their own way of export the same data! The data is there for sure. But, either it can’t be loaded or loaded incorrectly. I still have PTSD about this because I had to deal with this as a pipeline guy. When 3dsMax dev worked on Alembic in 3dsMax 2019, I had to make sure to have at least some control over it. So, when I heard about USD, I had high hopes. Maybe, maybe, finally, we might have a solid spec. Well, I was wrong. The situation is not any better. I don’t think there is even a standard name for uv. It has been changed a few times for USD for 3dsMax, and currently the name is “st”. See? The above image was not that long ago, it was “st0”!
This is why the custom primvar setup option is important. At least, you make USD file that other side is expecting.
- Material ID – will be exported as GeomSubset.
- Wireframe color will be exported DisplayColor primvar
- Non-renderable object(Renderable object property off) exported and Bones/Biped/CAT will be exported as Guide purpose which means they do not render, and by default are not shown in USDView.
- usd_purpose/usd_kind – custom attribute to set purpose and kind
- Instanced geometry will be exported as instamced.
Camera
- Standard (Physical, Free and Target cameras), 2 types of Vray cameras, and 4 types of Arnold camera are supported
- FOV, Focal Length/Lens Breathing(Focal Length)
- Projection Type(orthographic / perspective)
- Clipping Planes/Range
- Target Distance(Focus Distance)
- Horizontal / Vertical Aperture/Zoom(Horizontal / Vertical Aperture)
- Lens Shift(Horizontal / Vertical Aperture Offset)
- Shutter
- Exposure
Light
- Photometric Light
- Color, ColorTemperature(value and on/off), Exposure, Intensity, Normalized on/off, Shadow(color and on/off), Shape, Diffuse. Specular
- Photometric SunPositioner exports to USD including sun orientation, mapping color and intensity.
Shape/Spline
- If Enable in Viewport/Rendering is off, spline will be exported as UsdGeomBasisCurves.If the option is on, it will be exported as UsdGeomMeshes.
Helpers
- Exported as Transform node
Animation
- Node Transform animation – usual moving objects
- Vertex Deformation – Non-vertex count changing mesh animation like point cache
- Changing Topology animation – Vertex count/topology changing messh such as meshed fluid.
- Skin/Morph Targets as USDSkel – just like FBX skin/morph export
- Spline animation including vertex changing spline
Material
- USD Preview Surface – Dedicated USD Preview Surface material
- Physical, PBR Material (Metal/Rough), PBR Material (Spec/Gross) will be exported as USD Preview Surface
- Bitmap map, OSL BitmapLookup, OSL UberBitmap are supported.
- MaterialX shadier as reference -If object has MaterialX material assigned. The file path will be referenced. This means whatever change you made in 3dsMax material editor will NOT be exported unless you save the file.
- I know you have some questions about Material in USD. I’ll talk about it in the next post.
Stage
- Stage is a composed USD scene. In 3dsMax, you can have a Stage object which containes the content of a USD file. l explain about this when I explain how to consume USD in 3dsMax.
- USD Stage objects or prims are exported as USD references. It is similar to nested scene xref. It is very similar to a nested scene xref.
- Because the Stage objects are exported as a file reference. Any in-memory change or animation setting change in the scene will NOT be reflected in the exported USD file. Same as MaterialX.
As you can see the most major data types for any traditional productions are already all supported. There are a few missing ones. But, I’m sure they will come in the future. But, how about all the 3rd party plugin data? What if I need export something right now? Well, lucky for you. There is very easy way to make own exporters.
PrimWriter, ShaderWriter and Chasers
3dsMax USD SDK allow you build your own PrimWriter(scene nodes), ShaderWriter (Materials) and Chasers using either C++ or Python to hook into 3dsMax USD Exporter.
Prim writer/Shader Writer
Prim writer will execute for each Max node at export-time. So the exporter iterates through all the objects to export, and each object it checks the current list of registered prim writers for the first prim writer that says it supports exporting an object. If one is found, that prim writer will export that specific node into USD and other prim writers are now skipped.
In English, you have control over how to export each object type(class). For example, if your renderer dev is slow to support USD and you need to export the renderer’s camera right now. You can do with a little bit of Python. In SDK, there is a a sample prim writer,SpherePrimWriterSample, which export 3ddMax sphere as USD sphere with a radius value.
Shader Writer does same thing for materials.
Chaser
Chasers happen at the very end after all prim writers are done, and contain a mapping of the original Max nodes and the resulting USD prims. This allows you to append data to things already written.
For example. the current version of Exporter can’t export objects properties or user properties. But, in SDK sample, there is already an exporter does that, UserDataExportChaserSample.
If you Chasers, it will show up in “Plug-In Configuration” drop down.
File Format
.usd/.usdc/.usda
USD supports Binary(.usdc) and ASCII(.usda) format. The recommend USD workflow is having a lot of granular USD files and composite them as UsdStage. This is an image from Pixar.
It is recommended to use .usdc for data heavy asset data and .usda for composition. Remember 3dsMax USD exporter support exporting loaded Stage objects as references?
.usda is also very useful when you need to debug your export.
USDZ
.usdz is zip-compressed package file format. To export as usdz, just give .usdz extension in the Exporter.
USDView
3dsMax USD includes USD python binding and various pre-compiled toolsets. One of them is USDView. They are here. C:\ProgramData\Autodesk\ApplicationPlugins\3dsmax-usd-2024\Contents\bin
If you just drag and drop an USD file into, C:\ProgramData\Autodesk\ApplicationPlugins\3dsmax-usd-2024\Contents\bin\RunUsdView.bat file. But, this file has to be in this folder. If you run form anywhere, put this line as a .bat file. Then, you can put this batch file anywhere and drag and drop an usd file to view.
"C:\ProgramData\Autodesk\ApplicationPlugins\3dsmax-usd-2024\Contents\bin\RunUsdTool.bat" usdview %1
This utility is a god send for troubleshooting. You can see everything in the USD file. I’m not sure if you really want this much tutorial, But, NVIDIA has USDView tutorial here.
Another very important use of this utility is that it serve as a ground truth of your USD file. When you send and receive a data exchange file, the importer and exporter both need to work properly. When something is not right, it could be a fault of exporter or a fault of importer. When I use Alembic, I have had to deal with so many “Why can;t 3dsMax read this alembic? 3dsMax alembic is not good”. Well, guess what? In most cases, the problem was the exported alembic file. Either it was not following the needed naming convention or just badly organized data. Sure, it would re-imported correctly to the program which exported the file. That doesn’t mean that the file is sound!!! With this USDView utility, you can examine every single aspect of the USD file and find what the problem is. If this utility can’t read the USD file. Then, the file need to be re-exported. Period.
What’s left
I can say that, as of today with 0.5.1.1, USD already can do more than Alembic. Also, Arnold and VRay already started to support own exporters, and the Prim/Shader Writers and Chaser even allow you to implement custom exporter easily. So, you can certainly use 3dsMax for authoring USD data in production. Just try it.
So,what’s left in terms of export?
- Velocities channel – This need support from 3dsMax dev.
- Animated Custom Data – We already can export static values for custom attributes, user properties and other node properties for artist with Chaser. But, we arew waiting animated vale export support from 3dsMax dev. We need UI forartists.
- Variant Set – This is a unique concept of USD for switchable reference(Variant). It could be low/high res or different combination of parts or different materials. You can actually do this with Prim Writer if you need. But, we will need UI for artists.
- PointInstancer – This also can be made with Prim Writer if you need. But, we will need UI for artists.
OK, I guess this is it for export. I’ll talk about Stage object in next post.