Thanks Andy, it's good to hear that a modular approach of discrete functions makes sense programmatically too.
I tend to do it so I can annotate my work as I go along which makes it easier for me to remember when I've solved something before and can reuse it again. On 2 March 2017 at 16:31, Andy Nicholas <[email protected]> wrote: > > I've found working with Wrangles to be easier > > That's great to hear! Yep, as you've obviously found for yourself, there's > really nothing to be intimidated by. Most people are aware of the various > concepts intuitively, it's just that I've noticed the syntax can scare > people off. > > > However I had wondered whether splitting things up into lots of separate > Wrangles > > was less efficient programmatically. Do you have a view on this Andy? > > No, I've not noticed any performance hit, but I've not tried profiling it. > > Each time you do put a Wrangle of some sort down, Houdini will generally > need to create a new copy in memory of the geometry so that you're able to > write your attributes to the new version of the data. But that happens with > most nodes I would have thought, so minimising the number of nodes is > generally a good idea. It would only need one copy in memory each time > though, so there should be efficiency of re-use. Kind of like a double > buffering system where it swaps the buffer each time. The new SOP compiling > feature (http://www.sidefx.com/docs/houdini/model/compile) would in > theory limit any overhead by combining all the compilable nodes before > running. > > Anyway, these are all just educated guesses based on my understanding of > the mechanics of Houdini, so take with a pinch of salt! > > From a stylistic point of view, I much prefer to seperate VEX code into > separate Wrangle nodes so that each node does *one* thing only. It makes it > more robust and easier to manipulate and debug. It's exactly analogous to > coding functions. Big functions that do a lot of things are generally nasty. > > I also find that some operations need to be split, for any/all of the > following reasons: > * For architectural/re-use reasons. E.g. An "initialisation" Wrangle, > a "loop operation" Wrangle, and a "tidy up" Wrangle. > * If I've adjusted the geometry (e.g. by adding points) and now I need > to iterate over all the points again including the new ones. > * If I need to do another operation but looping over a different > entity e.g. a per-point wrangle followed by per-primitive or detail > operation. > > A > > > On 02/03/2017 15:33, Jonathan Moore wrote: > > Disadvantages - If someone else can't code and needs to take over the >> scene, then they're going to have difficulties if they need to fix/change >> things in an individual Point Wrangle... > > > Funnily enough I don't consider myself a programmer. Before Houdini I > generally hacked around with scripts but I'd never attempted anything C > like. > > I've found working with Wrangles to be easier than my preconceptions led > me to fear. I can't say that I'm overly ambitions with VEX but the > motivation of multithreaded optimisations keeps me pushing forward. Plus > lots of bespoke reusable 'subroutines' helps me compartmentalise VEX in a > very digestible manner. > > However I had wondered whether splitting things up into lots of separate > Wrangles was less efficient programmatically. Do you have a view on this > Andy? > > On 2 March 2017 at 15:08, Andy Nicholas <[email protected]> wrote: > >> Heh! Yep, I know exactly what you mean. It's usually a lot faster to >> write the logic in VEX compared to creating a spaghetti network of group & >> attribute manipulation to get what you want. The new compilation system for >> SOPs may help slightly, but it's still a million times faster to prototype >> and adjust in VEX. >> >> It's worth mentioning that after a job finished last year, I had a look >> back through the scene. The project involved a lot of creation and >> manipulation of trail geometry. I'd say that easily 95% of the nodes were >> Point Wrangles. >> >> Benefits: >> * Super fast and automatically multithreaded >> * Each node's function is completely customisable (unlike built in >> nodes) >> * Easy to read and understand intention (compared to the equivalent >> node network) >> * Modularised and reusable code >> >> Disadvantages: >> * If someone else can't code and needs to take over the scene, then >> they're going to have difficulties if they need to fix/change things in an >> individual Point Wrangle >> >> I'm sure there are others plusses and minusses, but that single >> disadvantage can easily be negotiated if you make sure that you don't write >> PointWrangles with hundreds of lines of code, and force yourself to break >> them up into smaller reusuable components - like subroutines. That way, >> they can be treated in the same way as any other standard Houdini SOP. If >> someone else comes in and doesn't like VEX, then it's granular enough not >> to get in the way. >> >> So personally I'm going to keep with VEX, as I can't find a good reason >> to stop ;) >> >> A >> >> > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to [email protected] > with "unsubscribe" in the subject, and reply to confirm. >
------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
