I think working in Houdini is rather exhausting. Dealing with freedom can be a total nightmare. I'm not saying it's not pleasing, but having to work on scene that are constantly creating themeselves from scatch, well it makes my brain overheating. That's quite a different process than opening an xsi scene where setups are done, frozen, working in fixed context, and always ending in passes. In houdini it keeps calling objects from everywhere, computing stuff, going back, with a few additional variables, etc And, while it makes perfect sense when you are building your incredible setup, it's a whole different story when you open it 2 weeks later... Houdini requires a high level of organisation, and that's by far, to me, the hardest part.
2017-03-22 12:00 GMT+01:00 Andy Nicholas <a...@andynicholas.com>: > Ah, I see, understood! :) > > > On 22/03/2017 09:03, Jonathan Moore wrote: > > Andy, I meant nothing more than that last Cheat Sheet was published back > in 2011. I’m sure a bunch of folk would be interested to see what your 2017 > Cheat Sheet looks like. 😊 > > > > *From:* softimage-boun...@listproc.autodesk.com [mailto:softimage-bounces@ > listproc.autodesk.com <softimage-boun...@listproc.autodesk.com>] *On > Behalf Of *Andy Nicholas > *Sent:* 21 March 2017 23:09 > *To:* Official Softimage Users Mailing List. https://groups.google.com/ > forum/#!forum/xsi_list <softimage@listproc.autodesk.com> > <softimage@listproc.autodesk.com> > *Subject:* Re: Random Thoughts about H. > > > > 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 > <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<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 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.
