Yep! Still reading :) Here’s the link to the cheat sheet as it didn’t come through in your email: http://www.andynicholas.com/?p=1344
> I think it would be brilliant if he updated his Cheat Sheet for these post > HScript days. They're expressions, not HScript, or am I misunderstanding what you’re getting at? Anyway, if you have suggestions about what you’d find useful from an updated cheat sheet, then by all means let me know. I did start looking at making an update, and made a couple of mind maps breaking down the most popular SOPs and expressions into categories. I'll can post that when I next get a chance. A > On 21 Mar 2017, at 19:07, Jonathan Moore <jonathan.moo...@gmail.com> wrote: > > I think Andy covered off most stuff. The only thing I can reiterate is the > importance of VEX. I shared a link the other day to the VEX masterclass with > Jeff Wagner and had positive feedback from other XSI alumni on this list. If > you haven’t watched it yet, you should. It makes sense of many of SideFX’s > design decisions. > > Ultimately Houdini is an operating system for 3d and becoming comfortable > with VEX and Python within Houdini are mandatory things. SideFX might like to > market Core as a replacement for XSI but VEX in particular and Python (if you > want create portable assets) are essential ingredients in getting the most > out of Houdini. > > I came to Houdini with a hackers knowledge of Python scripting and competent > Processing (which I suppose is Java) skills. Never learnt C++ and I certainly > wouldn’t classify myself as a programmer; and I find I’m comfortable with > VEX. Sure I have the help browser opened permanently on my second browser the > check my function arguments, but I muddle along without pain most of the time. > > If Andy’s still reading, I think it would be brilliant if he updated his > Cheat Sheet for these post HScript days. When I was first learning Houdini it > was a huge help. And funnily enough even though HScript has mostly been > discarded, the list of ‘essential’ SOP operators Andy listed back in 2011 are > just as relevant in 2017. <>😉 > > > From: softimage-boun...@listproc.autodesk.com > <mailto:softimage-boun...@listproc.autodesk.com> > [mailto:softimage-boun...@listproc.autodesk.com > <mailto:softimage-boun...@listproc.autodesk.com>] On Behalf Of Jason S > Sent: 21 March 2017 18:36 > To: Official Softimage Users Mailing List. > https://groups.google.com/forum/#!forum/xsi_list > <https://groups.google.com/forum/#!forum/xsi_list><softimage@listproc.autodesk.com > <mailto:softimage@listproc.autodesk.com>> > Subject: Re: Random Thoughts about H. > > > Hi Andy, > > Thanks for the feedback! > >>> - Can handle lots of objects or elements and a few things became very much >>> faster in recent versions (multi-threaded or openCL) >>> (SI is still is king for sheer high-poly-count on fewer objects, which >>> includes *tons* of island transforms) >> >> Have a look at packed primitives. You can chunk your geometry into sections >> and get excellent performance there along with deferred rendering. >> >> For island management, then there are workflows that use the "name" string >> primitive attribute to differentiate between pieces. Some SOPs support this >> (see clustering and fracturing for example). >> > > Indeed I'm aware of packed prims, and I already agreed with you there (was in > the "Good!" section :P ) > > >>> Elements seem to be either inside OR outside, or object level elements >>> (where regular parenting happens) are almost like separate scenes >> >> Not sure I completely understand your point. I've not had an issue with >> referencing data or geometry. You can use the Object Merge SOP to pull >> geometry from anywhere though, and you can use expressions and VEX to pull >> info from other objects too (although I'd generally recommend object merging >> them for clarity). The convention (as you've probably seen) is to use a Null >> SOP called something like "OUT_Geometry" for example, or to use an Output >> node, and then reference those from another object. That has the advantage >> of being able to insert more nodes before the referenced node, so you don't >> have to update all your references. >> > > I know about merge sop, but is it possible to refer to outputs or elements > located in other object level networks? > (or having object level items used as inputs for multiple other object level > networks?) > > >>> - ICE equivalence (personally my biggest gripe) >>> Wished for one thing, that Vop nets allowed for subnetworks with custom >>> port names, >> >> This is possible, but you need to create a digital asset to do it. Kinda >> painful as a workflow, but it is there. >> >> >>> If that's at-all realistic, as it would probably involve very systemic >>> changes, like how/when compilation happens (?) >>> (to allow time dependancy inside vops, but I don't know) >> >> You can have time dependancy inside VOPs, you just need to use the Time >> input from global variables, rather than use $FF inside expressions. >> > Thanks, also I think promoting parameters allows for time dependency? > But I was referring to time dependency as what could prevent entire processes > to be self contained inside a single VOP net. > (or one of the things) > > >>> everything (such as different settings or where to adjust different >>> things) is all over the place >> Yes, it can be, which is why it's crucial to try to be as organised as >> possible and work in a consistent way. If there's an occasion you can't be >> consistent, then put down a post-it note in your network to document it for >> when you or someone else comes back to the scene. >> >> >>> --- expressions :: >>> even if often very simple, driving values with more elaborate >>> procedures, >>> requires equally more elaborate expressions with often somewhat >>> cryptic and sensitive syntax >>> with single or two letter functions that can be easy to remember >>> for the more common ones like 'F' or 'P', >>> but otherwise involves having the doc open at all times. >> >> You get used to it quickly, but you'll probably find you move more towards >> Vex, which will make most expressions redundant. > > Perhaps I could get used to it, like I could also get use to C++, but the > point was that it's not what I would want to deal with under tight deadlines > (or where I would like to spend most of my time) > > I've done my fair share of scripting, even some quite elaborate ones, but > always commenting the heck out everything and having extra descriptive > variable names to not have to decipher myself even the next day, but I > couldn't say I could decipher half the scripts I come across, and such things > remain quite difficult for me (as for many artists). > > >>> To simply -- say randomizing something with range that changes in >>> time, is comparatively quite something, >>> involving creating attributes (set or bind data) and float >>> parameters, >>> then processing these references in expression strings, spread >>> over a couple of nodes... >> >> Yep, completely pain in the ass. Unless you do it in Vex Wrangles, where >> it's super simple and fast (highly recommend learning the basics). >> > Thanks, I guess simple and fast can be very relative. > > >>> ---- and in general, string references to elements, attributes, or >>> to things defined in one of the 10 other Xops (all over), >>> *** following dataflow, (or getting an impression of what is >>> happenning) can be very -convoluted-. >>> often requiring great scrutiny or finding sources of >>> references to discover what different nodes actually do. >> Agreed. There's a definite need for programming-like strategies to cope, >> e.g.: Compartmentalise where possible into small blocks of nodes that do one >> simple task is a very similar argument to programmers not writing long >> functions. >> >> >>> - lots of Cryptic or non-self-explanatory nomenclature. >> Yes, there's a definite learning curve here. Probably not going to change >> now as it's so embedded in the software and documenation. >> >> You brought up quite a few other points, but thought I'd just address those >> for now as I don't have much time. Feel free to ask back questions though if >> you need clarification. >> >> Cheers, >> Andy >> > > Again thanks for the pointers Andy! > -J > > > > > ------ > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com > <mailto: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.
