RFE: New OP Type: "Clone OP"

Wishlist and RFEs
1

TL;DR: I wish I could clone OPs so that I could edit the parameters of several same-type OPs without too much setup/clicking.

Sometimes when I’m modelling with SOPs inside of a single Geometry, I need to reuse copies of identical Transform SOPs to, get a bunch of pieces to transform to the same height/scale, or offset a bunch of pieces the same amount. To that end, I just copy paste Transform SOPs. But if I need to adjust many pieces at once, I have to select all the identical Transform SOPs, and edit their parameters in bulk (or one by one).

  • Since I am going to be instancing this Geometry, I cannot use nested Geometry or parenting to achieve this group effect.
  • Since I need different materials on the various SOPs, I cannot use merging, as the Materials SOP does not support Groups.

There may be approaches to achieve this I’m not aware of, but that’s why I’m wishing I could use single-OP cloning.

Imagine being able to have a normal Transform SOP which would act as the source/master, and any number of ‘cloned’ Transform SOPs made from it, such that when I change any parameters on the master, the clone OPs update accordingly. And like COMP cloning it would be cool if I could then ‘break off’ a clone (ie. disable cloning) to make a clone independent later.

I’m suggesting that this idea could be applied to any kind of filter (ie. non generator) OP which is typically tweaked as part of workflow: Transform SOP, Math CHOP, Transform TOP, etc. But mostly I find I’m wishing for this with Transform SOPs, since it’s annoying to have to use multiple Transform SOPs to affect pieces as a group, but it’s less annoying than setting up binds/references between Transform SOPs.

This ‘Clone OP’ type would only need two pars probably: Source OP and Make Unique

I also know I could also make some kind of Component based solution but there’s something nice about just laying down a bunch of native, off the shelf OPs. I love the Clone functionality of COMPs. I wish I had the same for single OPs.

Maybe there are other use cases for this idea as well?

2

I know you mention “binds/references” but I feel like Binding is so close to what you’re asking for that cloning would be a bit redundant in this case. I have had this same thought myself, and maybe one time there was a legitimate use-case - but I can’t remember exactly any specific “ah-ha” that sticks out in my mind. Most cases for me are either solved by binds or would be solved by being able to set default parameter values on single ops

The nice thing about binds over references is that you can modify the parameter on the original op OR any of the bound parameters in the other ops and they will all change - so you don’t ahev to go back and find that original op. Just change it anywhere to change it everywhere.

Your workflow (which I feel is practically identical to what cloning would be as far as number of actions / clicks) would be to copy an op, bind the desired parameters in the second op to the parameters in the first one, and then just copy - paste that second op ad infinitum. The bound parameters will continue to point to the first op and now you can modify the bound parameters in ANY of the copied ops.

Yes maybe something that binds ALL the parameters at once would be quicker in some cases, but also I feel like most cases you would only want a sub-selection of parameters to be bound to eachother more often than wanting ALL parameters to be bound. At least that is often the case for me with Transform SOPs like you mention. (Another method is to merge before texturing, do Transforms in one SOP, and then split later by groups or primitive numbers)

3

Thanks for your reply Pete. I hear what you’re saying, and you may very well be right that Derivative envisioned Binding to be the extent to which TD facilitates linking filter-type OPs. I don’t presume that to be the case, which is why I think it’s worth asking.

Not if you have to bind 4+ transform/rotate/scale pars

Those are the kinds of cases I’m thinking of. It would really be a couple of clicks versus however many to set up binds/references, in addition to the cognitive strain and workflow interruption of doing so. Laying down OPs, for me, is always less brain-pain than referencing/binding, both in terms of initial setup as well as in terms of reviewing your own work down the line. For me, it’s typically easier to see it visually laid out rather than having to look at what’s bound to what inside of parameters. Lastly, knowing that it’s all the pars and not just some has its benefits, in that it’s immediately clear just by seeing that it’s a full clone.

That’s a good point. Perhaps this ‘Clone OP’ should be able to send values back to its master op like a bind.

That’s a lot of setup and mental earmarking, compared to just using a hypothetical cloned Transform OP. I’m specifically imagining a fewest-possible-clicks solution to having filter-type OPs as cloneable as what the Select OPs do for cooked data, and what COMP Cloning does for infinitely complex components. Not only would it be easy to set up, but it would be easy to move around in the network without having to open parameters or rely on multiple additional other type OPs.

For me, the case for a Clone OP is strong outside of just Transform SOP. As I mentioned, I could see myself using it for all kind of filters, such as Math CHOP, HSV Adjust, Levels TOP, anything that affects data flowing through it.

I love that I can ‘clone’ generator-type OPs using Selects. I use that all the time to spread data around my project which I need globally, but I have no equally-quick way to do it for filter-type OPs, which in many cases are themselves an asset that needs to be re-used across the project.

I would also argue that part of the reason it’s hard to remember needing such an OP is because we simply haven’t had it. There are many OPs that I didn’t know I was missing until discovering them.