|
Hi, In light of recent H ramblings, just wanted to share a few pros and cons I personally found with H. ___________________________________ Good! - Can easily 'Get' effects, like fire, pool of water etc... then define inputs, and tweak settings. Can be artist friendly for high level nodes ( weather for factory nodes, or various digital assets around ) Factory high-level 'Assets' with workflows that are very streamlined, with everything very refined (all the way up to rendering) to make truly great FX very fast. - Modeling now seems just fine! (or at least for direct component manipulation which is now good enough, because it was much more finicky) Without being the same as SI, or the same as [insert the app you are most use-to here] I don't think anyone expects it to be the same as what they are use to, but similarly as workable, so that's neat! Seemingly in no small part thanks to McNistor's (and possibly others) initiative, patience and dedication ( and dev's openness which is very commendable and rare ) ironing out annoyances, and narrowing down issues. Because of that, at least for modeling, Houdini networks now feels (or feels much more) like a 'next' version of SI's construction stack, or like 'model compositing'. Performance - 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) ___________________________________ Things that I'm not sure yet -Animation As far as I could tell, like setting keys and curve editing seems just fine. Although I'm sure artists that animate or rig characters all day would have (and probably have) things to say about workflows, I was pleased to see that at first glance, alot seemed to already be there. -Shading Haven't checked new shading workflows yet. ___________________________________ Things I find to be 'Meh' Passes - there's probably 3 or more ways to set-up 'passes', and all of them are comparatively excruciating. - Help! - Good for explicit searches, or clicking the '?' icon in operator headers. - Can be Really bad for browsing reference sections - Alphabetically sorted flat list of all nodes, all _expression_ functions or all Vex functions ... For example :: the 'Inflate', 'Instance', 'IsoOffset' nodes, all concern very different things. - Perhaps there is something up with my setup, but help views seemed very buggy and (sometimes not always) very slow especially when always having it open. - Scene item Tree list (outliner/Explorer) seems somewhat basic, Network view is great, but tree lists can be much more optimal for overviewing hierarchies and unless I missed a preference(?) H tree view is a flat list of all object level items without parenting hierarchy representation. - Inconsistent highlighting and/or viewport element display This may very well be things I haven't yet understood, but even after a while, I haven't wrapped my head around it, ... but highlighting of selection or when viewing particular nodes seems quite inconsistent (when inside, or at obj level when switching tabs) sometimes shading type changes, sometimes with textures, sometimes not, sometimes transparent, sometimes not, or displays other outputs as well? (sometimes not). (when viewing back and forth between the very same nodes ) Elements seem to be either inside OR outside, or object level elements (where regular parenting happens) are almost like separate scenes (with little or no communication between them?) I may very well have missed something, or I hope I'm wrong, but it doesn't seem to be possible have multiple references of outputs or elements that are at object level or in other sops(?) (for instancing, or having common sources (easy and very common in ICE), or for allowing for arbitrary inputs) Performance Quite a few things remain very slow, the grass flattening example is runs at 5 fps for very few, very short guide fur strands. Teckano's ICE Grass flattening tutorial scene runs at 60 fps with tons of long strands (of many segments). That also goes for cloth, 8 fps for ball falling on blanket The SI Syflex Tshirt scene runs at 30+fps for 3 times mesh density for both cloth and colliding mesh What is comparable is RBD which seems to run at the exact same speed as Momentum (for same amount of pieces, both using bullet?), except for higher poly count peices (islands), SI still runs much quicker, and for reasons outlined below, despite some bugs, remains much more customizable. - ICE equivalence (personally my biggest gripe) while (as mentionned), HU operator networks felt like a next version of SI's construction stack for modeling, ... in contrast, HU networks also still feels like an extra-early or incomplete prototype of ICE. Or I still don't think it at-all compares in terms of **how visual** , visual-programming can be. Wished for one thing, that Vop nets allowed for subnetworks with custom port names, allowing for entire processes to be self-contained in a single VOP op Probably no small feat, but I think 'just' those things would address 90% of issues users have coming from ICE. 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) Or perhaps would there be other subtleties? Because in theory, or in those very respects, FabricEngine should be very-much like ICE, ... and it is ... but .... ( it's also very, or much more technical, but in different ways ) Nevertheless, currently, reproducing how different things were achieved in ICE or when wanting to make custom things is not *at-all* as intuitive! as soon as digging-in a little deeper. everything (such as different settings or where to adjust different things) is all over the place References to things that are everywhere that all happen behind the scenes, in _expression_ strings or Vex code bits, --- 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. 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... ---- 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. - lots of Cryptic or non-self-explanatory nomenclature. All the x-ops contexts is the first thing that comes to mind (especially for new users) (actually took a while to figure out what each context covered, even after reading descriptions) But Cryptic names also goes for quite a few things in H, like the many, if not most of the hundreds of expressions or Vex shorthands like:: oc Returns the value of a CHOP’s output at a specific sample index. oppwd Returns the path of the current network. ice Returns the end index of a CHOP’s input. ( and TBH, contributes to returning an XSI user to ICE ) And it sometimes feels like authors went out of their way to name certain things their own way, which also sometimes can refer to numerous things. One of the most obvious can be 'Primitives' (mostly for polygons), which can also mean primitive geometry like 'Box', 'IsoSurface', or 'Curve' or other sub-components notably for hair. Searching for 'Primitives' in forums returns things about polygons, and all sorts of things. But I don't know if it's worth bringing it up, would renaming a bunch of things really be considered? _________________ I think it's worth mentioning, that it wan't at all uncommon for first experiences with ICE to also be quite intimidating. Yet at least for me, after going through but a few clips from Bradley Gabe and Pooby it all (... or all mostly) became clear, or clear enough to more-or-less 'get' (at least topically) what was happening in the very large majority of compounds I encountered, all the way down to the most deeply nested ones (where lowest level nodes lived). Enough to modify theses compounds for particular ends, grab parts for reuse someplace else, and almost instantly learn from them, later eventually making my own from scratch. In contrast, after quite some time reading, experimenting and going through H tuts, (what we did in ICE involves digging in Vops and Vex material) In the many example hip files I opened to see how things were achieved, those proportions were completely reversed, and still consider myself mostly in the dark most of the time. Which I guess can have to do with how technical I'm personally willing to go without *specializing*, something which can of course vary widely from one person to the next. But anyhoo, all in all, at least for me, currently despite Vop nets, it seems that -- apart from very low level math Vop processes like -> this input multiplied by that one -- similarities with ICE don't seem to go much farther than that, or getting to similar end results is mostly achieved through what seems much more akin to scripting, except with -some- visual aspects, ... as opposed to through what could be appropriately called 'visual programming'. Very flexible no doubt (and probably less bulky), but also quite a bit less... 'visual' or intuitive, for authoring, interpreting things made by others ( when you didn't do it ), or reviewing our own work ( or figuring-out what the heck we were thinking at the time :p ) So perhaps starting a << project "Houdini, a great(-er) Visual Programming Environment " >> thread besides McNistors modeling thread would be in order? Just like modeling, I don't think the point is to "Make it like ICE" but also like modeling, to make it become similarly as friendly in Houdini way. (or enough so that we can say : "low level.. high level.. whatever!" ) Let me know if any thoughts, Until then, I think my subsequent experiments in Houdini will be making FX using provided high level nodes (where H really shines) perhaps eventually taking advantage of any extra upcoming regular DCC features (If I were Sesi, I would hire McNistor not just for modeling but for everything else :P), while forgetting about ICE, until i open it up again do to what I could only do in ICE. Though if indeed forgetting about it (not really :P), I wished it would be because it was obsolete, since unlike something like stop-motion making way for CG, it may be more 'dead' than it was, but in a great many ways does it seemingly remain -far- ahead by heaps and bounds. (with very slim chances for any replacement in sight) Or whichever it's status, there currently is apparently still no more direct path to translating what can be imagined into pixels (for custom stuff that otherwise can involve much more 'hardcore' techy stuff) ___________________ Below:: are some Illustrations of previously mentioned points Comparison using Olivier's recent local rotations method with ice (as an extra simple example) then comparing standard emit from geo nodes. Let me know if something seems inaccurate, or if I missed something. Thanks!
|
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
