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 >> > >
