yes, its aggressive. other renderers have traditional materials applied to surfaces, and if these materials use the attribute shader nodes the ICE data should get pulled. maybe instead of that massive "Shader Options" tab, you could provide actual shaders or a shader compound which you apply to the particle cloud. in that shader compound you would use "Vector Attribute" shader set to point normal, driving the normals port of a "Krakatoa Shader". you can provide these compounds with the default set of ICE attributes to drive the default Krakatoa named channels, this would also allow someone to "repath" a Krakatoa named channel to a differently named ICE attribute. ex. MyCustomVector -> Normal (krakatoa's normal channel).
thanks for your work james, is this to be a plugin for sale through thinkbox? or is it proprietary? or free and open? On Fri, Mar 22, 2013 at 7:08 AM, James Vecore <jvec...@hellopluto.com>wrote: > Now for a real question. While integrating the ICE channel support I > noticed that even if I put a Set Data for an attribute like PointNormal, > ICE will still optimize it away unless it is being directly used for > display or simulation. This seems a tad overly aggressive. My current work > around is to drop a log values before the set data and turn off the logging > which forces the channel into existence. Please tell there is some other > easier way to force a channel to not be optimized away? Or some way from > C++ to force the evaluation of the ICEAttribute. I have to imagine other > renderers would have similar problems with channels that aren’t needed for > viewport display or simulation but are needed for rendering. > > ** > > ** ** > > Thanks,**** > > ** ** > > -James**** >
