What if you locked it? (Node Hierarchy lock) I think it'd survive as it's typically freeze-proof.
On Fri, Jun 29, 2012 at 6:19 PM, Bradley Gabe <[email protected]> wrote: > Yup, I've had workarounds for the weight map ICE Tree thing for a long > time, which is why I'm not so annoyed by it. But so far, no good workaround > for the Static Kinematic State issue. > > > > On Fri, Jun 29, 2012 at 6:15 PM, Alan Fregtman <[email protected]>wrote: > >> Second thing sounds like a bug, but for the first thing: >> If you know beforehand you'll potentially want to freeze the weightmaps, >> the trick is to store your weightmap data to a custom attribute, then with >> a second icetree *on the weightmap* (just select the map when creating the >> icetree) then you can read your custom attribute and set the weightmap data. >> >> This way if you freeze the weightmap, it will freeze that icetree inside >> it and not the first, so your other effects are safe. :) >> >> >> On Fri, Jun 29, 2012 at 6:06 PM, Bradley Gabe <[email protected]> wrote: >> >>> When a weight map's weight values are being driven by an ICE Tree if you >>> freeze the weight map, it ends up removing that ICE Operator. It would be >>> nice if it didn't do this, because maybe I needed that ICE Tree for other >>> effects, but it's okay because I can understand why that ICE Tree might >>> have to go away in order to freeze the weight map. >>> >>> What makes less sense to me is what happens with custom Static Kinematic >>> State nodes. >>> If I create a custom Static Kinematic State node and then access it in >>> an ICE Tree, freezing that ICE Tree will result in that Static Kinematic >>> State node disappearing. In this case, the property node is feeding the ICE >>> Tree, not vice versa, so deleting it doesn't make sense. >>> >>> Any chance this might be a bug rather than a feature? >>> >>> -Bradley >>> >> >> >
