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 <witha...@gmail.com> 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 >
