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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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 [email protected] with "unsubscribe" in the subject, and reply to confirm.
