Adventures in 3D — A Cinema 4d to iOS AR Quicklook / USDZ Workflow

We love USDZ and the AR Quicklook functionality within iOS. We also love Cinema 4d. However, it’s not easy to create a USDZ file directly from Cinema 4d. What follows is a detailed, tech-heavy, walk through of my process creating a Stern Pinball spinner USDZ, starting with Cinema 4d.

A quick note:

USD is a technology created by Pixar. Therefore, it should be no surprise that Maya supports USD better than other tools. Blender, too, has great support for things like glTF and PBR rendering, and is probably an overall better tool for this technology than Cinema 4d. For Blender specific information, I recommend you follow Blender Sushi Guy.

The Plan

I want to create a USDZ file for AR Quicklook on iOS using the 3D tool I am most familiar with: Cinema 4d. It’s most efficient for me to construct the geometry in C4d, do some texture mapping in Body Paint, and deal with the available outputs and conversion utilities to create the final package.

My goals are:

• To take advantage of Augmented Reality by constructing the object at real-world scale.
• To make the object more engaging with animation.
• To explore the process needed to generate and apply PBR materials to the model.
• Avoid using online conversion tools like Vectary or Sketchfab.

The object

I want to create something that has fairly simple, repetitive, mechanical movement. It should have a few different parts and textures. I love pinball, so a pinball part was an obvious choice.

I chose a spinner from a modern Stern Pinball machine.

In doing some quick googling, I found these solidworks files by Joe of http://homebrewpinball.blogspot.com/. Using these will save some time, and will prove that we can adapt a cad-like file format to USDZ through conversion.

Cinema 4d Studio can import solidworks files natively. Alternatively, you can export the .SLDPRT files to .stl files through Fusion 360. Sketchfab outlines that process here.

Cinema 4d can import .stl files. At that point it’s just a matter of re-arranging the objects and ensuring they are set to the correct scale. In Blue below, I’ve ensured that the project is set to 1mm, and in Green the overall Y-dimension is approximately 60mm.

We’ll address the magenta section in the Animation portion of this post.

Tips for success

• You must nest your objects under a single root node for scale and animations to work correctly. In this case, highlighted in Red, stern_spinner is a null object with the other geometry nested below it.
• That root node determines the position of the object in AR. You want it to be positioned at 0,0,0 with your geometry emanating from it. More than likely, you will need to fiddle with the axis to get it to look right.
• While the screenshot does not show it, I would recommend only a single level of child nodes. At some point in the conversion process (possibly to glTF?), I ran into trouble with animations when there were several levels of objects.
• Your nodes should also be named to be easily converted (and recognized): no dots, spaces, special characters, etc…
• Maybe this is obvious, but you should make all your objects editable. It could help to have a ‘dynamic’ version of a file then save it as a flattened version of the file where conversions are made if you are making edits to the geometry during the conversion process.

Conversion

Now that our polygons are in place, we want to see it on a device.

Looking through Apple’s USDZ video (the only formal ‘documentation’ on the technology at this time), the only tool they mention is usdz_converter, and that it supports .obj or Alembic (.abc) as input.

.obj files do not support animation, so that’s out. Luckily, Cinema 4d has a built-in Alembic (.abc) exporter. That should work.

The conversion roadmap will look like this:

.SLDPRT →.stl→.c4d→.abc→.usdz

The .abc export options I use are captured here:

The important choices are File Format and Scale. Changing the other options didn’t seem to have much impact in my use case. The animation options are important, but we’ll deal with those further down.

Now that the .abc has been created, I just needed to run Apple’s conversion tool. Nelson Chang does a great job describing how to use usdz_converter in this post:

Verify the conversion

Once the .usdz has been created, OSX tempts you with an opportunity to view and edit properties of the .usdz file in the Xcode SceneKit editor.

Don’t Fall For It!

The textures don’t appear correctly in Xcode. Additionally, you can’t edit the properties for a model in the editor. You can validate the node hierarchy, and potentially material properties, but you can’t effectively edit anything (at this time).

The only sure-fire way to validate the USDZ is by sending it to your phone. This can easily be done with iCloud or AirDrop.

Sadly, you will likely need to do this multiple times as you tweak things (especially materials). I will address a way to optimize this process in my next post.

Animation

For the animation, the goal is to create an infinitely looping spin. This is accomplished through linear interpolation and ensuring that the last frame(+1) is exactly the same as the first frame.

Additionally, the trigger on the switch should appear to be depressed by the spinner arm (this is how points are scored). Each object will have it’s rotation transform adjusted, the bar has it’s position more finely controlled, while the target has a 360° rotation applied over the span of the animation.

Unfortunately, when exporting this animation as .abc, the timing and keyframes don’t always match the source file.

Here is how I resolved this issue:

I created my animation as I wanted them to appear in Cinema 4d. On export to .abc, I set start frame to 0, end frame to 25 (even though the animation is only 24 frames), and ensured the frame step and subframes are set to 1.

Then, I ran through the same usdz_converter process as before, but used the following command line options:

xcrun usdz_converter spinner.abc spinner.usdz -a -l

-a Generate a .usda intermediate file.  Default is .usdc.-l Leave the intermediate .usd file in the source folder.

This utilizes the options to create an intermediary, ascii .usda file, and does not delete it.

At that point, I opened the .usda file with a text editor and edited the properties that made sense, such as:

endTimeCode = 23
framesPerSecond = 90
startTimeCode = 0
timeCodesPerSecond = 90

Most importantly, however, is the endTimeCode. I essentially ‘trimmed’ the animation so that it looped correctly by setting the value to the final frame that I wanted, then sped it up by changing the framesPerSecond and timeCodesPerSecond values.

I suspect that it is sub-optimal to have the ‘trimmed’ frames/timeSamples remain in the .usda file, so this should be investigated further.

once edited, the .usda file can be converted to the .usdz file thusly:

xcrun usdz_converter spinner.usda spinner.usdz

So, really, the conversion roadmap ends up being:

.SLDPRT →.stl→.c4d→.abc→.usda→.usdz

phew.

Applying Materials / Texturing

I’m not going to describe the whole process of texturing objects in Cinema 4d. If you need help getting started, Greyscalegorilla will have what you need.

If you have any tips for approximating PBR in C4d to match AR Quicklook, I would love to hear your feedback.

If you’re importing 3rd party materials, or you are applying your own baked materials, I found this post extremely helpful. It does a great job explaining PBR, and where each texture should be applied.

In my brief experience, I wasn’t able to get C4d to 100% accurately render the materials the same way as AR Quicklook, even with the Physical Renderer in Cinema 4d Studio. However, I was able to approximate things to a point that I was able to implement a process that worked well for me for exporting materials from C4d:

Exporting Texture Channels

I used UV mapping for all of my materials. Often times I had to manually manipulate those UVs, particularly for the brushed metal effect on the bracket.

To keep your textures and .usdz in sync, remember to re-export your .abc file after you make changes to your UVs in Cinema 4d.

The most efficient process for me was to bake objects with the relevant channels selected:

Baking

By selecting your object, then selecting Objects>Bake Object, you will be presented with this screen:

By baking all of the objects, with the relevant channels selected, then deleting any extraneous textures, you will have a uniformly named set of textures, prefixed by their node:

barAmbient_Occlusion.png
barMetallic.png
barNormal.png
barRoughness.png
barSurface_Color.png
bracketMetallic.png
bracketRoughness.png
bracketSurface_Color.png
switchAmbient_Occlusion.png
switchMetallic.png
switchNormal.png
switchRoughness.png
switchSurface_Color.png
targetMetallic.png
targetRoughness.png
targetSurface_Color.png

Alternatively, you can use the Bake Texture tag on an object for more granular control of the channels that you are exporting. It’s output can be configured to match the naming pattern above.

Finally, once you have all of your textures prepared, you are able to pass those nodes and file names into usdz_converter as Nelson Chang describes here.

Wow, what a ride. This is a lot of work, especially if you need to validate very minor changes to your model or textures. Luckily, my next post offers some tips, tricks, and a tool on how to automate this process.

Dan Thompson is Director of Emerging Experiences at Perficient Digital Labs. Read more about how Perficient Digital Labs uses Emerging Technology to create innovative experiences that transform the way our clients do business here.