> > 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 <a...@andynicholas.com> 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 > > > > On 02/03/2017 14:39, Tim Bolland wrote: > > That's really helpful Andy, and I'm liking the nod to strand arrays on > points. Since starting to learn Houdini I feel I'm spending most of the > time in Vex, this isn't a bad thing but I'm constantly wondering if I > should be trying to do things via VEX/VOPs or by the prebuilt nodes. I > guess there is no hard answer to this, my assumption is embracing a Vex > workflow will allow you to customize more down the line. > > > @Jonathan > > Thank you, I didn't know that and I'll try it out. For something like > Andy's example I would expect to solve the trails, but for something like a > solid mass of non-animating strands I try to keep things in the modelling > stack (to borrow an XSI term [image: 😉] ). > > > Cheers! > > Tim > > ------------------------------ > *From:* softimage-boun...@listproc.autodesk.com > <softimage-boun...@listproc.autodesk.com> > <softimage-boun...@listproc.autodesk.com> on behalf of Andy Nicholas > <a...@andynicholas.com> <a...@andynicholas.com> > *Sent:* 02 March 2017 14:12 > *To:* Official Softimage Users Mailing List. https://groups.google.com/ > forum/#!forum/xsi_list > *Subject:* Re: [Houdini] Working with strands the Softimage way > > Hi Tim, > Here's a VEX example: > http://www.andynicholas.com/download/vex_trail_example.hip > > I've kept it super simple to make it easy to expand on. It should be a > great way to get familiar with VEX too. > > Let me know if you have any questions. > > A > > > On 02/03/2017 13:34, Tim Bolland wrote: > > Thank you! Really cool :) > > > ------------------------------ > *From:* softimage-boun...@listproc.autodesk.com > <softimage-boun...@listproc.autodesk.com> > <softimage-boun...@listproc.autodesk.com> on behalf of Christopher > Crouzet <christopher.crou...@gmail.com> <christopher.crou...@gmail.com> > *Sent:* 02 March 2017 13:25 > *To:* Official Softimage Users Mailing List. https://groups.google.com/ > forum/#!forum/xsi_list > *Subject:* Re: [Houdini] Working with strands the Softimage way > > If it can help, here's a basic scene showing one common approach for > making strands: https://filebin.net/6ml27y3atb6qd7iq > > > On 2 March 2017 at 20:17, Tim Bolland <tim_boll...@hotmail.co.uk> wrote: > >> Thank you Andy that's a really helpful summation, I'm going to give it a >> go :) >> >> >> ------------------------------ >> *From:* softimage-boun...@listproc.autodesk.com < >> softimage-boun...@listproc.autodesk.com> on behalf of Andy Nicholas < >> a...@andynicholas.com> >> *Sent:* 02 March 2017 13:12 >> >> *To:* softimage@listproc.autodesk.com >> *Subject:* Re: [Houdini] Working with strands the Softimage way >> >> >> Just to confirm how I'm thinking about this, a strand in Houdini is >> typically made up of point positions, not points with arrays as attributes. >> You can manually add an attribute to each point position to say which >> strand it's part of, there's a node that generates lines that will >> then understand this? >> >> >> What I'm saying is that's something you can implement yourself. There are >> no nodes in Houdini that understand a point with a vector array is a >> strand, and no shaders that will do that automatically either. Again, you >> can build that yourself if you like, but it's quite advanced if you're >> going to be delving into procedural geometry shaders. >> >> Otherwise you can create polyline primitives and feed point IDs into it. >> This will generate a polygon line (polyline) between the vertices in the >> primitive, and in some ways this is just like the point[pointarray] >> technique. >> >> >> Yep. A polyline is nothing special. Just an unclosed polygon. As others >> have pointed out, you can apply attributes to the points to set things like >> width and color. Or you can use something like the PolyWire SOP to generate >> your own rendertime geometry. >> >> The key is how do you create these point clusters and the order. In ICE I >> would make strands using a build linearly interpolated array with two >> vectors feeding into it. I guess I could try and recreate this using >> vex/vops, and maybe that's what I'm after, I just need to find a way to >> manipulate all these points in the right order. >> >> >> Easiest way (assuming you already have some animated points) is to use >> the Trail SOP with it set to "Connect as Polygons", turn "Close rows" off, >> and set "Trail Length" to something like 10. Next stop after that is to >> take a look at the Resample SOP. Especially the "Treat Polygons As" >> parameter, as that'll let you create interpolated shapes to your trails >> which is kind handy. >> >> A >> >> >> >> >> On 02/03/2017 12:58, Tim Bolland wrote: >> >> That's a good point Andy, and in my mind this would make the most sense! >> But like you say maybe not the most supported. >> >> >> Just to confirm how I'm thinking about this, a strand in Houdini is >> typically made up of point positions, not points with arrays as attributes. >> You can manually add an attribute to each point position to say which >> strand it's part of, there's a node that generates lines that will >> then understand this? >> >> >> Otherwise you can create polyline primitives and feed point IDs into it. >> This will generate a polygon line (polyline) between the vertices in the >> primitive, and in some ways this is just like the point[pointarray] >> technique. >> >> The key is how do you create these point clusters and the order. In ICE I >> would make strands using a build linearly interpolated array with two >> vectors feeding into it. I guess I could try and recreate this using >> vex/vops, and maybe that's what I'm after, I just need to find a way to >> manipulate all these points in the right order. >> >> I'm rambling a bit here, but hopefully getting somewhere! >> >> Cheers, >> >> Tim >> >> ------------------------------ >> *From:* softimage-boun...@listproc.autodesk.com >> <softimage-boun...@listproc.autodesk.com> >> <softimage-boun...@listproc.autodesk.com> on behalf of Andy Nicholas >> <a...@andynicholas.com> <a...@andynicholas.com> >> *Sent:* 02 March 2017 12:27 >> *To:* softimage@listproc.autodesk.com >> *Subject:* Re: [Houdini] Working with strands the Softimage way >> >> Hi Tim, >> Did you notice that you can do per-point array attributes in VEX? There's >> nothing stopping you setting up position vector arrays on each point, just >> like in ICE, and then using a Point Wrangle at the end to use that array to >> generate a polyline. The problem is that you then have to write all those >> handy ICE nodes like "Simulate Strands", etc. yourself. >> >> That's why generally, you're better off just trying to use polylines as a >> primitive as they're more supported by Houdini's other frameworks (e.g. >> wire solver) and constraints. >> >> A >> >> >> ------ >> Softimage Mailing List. >> To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with >> "unsubscribe" in the subject, and reply to confirm. >> >> ------ Softimage Mailing List. To unsubscribe, send a mail to >> softimage-requ...@listproc.autodesk.com with "unsubscribe" in the >> subject, and reply to confirm. > > -- > Christopher Crouzet *https://christophercrouzet.com* > <https://christophercrouzet.com> > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with > "unsubscribe" in the subject, and reply to confirm. > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with > "unsubscribe" in the subject, and reply to confirm. > > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com > with "unsubscribe" in the subject, and reply to confirm. >
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
