Type, purpose, kind, draw mode ​

Lets get a slew of USD terms taken care of. As mentioned a few times by now a lot of these things make sense in context, but can be a little frustrating at first when you hear these synonyms mentioned by the USD illuminati.

Type ​

Type is most analogous to Houdini primitives. Houdini prims can be polygon, vdb, nurbs, agent etc, in USD everything is of type 'something'. The list of types USD supports is pretty extensive, covering pretty much everything Houdini does, plus everything else you'd need to be a full scene description, so there's primitives for lights, cameras, materials etc.

This can also be set via a Configure Primitives lop. Change a sphere to a camera, a point to a light, there's plenty to play with. Immediately this should give you some ideas for procedural scene layout, eg you could replace incandecent geo for lights just by changing their type.

Curious aside; there's no USD primtive for a null or locator, like wot you'd be used to in Maya or Houdini. Can sometimes make visualising parented hierarchies difficult.

Purpose ​

Purpose is a simple way to say if a thing should be something to render, or for preview, or a viewport handle only. That's it. Use the Configure Primitive lop to define what a thing should be, then you can tell solaris to hide/show each categeory via the sunglasses icon in the right stowbar of the viewport. The purpose names are pretty self descriptive; 'render' is only for final frames, 'proxy' is faster viewport geometry, 'guide' is for helper nulls and whatnot.

It doesn't take long before you start thinking 'hang on... but what if I want to send low res stuff to the renderer? Or see the final high res geo in the viewport? Or what if I have multiple level-of-detail, do I have to choose just one to go to the purpose I want?'

From what I understand the answer is 'ahh, well, purpose works for us internally at Pixar for very specific use cases'. It's built around how usdview, presto, their other cool toys work, and wasn't really designed for the rest of us. Ultimately it's an organisation tool, more tags to lets you quickly hide and show related things, like using the Maya display layer editor, but hard-coded to 3 layers, and where the renderer assumes you only want it to see the one named 'render'. Also to be blunt I've found it unstable to rapidly switch between different purpose displays, so I tend to not use it much.

Kind ​

Most of the docs I've seen around what this means will cheat and just quote the USD docs. I'll do the same.

• model - Everything in the model hierarchy is a kind of model.
• component - A component model is a terminal model in the model hierarchy - it can have no child models.
• group - a model that is simply a container for other models.
• assembly - An "important" group model - often because it is itself a published asset.
• subcomponent - Within a component model, subcomponents identify important (generally articulable) sub-trees. Subcomponents are "stopping points" when dynamically unrolling/expanding a component.

So, done, lets move on.

Ok ok, lets not. Kind is a way to tag a primitive with its intended purpose. The best analogy I can think of is the way riggers in maya will often name their joints and groups with an underscore plus suffix, eg _CON for constraints, _JNT for joints, _HLP for helper bones. Or something like that, it's been years since I've looked at maya rigging. Anyway, the point is you could setup a pretty complex hierarchy in USD for, say, a car, and tag up the parts with their kind so that the hierarchy itself is more descriptive and self documenting:

• top level 'car' as an assembly, because its the top level important group that will be published
• the collection of dials and stuff named 'dashboard', stored as a 'component', because its the end of the line for that hierarchy, we intentionally want to say 'nothing can be parented under here, this is as low as we'll go'
• ah but the little markers for the fual gague need to be gettable... ok, mark them as 'subcomponent'. Yes they're there, but we really don't want to deal with them often, so its almost like we're packing them under the dashboard as named polygon sets.

In other words, you can see that while it could be useful later on when you have super complex setups, and you'd like a little more intelligence and metadata available on your geometry, when starting out its probably fine to just ignore 'kind'.

You can set kind via a Configure Primitive lop, and see it appear as a column in the scene graph tree, but in most cases you won't see any meaningful visual change in the viewport.

Draw mode ​

Yet another thing you can modify via a Configure Primitive lop, this is most analogous to the display settings for loading packed disk prims or alembic from disk. Like purpose it shows its hardcodedness for Pixar tools, the 4 modes it offers are pretty brute force (full geometry, nulls, bounding box, texture cards). The last, 'texture cards', sounds like it could be interesting, eg for a distant forest you could do game-engine style 3 intersecting cards for the front/side/top view of a tree, but the Solaris help doesn't give many clues for setting this up. Something to research...

Summary ​

It's interesting to realise that of those 4 important sounding terms, only Type is actually important and mandatory, the other 3 are a mismash of organisational tools and display modes. Handy to know they're there, but not necessary, and can be safely ignored until you need them.

prev: UsdGuide11 this: UsdGuide12 next: UsdGuide13 main menu: UsdGuide