fix: allow empty prefix and unique name

[vincentullmann]

Changelog Description

Allows prefix and unique_name to be left empty

Additional review information

When prefix and/or unique_name was left empty it would create leading underscores in the filename.
This PR adds a shared get_full_product_name method to concatenate the product_name.

It also updates the logic on the publish_nodes side. If a prefix and/or unique_name is provided it will still be used as the filename. If not, the product_name will be used instead.

in the following screenshot:

prefix	unique_name	result
""	""	imageMain/imageMain_0001.png
ayon	ayon	ayon_ayon_imageMain/ayon_ayon_0001.png

Testing notes:

1. set either prefix or unique name to be empty (or both, or neither)
2. publish

[BigRoy]

Conceptually @Sasbom why was there a need for this prefix / suffix juggling to begin with? Isn't that exactly what variant is for to begin with? 🤔 I was always a bit confused about these options and as to why it needed this 'additional layer' of controls.

[Sasbom]

Conceptually @Sasbom why was there a need for this prefix / suffix juggling to begin with? Isn't that exactly what variant is for to begin with? 🤔 I was always a bit confused about these options and as to why it needed this 'additional layer' of controls.

The whole reason why I added this is to make sure there is as little ambiguity when naming a product. The secondary prefix is optional, but when I saw artists use this tool, they were exporting lots of passes to disk, which is why I thought that it would be best if i enforce a unique name, to prevent collisions and make sure that everything is clearly labelled, as the names of the nodes are used to look them up during collection and other processes, if I recall correctly. The unique identifiers Comfy gives them have been shaky for me, i personally haven't found them to be as reliable to match with.

I suppose that'd be a bit overboard if you are only generating one image though, but I feel like in production that's often not what you end up doing, so allowing the artist the freedom to publish data that has little by way of labeling attached to it namewise, to semantically distinguish it from others, would cause a lot of chaos.
Variants don't quite cut it, since sometimes youd want to use that for essentially different assets, when I see prefixes as mostly what AOVs are in more traditional contexts (except in AI image generation this is way less standardized of course), as sometimes people would for example generate a depth estimate, outlines and a style transfer, hence the 2 prefixes, one to denote an identifier name and one to denote some additional info, like 'snailVideo_Zdepth_videoMain_v001.mp4'

That's just my 2 cents on the matter, based on what I have seen. I'm sure it can be structured better, i'm curious to see if we can restructure this a bit better.

[Sasbom]

As stated in my earlier comment,
The original intent was to enforce distinct naming for products, since they often can't be derived from the filename / task alone,
e.g. it seems common to generate multiple products and to export these.
Also, distinct naming helps with collisions, since if I create a node in the scene for publishing, I can only keep track of it if it has a unique name.

It can happen that due to some bugginess, an existing ayon save node of the same name might exist in the graph, and because the logic in JS matches against names and node types, creating a new node will indeed create a new node and product, but then not properly update the one with the correct name, instead making one with <nodename>1 (since node name overlap isn't allowed). Then you end up with 2 problems:

• The context set on the new node is correct but it expects to have a different name
• The old lingering node has semi-reentered the context but without the proper matching imprint info

Did you find this to get in the way? How do you use ComfyUI? I myself am only a very light user, really only for the development of this plugin, so I'm very interested in how you use it.

[vincentullmann]

@Sasbom

I will have to check back with the artist who was testing this, but from what I understand, we're trying to match the product names and overall user experience as close as possible to what users are already familiar with from other applications.

our product names (in most cases) follow the template: {product[type]}{Task[name]}{Variant}{optional_suffixes}
for example cacheAnimationMain or renderLightingFG_aovName

Our initial idea here was to make prefix and unique_name optional and define the full name, including any suffix as the "variant". For example: variant="mainSnail_Zdepth -> product_name=renderAiMainSnail_Zdepth

Since you've mentioned the parallel with aov:
I'm wondering whether we could make "prefix" and "unique" available as tokens that can be used in AYON product name templates. That would studios to add them in whichever position of the name they like, such as: {product[type]}{Task[name]}{Variant}<_{unique_name}>

[Sasbom]

@vincentullmann

Since you've mentioned the parallel with aov: I'm wondering whether we could make "prefix" and "unique" available as tokens that can be used in AYON product name templates. That would studios to add them in whichever position of the name they like, such as: {product[type]}{Task[name]}{Variant}<_{unique_name}>

I see, thanks for explaining!
That's exactly the inverse of how I've seen people work at our place, so I think It'd be good to remain flexible.
If you're using variants for this, name collisions shouldn't be an issue!

@BigRoy Things seem fine on my end!
I'm gonna approve.

[Sasbom]

After explanation, I understand the motivation behind this.
Having the 2 prefixes be optional would have things be as flexible as possible for more workflows.

[tweak-wtf]

just chiming in to let u know that i'm running this since yesterday morning and so far had no complaints :)