Support for Cameras/Curves/etc about usd-unity-sdk

[daseyb]

I can confirm that cameras are working great!

[jcowles]

Ah, yes, they should be included in UsdGeom, but aren't currently.

Adding support for some specific schema should be mostly trivial (e.g. see Xform), but you will need to setup swig and a python-enabled USD build as noted in the "generating bindings" section of the readme.

To have your PR accepted, you will need to sign the contributor agreement.

But yes, contributions are very welcome!

[jcowles]

Still a work in progress, but I've added bindings for UsdGeomCurves, BasisCurves and Camera in this change: 52fdc5e

[daseyb]

Thanks! I had some trouble building from source (I didn't have the monolithic build of USD setup), so this is greatly appreciated. I hope I can work that out soon so I can contribute directly if anything comes up :)

[jcowles]

W00t!

[jcowles]

Ok, the majority of UsdGeom should now be wrapped (just pushed).

As for the high level serialization Sample classes, I can add one for Camera and BasisCurves (I'm assuming you want basis curves and not nurbs curves), but long term, I'd like to generate these from the schema definitions, which requires some investigation.

Let me know if there are specific sample classes that would be immediately helpful and I'll set them up!

[daseyb]

Awesome! I think the camera sample class would be the most convenient one to have right now, but it's not super urgent since I'm fine with using the native API :)

[jcowles]

Ok, I pushed a quick sketch of a camera class -- let me know what you think! Obviously I haven't used it in production yet, so keep an eye out for anything that seems off.

[jcowles]

The unit test may also be helpful:
https://github.com/googlevr/usd-unity-sdk/blob/master/src/Tests/Cases/UsdGeomTests.cs#L17

[jcowles]

Similar support for BasisCurves along with a quick unit test.

ProTip: when debugging curves in usdview, be sure to hit "CTRL+" to turn on tessellation so you can see the curve widths.

[daseyb]

Thanks, that's looking great! I think geometry wise that's all I need for now.
Next thing I'm going to tackle is shading, do you have a link to a good resource on usdShade? All the information I could find was fairly vague and I couldn't even find a good sample file with a texture mapped model.

[jcowles]

The basic idea is very similar to unity (though goes much deeper), you bind a primitive to a material and a material may have multiple engine targets and each engine can have a shader network specific to that engine. Parameters are surfaced on the material and connected directly to all the networks in which they apply.

I think I'll add an example in the asset package examples.

[jcowles]

Here's a shader schema example:
https://github.com/googlevr/usd-unity-sdk/blob/master/src/Tests/Cases/UsdShadeTests.cs

The UsdShade schema requires UsdRelationships and connected UsdAttributes, so those are now supported as part of the high level API, though the exact implementation may change (any feedback on USD.NET.Relationship/Connectable is very welcome!).

Talking with folks at Pixar, it sounds like the docs for UsdShade are actively being written.

[daseyb]

That was a quick turnaround!
The example already helps a lot and it's good to know that the docs are being improved. I'll do some testing later today and will let you know if I run into any issues with the API.

[jcowles]

Cool!

[jcowles]

I would hold off on diving into the shading stuff for a bit, I'm writing up an example in Unity and working out several kinks along the way.

[jcowles]

Ok, I added a more complete "ImportMaterials" example here:

https://github.com/googlevr/usd-unity-sdk/blob/master/unity-assetpackage/Assets/UsdUnitySdk/Examples/ImportMaterials/ImportMaterialsExample.cs

Which should look something like this:
https://youtu.be/7kWodREeJx4

It's using almost all the Standard PBS inputs, so it should be representative of real shader/material import problems.

I'm curious, will your shaders will be known in advance (e.g. how the example is setup with Unity.Standard) or do you intend to have a more extensible system, where you wont know the shader parameters a priori?

It seems dynamic shaders in Unity is generally difficult, so the assumption is that most users will have a well known set of shaders.

[jcowles]

Ah, I guess one way that this example is cheating is that the textures have .meta files to configure them, which should be coming from the USD file.

This should just a matter of fleshing out the Texture2D class to drive the texture configuration.

[daseyb]

The example looks great!
Yeah, I'm not sure if dynamic shader generation is possible at all in a standalone build.
The current plan is to use a single, flexible, Unity shader and adapt the USD material as well as possible (possibly allowing users to adjust the guessed adaption after import, just in case we expect "_Emission", but their texture slot is called "_Emissive" or something). Still, we'll probably limit ourselves to a PBR-ish shader for simplicity since perfect material replication is not necessary for our use case.

[jcowles]

FYI, I've recently added CopyFromCamera, CopyToCamera, and a constructor which accepts a Unity Camera to make CameraSample a little more usable.

I've also recently started using Curves and it seems to be mostly functional (primvar interpolation being the primary issue to resolve).

I'm closing this out, but feel free to create new issues for missing features or other missing schema types as you need them.