you can add the attribute as a custom attribute display >Property> attribute display (even switch off viewing of this data in viewport) but this will always keep your attributes intact. pain in the ass , but is the only way currently a gaurantee.
On 22 March 2013 15:08, James Vecore <[email protected]> wrote: > Here is a video of a plugin I started working on for Softimage. I’m > integrating KrakatoaSR as a renderer into Softimage:**** > > ** ** > > https://vimeo.com/62377510**** > > ** ** > > Please excuse the programmer art. I don’t actually know how to make > anything look good with Krakatoa yet.**** > > ** ** > > Features So Far:**** > > ** ** > > - Integrated as a renderer plug-in using KrakatoaSR’s C++ API > **** > > - Works with ICE driven point clouds**** > > - All Krakatoa supported channels are mapped and pulled from > ice if they exist (Emission, Absorption, etc)**** > > - All parameters in KrakatoaSR exposed in the renderer options > **** > > - Region render support**** > > - Scene lights can be restricted with a group**** > > - Occlusion mesh support (also through a group)**** > > - Multi-channel EXR output supported.**** > > ** ** > > 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**** >
