Hey Rob, Firstly, if you go ahead and use the ICE menu to do that "Transform Objects By Particles" thing, go ahead and select any of those nulls and do Alt+9 to see the icetree. You will find one per null, as I implied in a previous message.
Secondly, yes, when the xml is loaded you'll suffer the validations, but the problem and Matt's theory is some sort of validation happens on every change so it repeats every time you do something new. Therefore, the theory goes if you load a premade compound of compounds, the parser does all the nodes in one go and the validation happens only once. Either way, like I said earlier, you end up with a tree per null + one more to store the transforms. Cheers, -- Alan On Fri, Jan 11, 2013 at 3:16 PM, Rob Chapman <[email protected]> wrote: > Oh I see, so this is to potentially break the 1200 nulls per minute speed > barrier that Mr Fregtman set with his Python script earlier? > > Nice idea Matt. I wonder how its possible to 'dynamically' create a > specific xml file to disk though. probly in Python - ha! > > And surely when this compound/xml is loaded you will still have to suffer > all those validations and integrity checks anyway? > > cheers > > Rob > > > On 11 January 2013 20:02, Matt Lind <[email protected]> wrote: > >> Whether you generate all your nulls in one ICE Tree or multiple ICE Trees >> is irrelevant.**** >> >> ** ** >> >> The point I was getting at is creating anything in a scene will trigger >> events and other code running in the background to validate and ensure >> integrity of the scene. As the scene gets larger, those checks will take >> longer and take some measurable amount of time. When you create stuff >> iteratively, you effectively re-trigger the same events again and again. >> That time piles up.**** >> >> ** ** >> >> My suggestion to avoid that problem was to dynamically generate an ICE >> compound file (XML) and export it to disc as it wouldn’t trigger any of >> those events, then use the native ICE compound loader to import it into the >> scene. This would minimize the number of events that get triggered, or at >> least streamline them. This is the same principle behind why it’s more >> efficient to duplicate an object ‘n’ times with a single call to >> Duplicate() vs. ‘n’ calls to Duplicate().**** >> >> ** ** >> >> Matt**** >> >> ** ** >> >> ** >> >
