Autodesk UFE integration

seando-adsk commented 5 years ago

Description (this won't be part of the changelog)

Use Autodesk's new UFE API in the plugin to perform a UFE selection. This allows Maya to manipulate the USD objects directly. All of this is controlled via cmake configuration and C++ compile define.

Changelog

Added

When building with UFE is enabled, you will still get the default AL selection behavior. To enable UFE selection, you also need to set the env var MAYA_WANT_UFE_SELECTION. For now this is checked at run-time allowing you to enable/disable it to switch between the different selection modes. Note: this UFE selection is supported in the old VP1 code and also in VP2. When UFE selection is enabled, perform an extra wireframe draw to show selection.
Implemented VP2 selection, so the env var MAYA_VP2_USE_VP1_SELECTION is no longer required.

Deprecated

MAYA_VP2_USE_VP1_SELECTION is no longer required.

Fixed

Some minor Windows build fixes.
Update bounding box when UFE selection occurs.

Checklist (Please do not remove this line)

[ ] Make sure the Title and Description of the PR make sense and provide sufficient context for your work
[ ] Do any added files have the correct AL Apache Licence Header?
[ ] Are there Doxygen comments in the headers?
[ ] Are any new features, behaviour changes documented in the .md format documentation?
[ ] Have you added, updated tests to cover new features and behaviour changes?
[ ] Have you filled out at least one changelog entry?

seando-adsk commented 5 years ago

I'm don't know why all the tags commits are showing up here, but it appears they aren't merging anything since I can see from the list of files changed that these all are the changes that we've made at Autodesk.

murphyeoin commented 5 years ago

Hi @seanofnine - we've seen that tag commits problem before - it's strange, we'll investigate. Thanks for the UFE work - it's a big milestone, exciting! Can you tell us which version of UFE/Maya-2019 Beta is required or recommended? (I think we just got PR98)... Thanks

seando-adsk commented 5 years ago

@murphyeoin These changes will require PR98 which has the v1.0 version of UFE.

chadrik commented 5 years ago

Exciting! We'll check this out on Monday, after the holiday.

We have made a number of improvements to the UFE python plugins that were provided to us by Autodesk. Once this PR gets merged we'll follow up with a PR to add those. @seanofnine I'll be sure to flag you on it so that you can check it out.

fabal commented 5 years ago

Hi @seanofnine , would it be possible to clean up this pull request in order to provide only the needed commits? In this case master has been merged earlier in dev-adsk and this is something which should be avoided. The development should always be based on develop. Some git rebase and/or squash might needed. Thanks.

seando-adsk commented 5 years ago

@fabal Sorry to which commits are you referring to? I wasn't the one that originally created the dev-adsk branch, but I assume it was created from develop. I have personally merged develop into dev-adsk a couple of times to keep us current with the progress. The only extraneous commits that I see are all the tags, which I'm don't know why they appeared here.

b0ssi commented 5 years ago

Hi @seanofnine - I believe @fabal is wondering if we could get rid of the (redundant) list of release-commits (0.20.2, 0.21.1, ...) as they'd be irrelevant for this PR.

It looks like the dev-adsk branch was branched off our (Animal Logic's) master at 0.27.10 (e2dff9fb316e8c2564cc9b65baac64bb373b3065). When creating the diff for the PR git would backtrack to wherever the branch to merge (dev-adsk) branches off the diff-base (develop) - and this is all the way back, before the first of the release commits listed above (0.20.2 (5ec16f41af30ed446dfd3ea7b30f9ddb277ee50f)), that's why they all show up in here.

One thing that would clean the history up and correctly branch off develop would be to do something like this (please ignore any of this though if you think it might not work for you or possibly conflict with your workflow or set-up for the dev-adsk branch):

Create a temporary branch at cae40e7bfc0fbc6434de46f7b311bd970b43baae and check it out (that's just before you merged develop back into the dev-adsk branch),
rebase this temporary branch we're on onto the last "was-develop" commit right before the point you branched off from (which would be 38404ee10aa38c8c3ea00bd380dab0afadb4f1fd);
now cherry-pick the remaining few commits from dev-adsk on top of the temporary branch we're on and
move the dev-adsk branch onto the temporary branch we're on (-m 1 for b9ac70e89ac881df5591dd318722d40549debab7) and optionally delete the temp. branch again.

NB: The above will rewrite your history for the dev-adsk branch (and might affect local branches and PRs you have in your repository) as well as "flatten out" branch-off- and merge commits - while still preserving every contributing commit of course. Retaining branch- and merge-commits is possible but would be a bit more work).

fabal commented 5 years ago

@seanofnine Release commits are recorded in master only that's why they're showing up here. dev-adsk has been branched off of master first at e2dff9fb316e8c2564cc9b65baac64bb373b3065 and then master has been merged in again a couple of times (9bce541540dc2c9a615c08987e547d8c3d3e64a2, 19add17cbce99b79b7526e3b7daf15c3516199f4).

Our goal is to keep the history clear enough for everyone to read. Currently our changes (made at Animal) are always rebased directly into develop and other contributions are merged with no-ff (we're considering adding our changes the same way as external contributions). In general, we recommend rebasing your work regularly if possible.

We've updated the contributing documentation, it will be available shortly.

You can follow @b0ssi recommendations or simply (if possible on your end) squash all your work into one commit.

I hope it helps.

seando-adsk commented 5 years ago

@b0ssi / @fabal - thanks for the explanation. We discussed it internally and we have no objections against squashing all our work down to a single commit. We don't have any local work in our dev-adsk branch, so it's okay to flatten this out and lose the merge commits on it.

fabal commented 5 years ago

Great! Will you squash it on your end? (this way the commit will be authored by someone from Autodesk). Otherwise we'll squash it ourselves. Let us know.

seando-adsk commented 5 years ago

I had trouble converting the old dev-adsk branch into a new squashed one, so I created a new branch from develop containing a single commit with all our changes squashed together. See PR #131

I've copied over all my comments and made the change that Chad asked about the VP1 env var.

AnimalLogic / AL_USDMaya