Cleanup#27
Conversation
This is an example of how workflow can be automatically tested. In this case, the modeling workflow is tested. If something is done here that isn't valid, and is caught during validation, this test would fail. Update this test whenever the modeling workflow changes, and keep an eye out for when it *hasn't* changed, but the test still fails. It may mean there has been an accidental breakage of a valid workflow.
…tion of plug-in path. Registration currently happens in the .bat file, which makes it challenging to replicate in pure-Python tests. Now the tests can instead leverage the standard `install()` function, and less strain is put on the .bat files.
This is mainly a suggestion, the previous approach works, but may be difficult to modify in the future due to the overly specified logic and commented-out code.
With a more strict registration of hosts, this was revealed to be broken.
|
Hi @LegacyID1991, let me know what you think about these changes. If you click the "Watch" button at the top of the page, you'll be notified of new PRs like these. |
|
Clean and neat as ever. No objections |
|
Excellent. What are your thoughts on the boiler plate for Nuke? Take your time to read it through, and see if there is anything you find difficult to understand. Those notes are for you specifically. The notes then apply to Houdini as well, along with Mudbox, Photoshop etc. All tools in Maya today should work across all apps you guys use. |
|
Here is the workflow test, it isn't many lines of code and should be easy to read. It's how a modeler would work with the UI. I'm picturing similar functions for how you would work in Nuke, and Alldin in Houdini etc. |
Anything called exactly "TODO" is easily searchable.
|
I saw the pipeline.py for nuke in commit The workflow test I understood, what does the quote below do ?
|
It was probably what you saw, as in this. By "boiler plate" I mean something to be filled in, in this case by you when you are looking to implement the pipeline tools for Nuke (and Houdini).
You won't really need to understand decorators in order to expand upon this test, or write more tests, all you need to understand is that Here's more on decorators if you're curious. |
Introduce Houdini to Avalon core
…_asset_gui Feature/pype 195 switch asset gui
I've gone through the project and added documentation to things missing, fixed broken things and added tests.
The main thing I've added is a skeleton to get the Loader, Creator and Manager working in Nuke. See
pipeline.pyin thenuke/folder.Some more highlights.
/mayaPython package. Now plug-ins can be registered automatically in theuserSetup, instead of via the.bat. This is important if we want to use the plug-ins in tests, that won't go through the.batfiles.One of the tests I'd like you to familiarise yourself with Arvid is the workflow test. It's a snippet of code that does what artists do, and ensures it passes validation and ends up in the right place. The idea is that, whenever a validator is added, this test is updated to reflect what is a correct model. The test will then tell you when something is changed that breaks the normal modeling workflow for artists.
I'd then expect similar tests for each of the asset families at Mindbender, including rigs and animations. These will save you time in the future, in the form of you making an update and artists coming to you afterwards, unable to work, because something broke. Hours saved, multiplied by the number of artists. Having said that, it does take some getting used to and to update. I would suggest you take the hit initially and get a feel for where it is to your advantage, and then make a decision about whether it's worth doing.
See the commit comments for what has been done specifically, some commits have extended notes about why it was done. You can click the little
...icon to expand.