Iterating maya underworld when exporting

[sirpalee]

Description of Change(s)

The change adds the ability to iterate objects in the Maya underworld during USD export from Maya.

Fixes Issue(s)

Objects are not exported from the underworld. This happens if somebody writes an exporter plugin for imagePlane.

[pmolodo]

Squashed the three commits into one, for cleaner history

[sunyab]

Hi @sirpalee, @elrond79, our sets team had a few code review notes that I've added below.

There was one larger issue though that we wanted to talk about. With this change, the exporter for NurbsSurface is now exporting additional prims for the transform and shape nodes from the underworld. We have a test case that we're hoping to clean up and release so you can see the differences yourselves, but here's an example of an exported USD file with this change:

def NurbsPatch "SphereCubic"
{
# All of the below prims come from the underworld and were not being exported before.
def "SphereCubicShape"
{
def Xform "projectionCurve11"
{
def NurbsCurves "projectionCurve11_1"
{
# ...attributes for curve ...
}
}
# more Xform and Curves prims
}
}

We're not sure this is desirable -- we typically don't export prims beneath gprims like this. We're wondering if other people would actually want these prims exported, or if we need to add some kind of opt-in mechanism so that your image plane exporter would export things from the underworld, but other exporters would not by default.

[sunyab]

Could we restore this comment with the appropriate modifications for the underworld?

[sunyab]

How about simplifying this block by pulling the logic in this else clause into a static helper function in this cpp file, like:

static bool
_HasParent(const MDagPath &dagPath, const MDagPath& dagPathParent)
{
    // code from else block here
}

and then restoring the else-if statement like:

else if (!_HasParent(curDagPath, curLeafDagPath)) {
    // comment goes here
    itDag.prune();
    continue;
}

[sunyab]

Is it the case that we just want to strip off the first "->" we see (reading from left-to-right), and everything afterwards? If so, would the following be simpler?

    usdPathStr = std::string(usdPathStr, 0, usdPathStr.find("->"))

[sirpalee]

No, we want to get rid of -> and keep the rest.

I cleaned up the implementation a bit, first doing the removal then the replaces, kept the iterators and added a bit of extra comment to clarify it further. What do you think, is it easier to follow?

std::string usdPathStr(dagPath.fullPathName().asChar());
// We are keeping the iterators around, to avoid extra memory allocations.
// Replacing characters because of underworld (transform|shapeNode->|underWorldNode).
// Maya inserts "->|", we can safely eliminate both the "-" and ">", and keep the rest.
auto itBegin = usdPathStr.begin();
auto itEnd = std::remove(itBegin, usdPathStr.end(), '-');
itEnd = std::remove(itBegin, itEnd, '>');
// Replacing MDagPath separators with the USD ones.
std::replace(itBegin, itEnd, '|', '/');
// We may want to have another option that allows us to drop namespace's
// instead of making them part of the path.
std::replace(itBegin, itEnd, ':', '_');
return std::string(itBegin, itEnd);

[sirpalee]

@sunyab I wasn't able to reproduce the nurbs issue locally (we are not much of a nurbs users), so I'm looking forward to the example. The rest of the issues were fixed and I pushed back a change. (I'll squash them later on, but keeping the changes separate for now)

[pmolodo]

I rebased / collapsed our changes, and pushed a fresh / clean copy. Look here for the full history:

https://github.com/LumaPictures/USD/tree/tg/simple_features/iterating_maya_underworld
LumaPictures@5794dc3

[jtran56]

Filed as internal issue #147123.

[pmolodo]

So - was looking to fix up our PR to solve your issue (the nodes are created by projecting nurbs curves onto a nurbs surface, apparently). Decided the best approach was to limit the exported underworld nodes to be only image planes, since thats what we needed it for... and for various technical reasons dealing with how instances are handled*, it ends up simplifying things if we only need to worry about image planes / underworlds beneath cameras.

I actually went about implementing this... however, I realized that this PR then becomes useless, without our accompanying changes to export image planes! Since we're not quite ready to make a PR for that yet, I'm going to close this PR for now. We may reopen it (or open a new one) when / if we make a PR for our image plane stuff.

For reference, the changes to only export image planes from the underworld can be found here:

https://github.com/LumaPictures/USD/tree/tg/simple_features/iterating_maya_underworld2

Most of of the meat of it is in this commit: LumaPictures@5334f10

*Not sure if anyone else cares about the technical details, but for my own reference if nothing else: Initially I wanted to go with an opt-in approach for exporting types of nodes from the underworld, with a user-configurable option saying which node types you wanted. However, it turned out that handling this correctly is difficult, because of instances. Currently, instances are only exported from maya for shape nodes... because we then never have to worry about exporting instance hierarchies, ie, cases where there are nodes parented beneath the node that's being instanced. While both maya and usd obviously support this, it would significantly complicate the exporter to be able to handle this properly. If we allow exporting of any type of underworld node, we effectively need to solve this problem, as we no longer have the guarantee that shape nodes don't have children. However, if we say that the only type of underworld nodes we export are image planes underneath cameras, it sidesteps the issue because cameras are currently hard-coded to not support instancing on export.