IMPORTANT: The McUsd model and the normals test model are now part of the ASWF USD assets repository. Find the updated version of this model in here and the normals test in here. I will leave these old versions of the models and page available here, but will not update it.

Simple USD scene geometry with a variety of UsdPreviewSurface materials applied, for casual material and light testing.

Download this repository and then load the McUsd.usda file in the models directory into your favorite USD file viewer. Or, view the model in your browser through Sketchfab. Or, have an iPhone or iPad? Try out the McUSD USDZ. You'll have to shrink the model down in AR mode (pinch, on an iPhone) - each block is a meter in size!

The "Mc" is for Minecraft, not McDonalds. Short URL for this page: http://bit.ly/gitmcusd

Clockwise from "12 o'clock": diamond block, iron block, gold block, fern, prismarine, sunflower, purple stained glass, rails, chiseled quartz block atop quartz pillar, piston, and in the middle is lava.

The overarching goal is to help the community strive to give similar or the same renderings, as possible. Consistent interpretation of the UsdPreviewSurface material description benefits us all. While, as of August 2022, this description is still a "proposal," numerous companies have implemented it in their systems.

This material test file has a few purposes:

• Help people implementing UsdPreviewSurface material viewers, providing a simple model with some reasonably complex surfaces that can test for common bugs.
• Give examples in the human-readable USDA format to help understanding.
• Note loose areas of the current specification, to help encourage these becoming fully specified.
• Show the state of various implementations of UsdPreviewSurface, in order to determine areas where the specification is not yet followed.

There are more serious efforts at compatibility test suites happening in the long-term in the USD community, e.g., see this video at 23:09 on. My small effort here is to give a simple test scene, now, with some interesting materials, and note some problems seen testing with it. The model is first and foremost meant as an aid in testing and debugging UsdPreviewSurfaces.

You're welcome to send me your own results, or submit as a pull request. I am happy to add to the gallery any test images you generate and notes on them you might have, credited as you wish.

I believe the camera in McUsd has a field of view of 60 degrees horizontally, almost 36 degrees vertically (read from C4D). The reason I'm not entirely sure is that USD uses a more camera-like specification of focal length and aperture dimensions, not FOV that many are used to. Some camera mismatches in testing done below are no doubt due to the application having to make a decision as to which FOV to use for the given viewport.

The two lights included are a sun "DistantLight", Euler angle order ZXY, angles of rotation are X 235 degrees, Y 325 degrees, intensity 30, width angle 1 degree, and a light "DomeLight" with sRGB texture _domelight.png, Z rotate 270, intensity 6. Some applications translate these partially or fully; some provide their own lights instead.

Parts of the UsdPreviewSurface specification are not tested by this model. These include the setting "useSpecularWorkflow 1", and the clearcoat-related, displacement, and occlusion values.

This model was generated by laying down a few blocks in Classic (Java) Minecraft, then using Mineways to export the model to USDA format. The JG-RTX resource pack, released under the Creative Commons Attribution-ShareAlike 4.0 International Public License, is used at a resolution of 256x256 textures for the surfaces. Textures are of four possible types:

• Albedo/Opacity - sRGB color RGBA file with no suffix
• Normal - linear RGB vector directions in tangent space, mapped from (-1,-1,-1) to (1,1,1), suffix "_n.png"
• Roughness - grayscale roughness mapped to 0.0 (smooth) to 1.0 (rough), suffix "_r.png"
• Metallic - metalness, typically binary, mapped to 0.0 (non-metallic) to 1.0 (metallic), suffix "_m.png"
• Emissive - sRGB emissive color, suffix "_e.png"

Make your own: There are hundreds of other Minecraft blocks with PBR texture sets for them, if you want to make your own Minecraft test scene. Make a model in Minecraft, then in Mineways: Open World, select the model, Choose Terrain File terrainExt_JG-RTX256.png, Export for Rendering, set "Save as type" to USDA, uncheck "Custom material" and "Export MDL" (see other options here). You now have a USDA file of your own.

Note: I currently work for NVIDIA. However, I am making this simple USD file as an independent, free test model. Having worked through the UsdPreviewSurface proposal myself for my free program Mineways, I hope this test file will save others time and effort, while also helping to clarify the specification of USD, to widen its appeal and adoption. I would be happy to see a UsdPreviewSurface conformance suite of USD files and images generated by some more knowledgeable source. If there is such a thing, please point me at it.

I was inspired to take a bit of time to make this project due to hearing at SIGGRAPH 2022 about the pickup of USD in open metaverse initiatives and ASWF's USD efforts. More important, the USD Working Group is open to participation by all - calendar. Their openness inspired this effort. In particular, I'm told that the Assets working group is best placed to discuss these issues. This group has also begun making tests for specific features.

First, a summary of my observations on the specification of UsdPreviewSurface and UsdLux, since what follows after is an extensive list of applications tests.

One notable problem with UsdPreviewSurface as of August 2022 is that the "emissiveColor" is minimally specified as "Emissive component." It is unclear whether the color is meant to be specified as the material's on-screen appearance, or meant to be specified in, say, nits. These are actually two questions: 1) how does an object with an emissive color appear when directly viewed? and 2) how does this emission color work with other lights? For the first question, it is simple to say that the emissiveColor should be treated as a fixed color for the surface, the color that is always shown. However, USD has an elaborate camera model, including an exposure attribute, which implies that the appearance of the light should change as the exposure changes.

In McUsd I use a nits interpretation, since that is what worked well with Omniverse. The emissive texture is scaled up by 1000 (nits) by using the texture "scale" input:

    def Shader "emissive_texture"
    {
        float4 inputs:scale = (1000, 1000, 1000, 1)

so that it gives off a reasonable amount of light to surrounding objects. This workaround is unlikely to be the standard way in the future. Also, it works only for textures, not colors. As it stands today, from my black box testing, some (most?) applications seem to ignore this texture scaling factor anyway.

This question of magnitude for lighting is part of a larger question, how physical lights are specified in USD. Currently UsdLux and related light specifications use a film-related relative pair of values, "exponent and intensity", not tied to any physical units. Some applications appear to ignore the intensity setting for lights, I believe in part due to this lack of absolute measure.

The "roughness" input is loosely specified as of August 2022. It says "This value is usually squared before use with a GGX or Beckmann lobe." Choosing the square of the roughness, which is the common usage in the Burley model (see page 14), is the common way to go. GGX is also the common choice, from my experience. The standard setters need to choose, for better consistency among applications. As an example, glTF has chosen roughness-squared and GGX - see that section for their reasons. I would suggest simply lifting glTF's equations and descriptions of their implementation, saving work and also making USD and glTF more compatible.

All this said, I don't have a great test object in McUsd for roughness, one with "midtone" grayscale values that would show any difference in implementations. Due to releasing McUsd, I was happy to learn of this roughness test in the USD Working Group Assets repository. This is great to see! The specification itself would still be good to tighten up.

Mentioning how opacityThreshold should normally be set for cutouts in the proposal would help new implementers and users. A value of 0.0 means that the alpha (transparency) value is indeed treated as semitransparency. An opacityThreshold greater than 0.0 gives a level where the alpha is compared and judged to be fully transparent (if below this value) or fully opaque (if above or equal to this value). This is clear enough, but I suggest that the specification note an opacityThreshold of 0.5 is a common cutoff value. As an example, using an RGBA texture authored for use as a billboard, here is it rendered with an opacityThreshold of 0.01, 0.5, and 0.99. The 0.5 value is, in my opinion, the best render of the three, and about the most logical. A sentence saying so would have saved me hours, when I set it to 0.001 for export originally.

The USD Working Group Assets repository has a nice Alpha Blend Mode Test for UsdPreviewSurface. I am happy to see they point out that opacityThreshold == 0.5 is the "Default" cutout value. Noting this in the specification would help everyone else.

The application of normal textures to surfaces seems a little off by default. Some guidance from the proposal would be helpful; better still, a simple test suite of scenes.

For example, the McUsd.usda model needs to set the bias and scale for every normal texture as follows:

float4 inputs:bias =  (-1,  1, -1, -1)
float4 inputs:scale = ( 2, -2,  2,  2)

Having to negate the second, Y, value in each is confusing. These odd Y values, in fact, get flagged by the usdzip tool if the "-c", check compliance, flag is used (and non-negated Y values do not get flagged):

UsdUVTexture prim </Looks/grass_block_top/normal_texture> reads an 8 bit Normal Map, but has non-standard inputs:scale and inputs:bias values of (2, -2, 2, 2) and (-1, 1, -1, -1) (may violate 'NormalMapTextureChecker')

The normal textures used (created by Jason Gardner with Substance and other tools, and used in Minecraft RTX as-is) seem fairly standard to me, but I am not an expert. However, which way the X and Y directions on the texture are set can be varied, such as with the [NormalMap Online tool]https://cpetry.github.io/NormalMap-Online/, where you can use "Invert" to reverse the direction of any axis. I believe normal maps generated there with "Invert R" then can be used without adjusting the default bias (all -1's) and scale (all 2's).

See the Sketchfab section for how, without these negations of the bias and scale Y values, seems to give upside-down normals. So, this could be an authoring mismatch, that the vertical normal channel Y (green) should have small green values when a slope points along +Y in texture space, large green values when a slope points down. Or, I could be making a mistake myself.

So, I decided to make a simple test scene.

In the unit_tests/cubes_r_normals subdirectory you'll find a test file for checking whether bias and scale for normal map textures are treated properly.

What follows are images generated by various rendering systems, for comparison. I have tried to use the newest version of the software for each package. My focus is running applications on Windows 10.

Note that few images will match perfectly from system to system. Reasons include:

• Lighting is not translated in a compatible manner, or not at all, so is added manually.
• Camera position and orientation not translated.
• The opacityThreshold material attribute is not implemented fully.
• The renderer does not support some reflective materials.
• The renderer does not support emissive materials.
• The renderer supports emissive materials, but the emissive values are too bright/dim.

These various conditions and others will be noted after each rendering, as best as I can determine them. The last problem, emissive material definition, is explained in detail in the Observations section above.

Please note that the purpose of this project is not to show problems in a particular application, but rather for me to see what features there might be confusion on (due to the specification or implementation) and to understand and snapshot the level of progress at this time. Noting problems is not meant as criticism, but rather as things to be aware of if you use a package. Many of the applications have improved their import capabilities considerably in the past two years that I've been sampling them.

The following apps are a snapshot as of August 2022. If nothing else, you'll get a flavor of the wide range of support out there for USD.

The usdview program from the USD Toolset includes a basic hydra GL rasterizing renderer. It's about as basic a render you can make, but it's also the standard, in that it's the renderer Pixar provides. As such, it properly renders semitransparency, cutouts, roughness, metalness, etc.

It is possible to build usdview from scratch, but in that way lies madness (at least for me). Happily, NVIDIA's Omniverse Launcher provides a pre-built USDView that I can simply install and run. I tested with version 0.22.8. (BTW, if you want other USD tools in the toolset, I found NVIDIA's USD Pre-built Libraries pretty easy to get going; joining the developer network is free.)

Load procedure: File -> Open. Press F11 to toggle on the hierarchy view (if not already visible). Open up the "root" by double-clicking on it. Select the "Camera" and right-click, then pick (at the bottom) "Set As Active Camera". You can hold down Alt and use the mouse buttons to rotate, pan, and dolly.

As expected from a basic rasterizer, shadows, reflections, and emitted light from surfaces are not rendered. Note: here and further on, you can click on the image to see the full resolution version, which is scaled down to fit on this README page.

By default, USDView adds a light "at the eye", which is shown in the rendering above. This additional light can be turned off via View -> Lights -> Camera Light. I have not figured out how to turn off the XYZ axis helper, which shows up here as the vertical green line along the edge of the diamond block at the back. Ignore that line...

Without shadows, it is a little difficult to tell if the DistantLight in McUsd.usda is being used. By pressing "F11" (or View -> Toggle Viewer Mode), we can see that the DistantLight and DomeLight have been read in (the camera has not). These lights can be toggled off by right-clicking and selecting "Make Invisible". Doing so, the DomeLight appears to have no effect, neither to direct illumination nor as a background environment map.

The lava light source seems oversaturated. As discussed in "Observations" above, the emissive texture is scaled up by a factor of 1000. Removing this scale factor, which is done in the file McUsd_unscaled_lava.usda, the lava looks more reasonable:

From what I can see, the emissiveColor is used to shade the lava. More experimentation could be done here, e.g., removing the diffuseColor texture and setting the diffuseColor to white or black, to see the effect. I've done this experiment and get the same rendering, showing that the emissionColor, when present, is used instead of the diffuseColor. However, it seems better to have the emissiveColor's role in rendering specified, rather than needing to reverse engineer how the effect is implemented in USDView. I believe this program should not be held up as an oracle and final arbiter for how attributes are applied. Better, for me, would be the explicit set of equations used to compute local shading, such as how glTF does it.

I focused on Omniverse Create as the target for this USD test file, as Mineways is a "connector" for the Omniverse system, and Omniverse is free and far along in its rendering of UsdPreviewSurface. This is important to understand: this McUsd test file is tailored to look particularly good in Omniverse. Some application had to be targeted, as a starting spot. Doing so helps point out the differences between its interpretation of materials and lights compared to other applications. No application is particularly "right" at this point.

Load procedure: drag and drop McUsd.usda file into the viewport of Omniverse Create.

There are a few renderers in Omniverse. All results are from Omniverse Create 2022.

By default, the "RTX - Interactive (Path Tracing)" is used. This renderer is progressive, shooting more and more frames of rays and blending these results in. Here is the render after 512 accumulated frames (which is overkill):

One notable difference with USDView is that, in these Omniverse renderings, the prismarine block (the blue stone block) does not have as strong specular highlights in this and other Omniverse views. I think the USDView version looks more convincing, but do not know which is correct.

The lava is an emitter and affects how the other objects are illuminated. Here is a rendering with the sun and surrounding dome light off:

To use a different renderer, in the upper left corner of the viewport is a light-bulb icon with a renderer name. Choose the renderer from this dropdown list. The next renderer I tested was the "Omniverse RTX - Real-Time" renderer, which includes some ray tracing elements:

Note simplifications occur, such as opaque shadows for semitransparent objects. One important render setting dictionary entry currently used to improve the result is:

bool "rtx:raytracing:fractionalCutoutOpacity" = 1

which trades speed for better-quality semitransparent results, such as with the purple stained glass block.

The "Omniverse RTX - Accurate (Iray)" renderer uses the Iray ray tracer. Here is the render after about 520 accumulated frames:

Differences with the interactive version include less color on the semitransparent glass block on the left. Though not obvious, the lava is a bit dimmer. In the "Accurate" render a bit of a caustic can be seen on the grass to the right of the gold block. Running for 500+ frames made this caustic less noisy and more visible.

In the McUsd.usda file are some render settings at the top that are specific to Omniverse:

        double "rtx:post:tonemap:cameraShutter" = 10
        double "rtx:post:tonemap:filmIso" = 1000
        bool "rtx:raytracing:fractionalCutoutOpacity" = 1
        token "rtx:rendermode" = "PathTracing"
        double "rtx:sceneDb:ambientLightIntensity" = 0.0

Turning on the fractionalCutoffOpacity favors quality over speed for the Omniverse real-time renderer, providing better semitransparency. The fourth line specifies using an Omniverse path tracer on load. The last line turns off ambient lighting.

This leave the two camera exposure settings. I wanted to have emissive surfaces' effects still be visible even with any scene being in full sun. The lighting I chose are 30 for the sun, 6 for the domeLight, with a somewhat more real-world 1000 (nits) for emissive surfaces. To compensate for the low sunlight and domeLight values, I give Omniverse higher exposure settings: 1/10th of a second shutter, 1000 ISO (and f-stop of 5.0, the default in Omniverse). If these two post:tonemap exposure settings are removed, the Sun should be set to an Intensity of about 1550, the DomeLight to 310, and the emissive surfaces (the two lava materials) should have inputs:scale to 53000 instead of 1000. I provide this file as McUsd_no_exposure.usda. This file tends to blow out the appearance of lava even more in other applications, such as USDView.

Please note that these settings are used as of September 2022, but their use and names in Omniverse may change over time.

Note also at the start of the file the line:

metersPerUnit = 1

By default USD uses centimeters as its units, i.e., the value is normally 0.01. Minecraft blocks are 1 meter "in real life", so this setting makes it so that all mesh descriptions are in meters. This looks cleaner and saves a lot of extraneous zeroes in the USDA file.

Load procedure: make a zip file that consists of McUsd.usda and the McUsd_materials in the "models" directory and upload it to Sketchfab. Modifications: the directional light was set to 250 degrees, the camera FOV to 30, and the camera view itself manually adjusted to about match.

The Sketchfab rendering can be directly examined in a browser.

Sketchfab does not translate the camera or lights; I repositioned the view to attempt to match the original camera's, though neglected to change the field of view from 45 degrees to 60 degrees in the original model.

It uses rasterization and related techniques for interactive rendering, so giving typical limitations: the lava does not emit light, the glass block does not cast a shadow, true reflections are not generated for shiny surfaces. There are some interesting specular highlights on the glass block that are not visible in the Omniverse renderings.

Initially, I noticed that the prismarine block looks as if it is lit from below, which is wrong. The light is coming from above and should not illuminate the bottom edges of the stones:

However, I got the exact same flipped-vertically normals when I uploaded "McUsd_yflip_normals.usda", which should look different (and wrong). Since these are the same, what is happening is that currently Sketchfab is ignoring the scale and bias values set for the normal maps. It assumes the normal textures use a DirectX mapping, not an OpenGL mapping.

I manually edited my original, uploaded file, in Sketchfab (tediously) setting the material for every block to use the "Flip green (-Y)" property for the normal map. This corrected file fixes the normals for the model:

See the "Observations section earlier for more on normal map texture scaling.

Sketchfab lets you download different translations of your model (note: not all translated forms instantly appear in the download list when you first upload a version; be patient, as they compute the download USDZ form eventually). I downloaded the corrected Sketchfab USDZ translation - click that link on an iPhone to view it. The camera position set in Sketchfab is exported. The default Sketchfab light sources are not. From what I can tell, the emittance texture scaling on the lava is removed, for good or ill.

On Safari and Chrome (and perhaps other browsers), if you are using an iPhone or iPad and click on a ".usdz" extension file, the file displays in an viewer called AR Quick Look. Some examples are here.

I made my own USDZ file with the usdtool. You can view or download this McUsd.usdz. Click that link on an iPhone and you'll be able to view it (other phones and non-Safari browsers will just download the file instead; if you know how to hook the usdz file to immediately view, let me know).

The iPhone viewer has two modes: AR and Object, shown at the top. "Object" lets you view the model in isolation. In this mode, one finger rotates, two finger pinch dollies (aka "zooms", but not really) the camera in and out. There appears to be no way to change the center of focus. Here's an example:

Understandably, the camera setting is not used in either mode. If you look very closely, in only the the Sketchfab USDZ exportthere is some "ghosting" around the sunflower, an area around it where the cut-away parts of the texture should have no effect, but instead leave an extremely faint white trace. This ghosting is not visible in my own McUsd.usdz file, so is some unknown interaction between Sketchfab's exported USDZ and the iPhone's viewer. Also with the Sketchfab USDZ export the upper right part of the sunflower drops out, and other parts disappear from different views, e.g.:

Overall the fidelity is good when viewing my version of the USDZ file. The lava's emission texture is scaled up, leading to the bloomed view seen.

This problem is not visible in the USDZ file I created, for some reason. The lava looks better in Sketchfab's because Sketchfab ignores the emission texture scaling in the McUsd file, so its translation does not have this scaling.

Try AR mode (usually the default). Because this model is actually to scale, the blocks are each 1 meter across by default, so the model is likely much larger than where you are. You made need to first move your phone or tablet around so that it understands your environment before placing the model. After this, use a two-finger pinch gesture to shrink the model down and make it fit your environment. Two-finger twist lets you rotate it. One finger lets you move the model horizontally. Here is the scene shrunk to about 10% and viewed in place, using "AR":

(And, yes, socks with sandals rules.)

If you download the McUsd USDZ file and double-click it on a Mac, the Preview app will show it:

Lights and camera are not translated. The content looks good, with no z-buffer problems with cutouts. I did notice with the Sketchfab USDZ translation there was a problem with the display of some grass triangles, which looked dark. I didn't explore further.

Autodesk open-sourced their USD browser viewer. Demos and Github repository here. It's a bit of a challenge to build (I failed; turns out the build doesn't quite work for Windows yet, as of 8/31/2022, but that should change soon). Happily there's a site where you can simply drag and drop a USDZ file onto the page and view it.

Sadly, there is some bug in this viewer that makes it so that the McUsd USDZ does not display its textures. I did find this viewer displayed the (mostly-translated) Sketchfab USDZ file with textures, so used that for testing.

Dropping the Sketchfab USDZ translation onto Autodesk's USDZ test page gives this result:

The camera and lights are not translated. The main artifact is that cutout billboards make parts of the sunflower and fern disappear. Rotate the view and the sunflower cutouts will make parts of the purple transparent glass block disappear. My guess is that opacityThreshold is not being used to help control whether the z-buffer is written to for cutouts.

There is a related three.js demo repository, and their material implementation is easy to examine.Pierre-Olivier Nahoum has made an open-source USDZ Loader wrapper based on this viewer.

Dropping the Sketchfab USDZ translation onto Nahoum's USDZ test site gives this result:

The render is a bit washed out compared to Autodesk's original, but that's just a matter of adjusting the lighting in the code. Again, the cutouts hide parts of the plants and from a different view make the transparent block disappear. Also, the lighting on the (randomly rotated) grass tiles noticeably varies. My guess is that there might be some small normal map or other texture problem with the grass, though it's not clear to me whether it's a problem with the data (perhaps the texture contains unnormalized normals?) or the viewer itself. I've seen this sort of patterning before with the grass texture's random repetition (which is why I include grass in this scene), though usually the differences are more pronounced (and the buggy viewers are now fixed).

In testing with the unaltered Sketchfab USDZ file, I found that these viewers appear to pay attention to the normal map bias and scale, at least for this one (simple Y flipped) test.

NOTE: At this point, the testing for all the packages that follow are based on the McUsd files from early September, which had a small bug. In testing, I found that some of the normal maps were poorly translated by Mineways, which is fixed in the latest version of the McUsd model files. These renormalizations are not a huge deal (I think...), and I don't have infinite time to retest, so the images that follow may differ slightly from what you will see with the latest McUsd.usda file. Or, more likely if you retest, the vendor has improved their renderer - this happens pretty regularly.

Being free and open source, Blender is easy to test. I tested the bleeding edge (as of today) Blender 3.4.0 USD version.

Load procedure: Start Blender and delete the cube, as usual. File -> Import -> Universal Scene Description. If you use an older version, see this issue for the setting needed on the USD Importer dialog to properly build the shaders.

Choose Camera.001 in the hierarchy control in the upper right, then right-click in the viewport and, from the Object Context Menu that appears, choose the topmost option, "Set Active Camera".

Choose "Viewport Shading" in the upper right corner of the viewport. The result:

Blender added a light on import, at the bottom of the hierarchy list in the upper right. Turn it off by clicking on the eye icon to the right of this "Light" object to turn it off. The Sun in McUsd.usda is imported by Blender, but is too dim. Find it in the hierarchy, and below select the lightbulb icon "Object Data Properties" and change the Strength to 2.0. This gives:

The Shadow property for the Sun is checked in the properties, but it doesn't appear to cast a shadow, unlike the "Light" in the original image. This may be some error on my part.

Using F12 to render the image, I get:

This experimental work-in-progress looks good overall. The cutouts do not yet cast shadows. The normal map texture on the prismarine block appears to be reverse in both X and Y, with the bumps appearing to push in instead of out. This effect is more visible if you click on the image above, to see the original, higher resolution version. In further testing, Blender currently appears to ignore the bias and scale values set on the normal texture map.

You can install the Unreal Editor by running the Epic Games Launcher and then selecting "Unreal" in the upper left column, "Library" along the top, then the "+" to the right of "engine versions". Note that the 5.0.3 editor needs 114 GB of disk space. Images here were generated with Unreal Engine 5.0.3, using the Beta Version 1.0 Usd Importer plugin.

Load procedure: To install the native USD plugin, choose "Edit -> Plugins" in the menus at the top. Search "USD" and you'll find two (or four, if the Omniverse Connector is installed - both plugins evidently can co-exist, unlike Maya or Max). Enable the USD Importer by checking its box and restart the editor, as directed. See here for more help.

To load In Unreal Editor create a New Project. Choose the Games template on the left, Blank, and for Project Defaults in the lower right you could check the Raytracing box. After you click "Create" the editor may take a few minutes to compile shaders. You'll get a scene with some chairs, etc. I go to the Outliner in the upper right and delete all these StaticMeshes.

Use File -> Import Into Level... You should see "*.usd" in the lower right of the dialog that appears (if you don't, the USD plugin is not enabled). Choose wherever you like to put the imported USD assets. Hit "Import". Mouse scroll to dolly out of the scene.

For my renders I deleted the given Light Source and added a distant light source, angle Y=235 and Z=325, to match the McUsd.usda's lighting, which does not import. I also used the default SkyLight and BP_Sky_Sphere in the scene, turning off much else. The imported camera has the right position, but I could not figure out how to set its field of view to be narrower (Focal Length and Aperture were not taken from the McUsd.usda file, forcing a FOV of 92.67 degrees), so I dollied in.

The result, after positioning the camera view manually:

One minor flaw is simply a rendering artifact, that cutouts appears to be sorted from back to front, leading the stem of the sunflower to be rendered in front of the sunflower's flower. Also, the cutouts do not cast shadows in this mode (they used to cast shadows for the whole billboard in 4.27, so this is an improvement, IMO).

In the upper left area of the viewport is a "Lit" setting for the View Mode. Clicking and changing this to "Path Tracing" gives the following:

There is some auto-exposure system in place that I have not figured out how to turn off. The lava is actually emitting light in path tracing mode, which can be seen by turning off the other lights in the scene:

No intensity adjustments were needed for the lava emission values or scaling (I can't say whether texture scaling is actually used; I did not see it in the user interface for the lava materials). Auto-exposure is occurring, as the lava itself is brighter than above.

Overall USD import has improved considerably in UE 5.0. The main problem I see with the path trace is that the semitransparent purple stained glass block is not transparent, unlike the "Lit" version. This may be a regression. In Unreal Editor 4.27.2, for example, the path trace looks like this:

Houdini Apprentice has a trial, and is free for personal use. I tested with Houdini 19.5.303.

My instructions for loading a USD file are here. Following these, here is the basic Houdini GL render:

It's hard to tell with this model and view, but using the cubes_r_normals test, it turns out this renderer (Karma and Storm are fine) has a left/right reversal of the normal map direction.

Changing "Persp" in the upper right corner of the viewport to the Karma path tracer, we capture the lava emitter's effect:

A bit noisy by default, but the number of rays shot can always be increased. This view shows the Sun has been nicely translated, with no adjustment on my part.

The DomeLight has also been translated to some extent (it does not act as a surrounding environment), and affects the rendering if turned off:

Finally, the Hydra delegate Storm render:

Maxon's Cinema 4D has a 14-day trial. Loading McUsd.usda is simple: drag and drop the file into the viewport. In the "USD Import Settings" change the "Lights" setting to "Legacy Intensity" (the default is "Nit", a physical unit, but this does not work properly with the Sun in McUsd). Once loaded, you can then pick the camera imported by clicking in the top middle of the viewport where it says "Default Camera" and choose "Camera". Doing so with C4D version R26.107, you get this:

The camera is properly translated. There are some texture mapping problems, but these are more easily seen in the next render.

By default the Sun does not cast a shadow. Open up _Simple_Material_Test in the Objects hierarchy control in the upper right, then select the Sun, then under General at the bottom change Shadow to Area. Press Control-R to perform Render View:

The diamond block has a color texture mapping problem, with the faces of each block showing a thin gold band a quarter of the way across the face - compare to other renderings here. There are normal mapping mismatches with the prismarine (wrong scale), and with the piston and chiseled quartz block (normals flipped upside down). The quartz pillar shows only 2 "vertical pillars" instead of 6.

On further investigation, the DomeLight in the scene washes out the effect of normal maps in the interactive renderer. I did not find a control to turn down its effect. You can delete the DomeLight, or toggle off its effect by clicking on the two dots, turning them red, in the Objects hierarchy menu. The interactive render is then:

The Render View render doesn't look as good - the DomeLight helps there:

This render more strongly highlights the normal-map texture mismatches, especially on the prismarine. I think what might be happening is that they are interpreting the bias and scale factors for these textures as UsdTransform2d values, not as values that change the normal values themselves. It would explain the reversals and rescalings. But, that’s just a guess.

Maya 2023 comes with a USD import plug-in built in: mayaUsdPlugin.mll. It is enabled by default. You can see it by going to Windows -> Settings/Preferences -> Plug-in Manager and searching on USD. Newer versions of the USD plug-in are available for download and installation. Look carefully to make sure the one you are downloading is for your "year" of Maya, e.g., Maya2023 in my case. I am using Version 0.19.0 for the tests that follow.

Another plug-in enabled is mtoh.mll, the Maya to Hydra plug-in that lets you access Arnold and other renderers as Hydra delegates (if that meant nothing to you, just ignore it). This updates along with the USD plug-in, so is also at 0.19.0 for these tests.

Load procedure: To load McUsd.usda, use File -> Import..., and load McUsd.usda.

The camera imports. To use its view, in the list of viewport menus (those just above the viewport) choose Panels -> Perspective -> McUsd:Camera.

To see textures, click the "Textured" icon (a checkered sphere) in the long row of icons just above the viewport. It's about in the middle. You should now see textures, though dimly. Turn on lighting by clicking the icon just to the right, "Use all lights" (a light bulb). Things will be blown out to white. Best is to adjust the exposure. In the same row of icons, further to the right, is "Exposure" (a camera shutter), set to 0.0. Change this to -12.0. You should see this:

This is a simplified view in Viewport 2.0, so it is unclear whether the normal textures are missing or are just not rendered. The sunflower has a cutout ordering problem, with the stem in front of the sunflower's flower. There is a faint yellow square around the sunflower's flower.

Other renderers are available in the "Renderer" menu just above the viewport (not to be confused with the Rendering or Render menus above it). The experimental Hydra GL and experimental Hydra Arnold renderers gave black views, Arnold alone gave a dim purple view of the meshes.

I experimented with changing the Sun's intensity instead. Reset the exposure to 0. In the Outliner to the left, open the defaultLightSet and select McUsd:Sun. In the McUsd:SunShape tab dialog on the right, change the Intensity from 50000 (I don't know where this number came from, as the sun in the file is set to 30; that said, if I examine this same light in usdview, it says 50000. Maybe it's a default?) to 10. This gives a different view, with the lava blocks overblown:

However, Hydra Arnold then gives this:

It flickers among some various low-res views. Definitely experimental, and I'm sure it will improve.

Some of the many viewers, alphabetically:

• Activision
• Unity

CC-NC-BY-SA

Textures from the JG-RTX resource pack, which has the same license.

Email me at erich@acm.org.