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

Planned

In the loader, make Hero selection easier

When Hero mode is OFF : artists can just load the product, no problem, they get the latest version. When Hero mode is ON : in the Loader, the default version that is selected is the latest version, and not the Hero version : Problem : if artists want to import a Hero, they need to manually select the [v] for each product they load (which can mean 4 or 5 textures, in the case of published Substance). If Hero mode is active, it would make sense to have it available easily in the Loader, which means force the Hero to be on the first position among the versions list. I think it would help avoid user errors, as we could ask users to not touch anything and just load. It is also discussed here : https://community.ynput.io/t/in-the-loader-make-hero-selection-easier/2537

a.xerri

1
💡

Feature requests

Custom endpoints should have a fixed url

Current situation : Currently, paths to addon endpoints always contain the addon version, since all endpoints from all versions are always exposed. Example : http:// myserverayon:5000/api/addons/my_addon/0.1.2/get-test-data/myProjectName Problem : If we code a custom endpoint, to be used by other departments, we can’t tell them it’s a moving target, they need a fixed url, as in usual REST APIs. Because other departments can’t use self.version or similar, as the calls are done from other softwares. Proposal Please provide a “production" placeholder, that would replace the version. Example : /api/addons/my_addon/production/my_endpoint Context : It is also discussed here : https://github.com/ynput/ayon-backend/issues/494

a.xerri

1
💡

Feature requests

Add Transcoding Options During Export in AYON for Hiero

In standard Hiero functionality, when exporting shots, there's not only the ability to create folder hierarchies and organize shots, but also to transcode frames into the desired format and colorspace: Currently, when exporting via AYON in Hiero — for example, working with.mxf files — we need to manually transcode the shots outside of AYON before publishing. AYON then copies these intermediate files into the correct structure, effectively duplicating the data. This creates issues, especially at scale. For example, exporting a film with 100+ shots to.exr results in around 10TB of unnecessary duplicated data — aside from the added manual steps and general inconvenience. It would be great to support format and colorspace transcoding directly during publish through AYON, so we can eliminate this intermediate step and avoid redundant storage usage.

Alexey Volynets

6
💡

Feature requests

Unified Launcher

Thanks to this post — it finally pushed me to take the time and share an idea I've been holding onto for a few months now: Right now, we have three separate dialog windows, each of which needs to be opened individually via the system tray. The first flow is pretty much the same in each: select a project, a shot/asset, and a task: Why not merge all three dialogs into a single unified launcher? This would reduce the number of required actions and bring all the functionality into one solid entry point. It would look something like this: 1. Workfiles tab Additionally, building on this post, I suggest combining the functionality of the "Working Files" tab with the "Launcher" tab (including Thumbnails). This way, the user can choose to either launch through a specific working file or go in via the selected software. 2. Browser tab 3. Publisher tab

Alexey Volynets

4
💡

Feature requests

trackable variants

We would need an option to add variants from the overview and define ahead of time. -Example 01 Let say we’re working on a show with Dino’s We need multiple triceratops in a scene and we don’t want to have a 1 on 1 copy of them, that would look silly. I would like to have the same model and rig, animation cycles, but would like to have variants of the texture, maybe some have an extra scars, a little color variation etc. etc. I don’t want to create new tasks as they 3 variants we've are all so slightly different that if the client to decide that the overall color of the Dino should be slightly more brown instead of green we need to adjust 3 (in our case substance painter) files. Or if the model changes for some reason, again changing/adjusting 3 files So i just want to be able to adjust that one file and have a folder that we can manually turn on/off for the extra scars etc. etc. etc. We can to that right now at the publish and add a variant name, but we’ve no way to track it or define to the artist which versions we’ve need except for an note in the task. And textureMain and A can be approved but textureB maybe needs some small adjustments -Example 02 We’ve got a show with some “creative” comp shots. for some of these cases we already know that we need to create 3 versions of that shot which the client will decide later on which one will be finalized, this way again, we can have 1 nuke/aftereffects file where we can create the work in, but we can publish to the different variants to address feedback on just one particular version, we can omit the versions that we don’t need in the end. But we can (in the hopefully near future) track time on it, which will also be important. My suggestion would be a variant task. So a variant task you can only add to a task. You can name it, and have all the things setup in the overview. task progress, publish to it. (maybe don’t have someone assigned to it as you’re working from the same file that should be inherited from the mainTask But if you open a variant task from the launcher or the browser, you’ll just open the asset/shot from the parent task and no other project file will be created. I am aware that this can cause issue’s as you’re working in 1 work file, and can alter other versions if not careful (luckily we publish the work file along so we can always revert back) Maybe if variant are present we can have a popup when the program start that you’re working with variant in a single file. Also described here https://community.ynput.io/t/defining-product-variant-ahead-of-time/1368

User

5
💡

Feature requests