Sorry if I missed this, has the “return to original value” been added? If not, any idea when that might happen?
The wedging is great but without being able to return to the original parm value(s) when you deselect the TOP work item, we'll have to write in a bunch of workarounds that we'd rather not
17.0.229 Linux
Cheers,
peter B
Cheers,
Peter Bowmar ____________ Houdini 20.5.262 Win 10 Py 3.11
I am not sure if this addresses your question, but in “push” mode you sort of have that option.
If you are setting a Target Parameter to push wedge values to when you cook, you have the option of (not) overwriting the target parameter. This might give the results you are looking for, but with the trade off of not being able to conveniently preview the effects of the wedge.
I believe Peter is talking about the mode that would potentially work similar to CHOP export overrides so while previewing or cooking it would override target parameters (with some visible highlight like CHOPs do), however otherwise they would revert to the original parameter value or expression or whatever is otherwise driving them so that one doesn't have to sacrifice the ability to preview nor risking overwriting the values permanently I'm too impatiently awaiting progress on this front
Target Parameter is (IMO) the only mode that is useful, and clicking on each work item to preview is slick and highly useful.
The only problem that prevents it being used for production work is the lack of “memory” in terms of what was the original value. Without that, the “wedge” stuff requires a lot of scripting and fiddling and basically one-direction throwaway .hip files.
The reason for the above is that when an artist wants to wedge something, they won't want to spin up a new forked .hip file just to do their wedges, they'll want to work in their production file. However erasing the values they've already got just to test new ones (which is what the current Target Parameter system does) is too fragile to risk.
The CHOPs “override” system would be ideal of course, since the mechanism is built-in, and well understood in Houdini. However if that's not feasible for some reason in PDG, something similar is needed. IMO
Cheers,
Peter B
Edited by pbowmar - April 26, 2019 11:06:01
Cheers,
Peter Bowmar ____________ Houdini 20.5.262 Win 10 Py 3.11
pbowmar The CHOPs “override” system would be ideal of course, since the mechanism is built-in, and well understood in Houdini. However if that's not feasible for some reason in PDG, something similar is needed. IMO
CHOPs doesn't support strings, of course - which may hamper wedging a bit. Granted not in most cases, but some.
But yes, a non-destructive and easy-to-setup means of wedging would be ideal.
Wedging with TOPs was designed around the idea that the the value(s) that matter are described by the Wedge node itself, not specified in the nodes being wedged. For example the “real” value might be set as the center value in the Center/Offset wedging mode, or specified among the list of values using the Value List multiparm.
We've discussed the value restoring issue quite a bit internally, and I don't think it's feasible for us to integrate the overriding mechanism used by CHOPs with TOPs. One thing that could be done is to stash the “original” value somewhere. Work item selection could, for example, save the current value of the target parm to an attribute and then restore it back on de-selection. Alternatively, the target parm value could be saved to the wedge TOP itself when the target parameter field is set, with a button to re-capture the target parm value on demand and a button to restore defaults.
this is very sad to hear and makes it almost unuseable for production in the current state due to destructive nature CHOPs were just an example, if that tech is not feasible, anything similar will do
- the problem with “restoring the value” is that it is not just the value that needs to be restored, but the whole original driver, whether it's a simple value or expression, keyframes, CHOPs, Takes, etc… so it has to be robust
- main issue for production is that houdini network destructively overriden by a TOP network becomes “corrupted” not only when run manually, but also for any other possible TOP network setups that were using the same houdini network, but were overriding another parameters and were relying on “corrupted” parameters to stay exactly as they were originally TOP overrides have to be able to non-destructively modify the setup to be reliable
- how would you override parameters inside of locked assets currently? CHOP overrides are powerful enough to do that, even takes, if TOP wedge overrides could do that, it would be insane boost for productivity
Tomas has nicely summarized the issues, hopefully this can be addressed soon
BTW, could you please point me/us at the Python that is executed when you click on a Work Item. Hopefully I'll have time to have a play around with it
As Tomas says, the actual parm (including expressions etc) should ideally be captured when the override happens. As you suggest, saving all that to perhaps the localDict on each node maybe could work?
CHOPs is still the ideal solution, curious why you don't think that will work? Just create a hidden (maybe?) CHOPnet, and clicking a work item sets the values for each parm, and turns on the Export. If no work items are clicked, the Export is turned off.
Cheers,
Peter B
Cheers,
Peter Bowmar ____________ Houdini 20.5.262 Win 10 Py 3.11
pbowmar CHOPs is still the ideal solution, curious why you don't think that will work? Just create a hidden (maybe?) CHOPnet, and clicking a work item sets the values for each parm, and turns on the Export. If no work items are clicked, the Export is turned off.
while this can be thought as a temporary solution, it would not be ideal for several reasons - CHOPs would try to unexport current CHOP driver of the parm if the parm is currently driven by CHOPs, and then it would not revert it back - CHOPs are great for exporting numeric values, but get convoluted for exporting strings, and while if hidden behind the scenes it may not matter, still feels like there should be new, modern and more advanced approach for parameter overrides that can be then utilized in all houdini
What if you use the take system for a kind of a PDG shadow mode. Ie create a take with PDGwedge name, then include all the attributes you want to wedge and add the @wedge_this_1 , @wedge_this_2 etc in them. If you use TOPSOP, it can be more straightforward/convenient (they bugfixed, so it seems stable at first try), and you can also include it's bypass flag in the PDGwedge take, and switch off in the Main(however it does nothing, but good for visual feedback).
xilofoton What if you use the take system for a kind of a PDG shadow mode.
This sounds very much like the suggestion I made during the beta: constructing temporary takes to push wedge values onto parameters.
The only potential drawback is some crufty takes to clean up in case of interruption and potentially some setups might fail if they are trying to Parm.set() something while inside a Take, maybe?
Take based workaround would get more tricky in case the scene already uses takes and some ROP TOPs or Fetched ROPs are set to Render With Take
that's why I think is important to have first class robust parameter override system that TOPs can use especially if it'd allow priorities so that we can use it generally within all Houdini to replace certain take and CHOP based override setups and still use it for TOP wedging overrides with the highest priority to override even those (I think C4D xpresso is a great example in terms of how it handles parameter or xform overrides, priority groups and intrinsic priorities of overrides in case the same parameter is read and written to with the same or multiple networks without producing infinite loop errors, etc)
So, I think it's clear this functionality is required. The actual implementation matters too but in the short term, how can we get this going even with some temporary solutions?
Cheers,
Peter B
Cheers,
Peter Bowmar ____________ Houdini 20.5.262 Win 10 Py 3.11
A solution that uses the stash/restoring on the Wedge TOP has already been implemented. We're just testing it internally, and I aim to have it available in 17.5 in the next few days. It works as follows:
When selecting a target parameter for a wedge entry, the value of that parameter is automatically stashed on the Wedge TOP. This is done so that the value isn't lost if the work items are dirtied, for example. The Wedge TOP has buttons to manually restash the value, restore the value for a particular parameter, or restore all values accross all wedge entries.
When selecting a work item, the target parameter value(s) are overwritten by the wedged values on that work item. When the work item is deselected they're automatically restored from the value(s) stashed on the wedge node itself.
