Multiverse: fixed composition write, full docs, cosmetics

[pberto]

Brief description

Finalized Multiverse integration.

Description

• updating labels for the various tools as per discussed
• first version of the documentation on website
• added jcube to op contributors on main page of website
• Adding support for choosing .usd/.usda/.usdz.
• fixed empty composition due to relative paths
• formatting / cosmetics

Documentation

This PR includes also documentation.

Notes

We will add a Multiverse Look creator at the next PR.

[iLLiCiTiT]

You call get_file_format but it does not return a thing. Instead, it is changing attribute of object so if instance does have empty fileFormats it will use scene_type of previous instance.

Also not sure what the code should do? If it would be rewritten to simplified version:

instance_file_format = ["usd", "usda"]
file_formats = ["usd", "usda", "usdz"]
some_range = range(len(file_formats)) # that's the same as [0, 1, 2]

# This will never be true as the list with file formats won't be in iter of itegers
if instance_file_format in some_range:
    # You change attribut on the class instead of returning it
    # + it would crash if it would get here because it's using
    #    a list to get item from list (TypeError)
    self.scene_type = file_formats[instance_file_format]

It kinda looks like you wanted to use for instead of if? But that's anti-pythonic way of looping through list. Also only last item would be used in that case it would be better to use:

# Backwards compatibility for instances without fileFormat
file_format = instance.data.get("fileFormat")
# Check if is set
if file_format:
    # return last item of the list
    return file_format[-1]
# Return default scene type
return self.default_file_format

[BigRoy]

Why would be instance.data["fileFormat"] be a list or tuple in the first place - that sounds confusing?

Why can't it be this?

file_format = instance.data.get("fileFormat",
                                self.default_file_format)

Or even a hardcoded backwards compatible default:

file_format = instance.data.get("fileFormat", 
                                # Backwards compatibility
                                "usd")

With this simplification it doesn't need its own get_file_format method. Nonetheless, like mentioned before.. please return the value instead of storing it on the class if you do end up using a defined method for this.

[dmo-j-cube]

Sorry for the delay. For simplicity, I did your suggestion of using that get method.

[BigRoy]

@iLLiCiTiT would you feel it's wrong if name would always be usd no matter the extension? That way updating in the manager can be done even if file format changed in-between. Thoughts?

[BigRoy]

We will add a Multiverse Look creator at the next PR.

It might be confusing that the current documentation does already mention Multiverse Looks (e.g. in screenshots). Do you have an ETA on that next PR?

[pberto]

@mkolar please note I refactored a bit the Maya docs as the page was too long. I personally think this new organization is easier to read for the user and is also faster to find content.

[mkolar]

@mkolar please note I refactored a bit the Maya docs as the page was too long. I personally think this new organization is easier to read for the user and is also faster to find content.

Thank you having a look

[m-u-r-p-h-y]

The link in the documentation is not valid

[pberto]

That is because we did not release 7.1 yet but it will be released in the next days so that link be valid and you should not worry about it, you can safely merge it :)

[mkolar]

@pberto just for completeness I'll add information we discussed in private conversation.

We're happy to merge this, but please first change the family names to be prefixed with mv. We're working towards better modularity and also on native USD integration, that will be most probably structured a little differently than your data, so we'd like to avoid any confustions and make sure we don't have to resort in family renaming once this is in production. If we come to the point that OP would be generating USD based families with your suggested names across the board, it will be trivial to add their compatibility to your loaders and publishers, just by adding the new family to it. But let's cross that bridge when we get to it.

Other than that it's looking like great work! Thank you

[BigRoy]

but please first change the family names to be prefixed with mv

Are we sure? The data is just regular usd data that is generated in the end. Nothing Multiverse about that - except for the published multiverse looks that is.

To load the multiverse USDs into Houdini I'd then have to allow them to load mvUsd data instead of regular USD data. This will spread much further than we'd probably like?

I admit the Loaders themselves (so that loaded content can be managed correctly in the future) are MultiverseUsdLoader, etc. but they already are. 👍

I can see however how the Extractor might run into a conflict with the family if another pops up - but I think that's much easier to solve in the future than fixing published families.

Or did you intend to say that we'd still try to actually register the versions as usd family?

[mkolar]

Or did you intend to say that we'd still try to actually register the versions as usd family?

We're actually very wary about USD family in general. It goes very much against the grain of what families should be in the first place. model layout rig animation. Families define the type of data, not it's format. The exceptions are generic families that a host can define as a fallback. For example mayaScene or nukeNodes. Those are also not validatable.

It is very much true that if we prefix them, then other USD loaders should be aware of them, but I'm not sure it's a good ideal to now define usdComposition, USD and usdOverride as global families either. Adding a family to a loader can always be extracted into it's settings, as we do in many places.

There is a large discussion required (which btw we'll be invoking within days most probably) on how to work with USD across the board with OP. I have a feeling that the first steps will be as representation of some families (Layout represented as USD, model represented as USD and so on).

[mkolar]

MV structures the USD data in certain way that makes sense from it's perspective and even though they are just native USD files, it's kinda like ditching model family and instead we start using alembic instead. Yes it's universal, but it removes all structure.

[mkolar]

Houdini implementation at the moment is a good example of such mixup. We have usdCamera which makes no sense. It should be Camera family that has USD representation, albeit generic USD scene family will be immensely useful as fallback, the same way as mayaScene is. The question is, what to call is USD, usdScene, usdStage? And it doesn't really fit what usdCompositionandusdOverrides` are as they have very specific structure that could be validated

[BigRoy]

Thanks for the follow up - I understand. 👍 Definitely worth a good brainstorm on other potential approaches for this across the whole "family". (Pun intended.)

[mkolar]

please check comment in #3178 (comment)

[pberto]

please first change the family names to be prefixed with mv.

@mkolar as I said in private, no problem, we can change family names. Whats important is that the representation stays "usd" -- which we both agreed on.

[dmo-j-cube]

I have changed names for multiverse related families from usdX to mvUsdX - but have left usd intact since it's also been used in other places (and was already there before we pushed our first commit)

[mkolar]

Thank you guys. This is great and I think we can squeeze it into 3.11.0