We love your Feedback!

Please tell us how we can make AYON work better for you. You can also report bugs or ask questions if our Help Portal is not helping.

If you’re looking for developer resources, you can find all of them on our Developer Portal

Support Tags in settings filters

In many places in different addon settings, we can filter profiles by task names and types like in OCIO config profiles. Which can be intuitive as it expects naming the tasks in a particular way. In contrast, we already have tags that we can define for our project in the project anatomy. I think it’d be much easier to have tags in these profile filters. That way, we won’t need to worry about the task name or type, and it will also appear very explicitly on the overview page. Tags are colored, making them easy to identify visually in the overview page. Note this is a mockup to visualize the idea. Also, note the backend server doesn’t support tags_enum in compliance totask_types_enum. The example above shows the OCIO config profiles but this can be also used in application filters and tools. Disclaimer: I’m not sure if this request deviates from the original intended usage of Tags.

Mustafa Zaky Jafar

💡

Feature requests

Maya USD: Rig in USD Asset as MayaReference prim

Working within a USD Pipeline usually means you want your animation output for e.g. a rig to be overlaid on top of a loaded USD Asset to merge the animated point data with the model and look of the asset, usually for use by downstream lighting department. The USD reference usually provides: - asset (referenced usd asset) - geo - mtl The output data from a rig should then be overlaid over the /asset/geo path in the shot to move the character around. Currently, publishing an animation from a rig usually means completely separate Alembic or USD data that would need to somehow be identified to get overlaid over a particular USD asset structure in a shot. What if we could load an asset, and it itself, has a reference to the rig embedded? How would you imagine the implementation of the feature? Maya USD allows to embed maya scene files (mayaAscii or mayaBinary) to be included into USD as a MayaReference prim referencing the file. When a Maya USD Proxy finds such a prim it can enable the prim as a regular maya reference to load the native maya data, like for example a rig file. I'd like to propose to - whenever publishing a rig from Maya to write out a USD Asset Contribution where an extra layer gets added to the USD asset representing the rig as a reference. Basically someone (e.g. either in Maya or Houdini) lays out assets in a scene, by loading the asset USD. If that asset now contains the MayaReference prim (which can be loaded fine in Houdini; just the internal data of the maya scene couldn't be loaded) then in Maya one could now enable that reference inside the USD Asset to load the actual rig. So assets laid out in any USD supporting host could in Maya be switched to their rig for animating. Nice! In essence we'd need: On publishing a Maya rig, create a USD asset contribution that references in this rig version in a USD layer On Maya, when the Maya USD reference rig is loaded (and its detected its loaded within USD asset) then publish the animation cache as USD that gets added as a variant on the loaded asset in the shot's anim layer. That way, the animator in Maya can just read a USD Layout with loaded assets, enable the reference, animate and publish. Plus side to this would be, that when they've published their animation to the shot's layers they can also disable their reference and switch it over it to the published cache (since it's also a USD contribution). Meaning they can use the cached USD data as proxy in their scene whilst maybe e.g. continuing to animate on another character. Originally posted on GitHub: AY-6685_Maya USD: Rig in USD Asset as MayaReference prim #10

Roy Nieterau

💡

Feature requests

New workfiles for softwares without addon

I really love the simplicity of the Tray publisher. Any file with any extension can be published and be a part of the pipeline. It would be great to add this simplicity to work files as well (but not using the tray publisher) * Creating addons for every software in every industry will be hard to manage and take very long time. * “Simple” softwares like Excel, Word, Powerpoint, Notepad etc is in need of a simpler approach than addons, since there is simply no way to develop addons for every single software *The simplicity of the tray publisher could be applied to workfiles as well and therefore open up possibilites to add any type of software to the AYON pipeline, also for workfiles. To solve this we need a new feature to create new work files based on pre-existing template files. Maybe this could be done with the interactive web action? Example User creates a new task in overview and with web action the user gets to choose if it wants to create a work file from pre-existing template (For example there might be 5 different Excel templates for different purposes) Once the template is chosen there will be a new workfile created on disk and also a new database entry. For publishing we could still use the tray publisher. This feature would open up a lot of freedom for the user to add softwares that does not have an addon and not necessarily need a fancy pipeline. Problems to solve * Versioning of the workfiles would need to be added somehow. Maybe as a right click feature on the current workfile.

Olle Rydberg

3
💡

Feature requests

Set Product Status on Publish

To make it easier for users to set statuses it would be super helpful if the status of a product version could be set when publishing - I am thinking along the lines of two per instance attributes, one to set the status of the new version and the second to change the status of the currently existing version(s). So I want my new version status to be Pending review and the previous versions to be set to Omitted. This will also help with the status filters in the loader which hide versions based on status, so if you want to make sure all previous versions are excluded when Omitted is set to be hidden, all versions have to have their statuses changed manually, which is very tedious :(

Shea

7
💡

Feature requests