-
Notifications
You must be signed in to change notification settings - Fork 202
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[hdMaya] add Maya-to-Hydra plugin and scene delegate #231
[hdMaya] add Maya-to-Hydra plugin and scene delegate #231
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good...left few comments, but didn't bother repeating them at every occurrence of the same pattern (this will make it easier to discuss).
Key things:
- we don't have support for selection without UFE - is this ok? (see comment in lib/usd/hdMaya/delegates/proxyDelegate.cpp)
- we still have quite a lot code for 1901 and 1905
e459338
to
73730b7
Compare
Latest push was just to rebase against latest dev (to make it easier for me to build). No functional changes. Starting to review / address all the notes - thank you for all the feedback! |
@elrond79 Tested this branch on Windows and MacOS (compiled in strict mode). Got following errors on MacOS:
Attaching patch which allowed me to build successfully. |
- reword the "What's it good for" section of the docs - add nurbsCurve and phong to list of supported nodes
...this is related to another set of selection changes, for which we have not made a PR yet
was arbitrarily chosen, presumably in an attempt to prevent users from crashing if they chose too high a value However, any value that's high enough that no user would conceiveably ever need more is also high enough that it will crash some users systems.
...
Didn't follow your patch exactly (some of the code was needed, depending on USD version), but I think I should have addressed all the compilation warnings / errors: |
So, when I pushed this last batch of commits, I thought I had addressed (or at least discussed) all the comments - until I noticed that github had collapsed some of them! Doh! Ah well, I'll get the rest of them soon... |
I resolved the conversations that were addressed. Maybe this is what you see as "collapsed"? |
according to ANSI-C, these symbols is reserved for the compiler
if we want a switch for what cpp standard to use, should be done at top level /used everywhere
Alas, no - Github does this thing where if a code review is long, it says something like:
... which you have to click on to see the rest. Wish it didn't do that, personally. Anyway - thanks for marking those resolved! |
was currently disabled - in order to restore non-ufe selection, we will need to: - add a new interface to query selection paths from the base proxy shape (ie, something that functions as the combined result of AL's proxy-> selectedPaths and proxy->selectionList.paths()) - implement on all derived proxies - re-add / implement this removed code (ie, the PopulateSelectedPaths override that takes an MSelectionList)
Question - something I've wondered before. Is it acceptable to do MPlug.asInt() if the actual attribute is a short? (This is being done with mesh.smoothLevel.) |
The underlying value is stored as something much bigger (64bit IIRC), so I don't see any reason to change it. |
The asFloat didn't actually pertain to this situation - I was just wondering if it does some sort of auto-conversion, or just blindly interprets the int bits as a float. Sounds like it blindly interprets... Anyway, just pushed removal of an outdated USD_VERSION_NUM check which I somehow missed... |
We are almost there...just one new compilation error to fix (fails both on windows and macOS):
|
gcc will accept it, but clang + vc++ won't
Doh - I should have known not to trust that constexpr to be cross-platform compatible after the problems with the other one. Just changed it to const |
Perfect. I already run tests with this change. |
Awesome, thanks! |
This migrates the Maya-to-Hydra work from refactoring_sandbox to here.
This corresponds to the latest on usd_0_20_02_refactoring_sandbox:
67378d7
(If that commit is merged into refactoring_sandbox, the dev commit this comes off of (ec6750b) is first merged into refactoring_sandbox, then merging this into refactoring_sandbox can be done as a do-nothing merge.)