I have two assets, one inside another.

Is there any ideological reason not to allow to edit contents of “internal” asset without making “parent” asset editable?

I understand I can't change values of input parameters of internal asset in this case, but it's not always needed.

If it would be possible it will help to prevent any accidental edits of parent asset when you don't want to.
It's especially important when you have many assets inside each other and want to edit bottom one “in place”. You have to open for edit all it's parent assets…

to me it seems more logical because you'd be changing something inside the asset .. I've been making a new instance of asset I want to edit in a different screen/work window and editing it there, it will update as soon as the changes are applied.

I don't see the point there, because if I can change contents of that internal asset by creating it separately, why I can't do so directly in place?
Assuming each asset as a “blackbox”, I don't change contents of parent asset by editing of child one.
For example, if I am fixing a bug in a hand rig asset which is inside character asset, I don't edit a character directly - so why should I open it for edit?
These character assets opened for edit just in case to edit internal assets cause sometimes losing of changes in multiuser environment, when one changes that character asset, saving changes, and the other one, who opened character asset just to make changes in other internal asset saving changes in main character (overriding the actual changes made by other user) just because it can't remember if he actually edited this main character asset or not.
If he would be allowed to edit internal asset without opening parent asset to edit, it would be much clearer, because he will open this parent asset for edit only when he actually wants to change it's contents.

Makes sense to me, and sounds like a good idea.
I wonder if it is very difficult to impliment though.

I agree too, actually. It would be very convenient and probably help clarify what is actually going on. It does seem unnecessary to engage editing in the container network.

Suppose you have asset A that contains asset B. Asset A and B are both locked to their definitions. This means that a hip file that contains asset A only needs to save out the top level parameters for asset A. It doesn't need to save out anything about the contents of asset A. Similarly, the definition of asset A saves out the top level parameters of asset B, and nothing about the contents of asset B. The contents of asset B are saved as part of the definition of asset B.

So now you want to change asset B inside asset A. If I understand correctly, you aren't talking about chaning the definition of asset B. You just want to change the contents of the particular instance of asset B that exists inside asset A. In other words, you want to change things such that asset A no longer contains a locked asset B, it now contains a modified asset B. This very much changes this instance of asset A.

This of it this way: where would the modified asset B contents be stored? If asset A is locked, then they aren't going to be stored in the hip file (because when saving a hip file, or an asset's contents, we stop saving the hierarchy when we hit a locked asset). One of the primary principles of HDAs is that one locked instance of an HDA contains exactly the same nodes that another locked instance of that HDA contains. For your locked asset A to contain this modified asset B, the modified asset B must be saved as part of the locked contents of asset A. If you want to modify asset B without changing the definition of asset A (without changing the locke contents for asset A), then you must also unlock asset A. And this argument can be extended recusively to any number of levels of nested assets.

This is why you can't unlock asset B without first unlocking asset A.

Mark

Actually, I believe we're thinking about this way (correct me if I'm wrong, mlesin):
A contains B, yes. We basically want to modify the network inside B only, and Save Operator and then set B back to “Match Definition”. It seems that we've never touched any node (wiring or parm settings) of an node that A is reponsible for; so why do we have to unlock it?

So, in a parallel sense; if we have node of type A (with B inside) created somewhere, we could just instantiate just a node B elsewhere and make our changes and hit “Save Operator”. The node A would never be unlocked, kind of proving our point that B *can* be editing without unlocking A- the problem here being that doing exactly this is an impractical, awkward and unintuitive workflow.

However back in the current reality, I understand that the mere act of unlocking B would require “read/write” access of its container network so I think in order to make this whole scenario possible, there would have to be an additional rule implemented where a container (A) would have all its contained objects locked *except* for other HDAs (B). I think this logic makes sense but I'm probably not seeing it totally clearly.

It might be an awkward-to-implement subtely, I don't know… but quite handy. An ideal HDA pipeline should support some permssions and it might happen that an artist would not even able to unlock A, but should have full write permissions to B.

I see it was done this way for a storage of modified assets, thanks for detailed exlpaination, mtucker.
I understand it may not fit current implementation, but for my logic it's not good to store modified(unlocked) asset B inside locked asset A.
As for me - saving of modified assets is needed for storing intermediate results, but not result that will be used in a production environment, so I see only one good place for storing them - is current hip file.

BTW, the other thing related to fixing bugs in assets already used - I can't add new parameter to asset without saving it - imagine I have not working asset yet, but I need a new parameter, when I add it - I'm storing not working asset to anyone who uses it… So the only way to workaround this is to make asset Embedded, which is equal to store asset in a hip file.

So why not to store all modified assets in hip file automatically, even for parameters change, and only store them back to .otl when we hit Save Operator?

I'm a real advocate of obeying the structure and workflow of HDAs and OTLs…
we've been using them for a long time, 2-3 levels deep and have found that while, yes, it is sometimes desireable to be able to edit an HDA inside another HDA without having to unlock the parent node…
BUT
this can and will come back to haunt you…

the original post mentioned editing B without editing A…
you can unlock A, then edit B, then simply match A to it's definition in Houdini right now…A will lock and will contain the new B…no problem.
the prblem comes when you're working with others…
if you edit B to your needs - what's to say that the guy beside you doens't need B to be the way it was before?…you've just ruined his shot…

the best way to get around this is with same kind of version control…
assetA.otl > assetA.v00001.otl, assetA.v00002.otl assetA.v00003.otl etc
assetB.otl > assetB.v00001.otl, assetB.v00002.otl assetB.v00003.otl etc

this way you can make a change to assetB but retain the history of changes for other shots or other artists…
it may take a bit of work to set up but it's worth it…

I guess it really depends on who you are and how you work…for the individual artist it's not really a big deal to be able to edit anything you want…for a studio it's more important to do things right.

you can make a version control system in Houdini right now…no 3rd party stuff required….and with python in H9 this will be simple…and I'm sure someone will write a simple one and offer it to the community at some point…

ps…
when developing an HDA, it's best to work with a ‘local’ copy - not the real main working copy…this way you can do whatever you need to do with the ability to save it without endagering anyone elses work…

we have at times needed to edit and internal HDA /without/ adding it to the version control system and sending it all the way through the pipeline…it /does/ work…you just have to secretly cross your fingers and not tell anyone :wink:

mlesin
I understand it may not fit current implementation, but for my logic it's not good to store modified(unlocked) asset B inside locked asset A.

It's not only the question of where the modified asset is stored; it is also the question of consistency. The locked asset should consistently mean that nothing about it is modified and that it behaves exactly according to its definition.

If the definition of an asset A contains a locked asset B, then any locked asset A should behave as if the asset B is locked.

Violating this principle can lead to a frustration of having two instances of locked asset A behaving differently because each has own version of an asset B edited internally. Such edits could potentially be hidden deep inside nested HDAs, which would be nearly impossible to track down and debug.

Unlocking and editing a nested asset B can affect the behaviour of an asset A even if the networks of the asset A are not changed.

Rafal

Everything you say is correct you don't want to be looking at what appears to be a locked asset when in fact it contains an unlocked one inside. However surely this is problem that is very easily solved in the same way the unlocked ones are now, just colour it differently and some information to it that tell the user it contains an unlocked instance of asset foo.

The real need for this is really so you can store edits and curve sops and other data that isn't fully procedural.

I don't think the arguement that its possible to break networks by allowing it is a very good one. There are already tons of ways of breaking things if you don't bother thinking about what you are doing this would just be another case where its a power feature that comes with a massive use with caution sign on it.

In fact, the reason of appearance of that topic is lying in case of loosing a data when two guys are unlocking one parent asset but only one of them doing actual changes in that parent asset. Then both of them are saving that parent asset, the other one can do so just because he may not remember if he did any changes in that asset, overriding changes done by first one.
The best solution IMHO for that case would be some kind of built-in version control with a detection of such conflict situations and asking user to resolve it somehow, like creating other copy of asset with differences highlighted or something like that.
At least a warning about asset you gonna save was already saved by anyone else since your last unlock would help a lot.
And then, there will be no need to talk about unlocking assets in locked assets IMHO

mlesin
In fact, the reason of appearance of that topic is lying in case of loosing a data when two guys are unlocking one parent asset but only one of them doing actual changes in that parent asset.

One way to avoid such conflicts, is for the artist working on the ‘child’ asset B to create a separate instance of it outside the parent asset A. Then unlocking and modifying that new instance of the asset B does not infringe on the asset A in any way.

rafal
One way to avoid such conflicts, is for the artist working on the ‘child’ asset B to create a separate instance of it outside the parent asset A. Then unlocking and modifying that new instance of the asset B does not infringe on the asset A in any way.

IMHO that could be quite difficult when I want to edit 3rd or 4th level asset in that hierarchy…

mlesin
IMHO that could be quite difficult when I want to edit 3rd or 4th level asset in that hierarchy…

Yes, indeed, it is more involved than unlocking B without unlockin A. However, for most assets you should be just able to either copy/paste it or instantiate it at the manager level (eg, /shop for shaders, /pop for particles, etc) and edit it there.

Simon
However surely this is problem that is very easily solved in the same way the unlocked ones are now, just colour it differently and some information to it that tell the user it contains an unlocked instance of asset foo.

That's true. But if it is possible to avoid the problem, it's better to do so.

Simon
The real need for this is really so you can store edits and curve sops and other data that isn't fully procedural.

I see. Very good point. But, again, if it is possible to store such data without the need to deviate form the HDA definition, than that's the way to go. For example, maybe there is a way to incorporate such changes into the top level HDA in a way that we change parameters only at the top level and link them to the internal nodes; maybe we could store such chages at the top level and link them to the nodes inside, as well. However, it is hard a problem and what i just described may not be feasible.

Simon
this would just be another case where its a power feature that comes with a massive use with caution sign on it.

but it would be really cool if the power feature could come with a massive use and without any caution signs

rafal

Simon
The real need for this is really so you can store edits and curve sops and other data that isn't fully procedural.

I see. Very good point. But, again, if it is possible to store such data without the need to deviate form the HDA definition, than that's the way to go. For example, maybe there is a way to incorporate such changes into the top level HDA in a way that we change parameters only at the top level and link them to the internal nodes; maybe we could store such chages at the top level and link them to the nodes inside, as well. However, it is hard a problem and what i just described may not be feasible.

Well if you can think of a way I can have a curve sop inside an asset and still add and remove points from it as well as edit the position of the points and all in a locked asset then great I'll take that