|
On
04/13/17 23:24, Jonathan Moore wrote:
> The bit that's most odd to me is using HScript style $ in VEX. Is that VEX code that you've copy pasted from somewhere else? Actually, it was a Maya particle _expression_ for making confetti, but I can see how you might have mistaken it for Houdini code. (processing P's N's and V's in math op strings assigned to variables) On 04/15/17 7:07, Tim Bolland wrote: > I would agree with that if the final result out of Houdini was on par with what Maya and other DCC's were delivering. Agreed, yet quite specifically for FX using factory high level nodes. The reality is some of the assets you can make with Houdini, with very minimal scripting, can be far more complex and superior than what you can make with other applications. In fact, depending on the asset I would say making it in Maya would involve far more scripting and technical know how than the Houdini workflow. Actually Houdini, using the same example, that very short (but not super easily authorable) confetti snippet, would be more or less the same formula. I just don't see 3D as a single software process anymore. Of course not, that was (is) an XSI thing. I'll use the best software to get the best results out, what ever that is. Excluding the one that "does it all" ? (or to a quite large extent most of it all?) While it can of course be beneficial to export / import to/from apps to do specific things I think we can all agree that the least amount of roundtrips necessary, the better. (I've seen some pipelines that are absolutely horrendous in the amounts of exports/imports) The problem I think with either Houdini or Maya, is that the only way to do even a bit more than somewhat basic things, is -through- that complication. Also the reason I'd like to push for more visual approaches, is that if anything, Houdini has seemed to be getting -more- complicated, as opposed to less. Old vs. New Point SOP | SideFX (hole thread is interesting) itriix:: @P.x, @P.y, @P.z is how you would access the different components of the Position. Or @N.x, @N.y, @N.z for Normals. If the default is now: Set Constant Value to: 0, 1, 0 Set VEXpression to: self + value * sin(radians(@ptnum)) That's a lot of additional work - and possible “human error”, just to get a sine wave. It's beginning to feel much more verbose. It also doesn't have any visual clues as to how you might want to reference a particular attribute (such as position). While, yes, you see Position(P) in the drop-down menu, it doesn't visually show it being used like: @P.x, @P.y. @P.z In this case, it wasn't for the sake of more flexibility (or not mostly), but for more performance, or for -multithreading- specifically. Which can of course be very good reason to change things, but it's where we can see that approachability could have had much more relative priority. Hscript to Vex, might be compared to what _javascript_ is to C++ or rather -> C (also for more flexibility no doubt). should i avoid hscript and copy stamp? (hole thread is interesting) Artye :: When you are learning, hscript and copy stamps are nicer. mestela :: For those cases the new for loops are the way forward, which I agree are tricky for new users to get their heads around (and most experienced users too for that matter). But its not just for 'learning', it's also for every day when making, or trying to understand what others did for different setups, or how fast we can understand what we ourselves may have done not so long ago. Vex (or blank wrangle nodes with a text box in which you define what the node is/does), also replaces a bunch of nodes that although basic, had some sort of UI. To the point of 'nodes' becoming little more than either separate or merged script containers? (often favoring vex over vops, simply because vops quickly becomes big, messy, with required separations or ins and outs.) Also because there doesn't seem to be THAT much things to address to make subnets more easily manageable/distributable. enough for them to actually be used around. And also because :: << Why isn't it working?! Is a comma missing? are all brackets balanced? wrong syntax? (specially when shuffling between vex, expressions, hscript and python) ... or a typo? or is it a wrong "connection". (textually represented 'connections') ARRGH! Deadline! >> Then scruitnizing docs, asking questions on forums about things that would otherwise simply be non-issues.. "I have created the set up and created the ID and AGE attributes but cant figure out the death over time part." https://www.sidefx.com/forum/topic/49220/ here with a response pointing to snippets. and leading to things like this:: Frustration Threshold ICE Confetti In this (very) particular case, a Vop net would probably not need be much more elaborate, because it's mostly doing basic math on common attributes. But in many if not most other cases, not having easily accessible encapsulated functions (including tiny ones encapsulating 2 or 3 ops) could indeed make doing things from scratch with nodes quickly become nightmares (with -lots- of nodes across a couple vop nets), Then making it indeed (borderline) questionable if using nodes is more straight-forward or not (then becoming a "yes & no"), thus probably contributing to often favoring the much less visual and difficult to author or decipher, but also then much more lean Vex, over bulky Vops. Now wouldn't the best of both worlds be awesome? No one is arguing removing coding aspects, some people live in code, and that environment is obviously what suits that type best. Yet for "the artist type", to a large extent do you -need- to live and breethe it, or in other words -- dedicate yourself to it, to become relatively fluent to a functional degree, or even remotely swift. Thus taking away from other possible artistic endeavors (if that's your thing)... Of course ideally we should strive at both, and we generally do to some extent because we -have to-, at least to -some- extent, but it's not for nothing that people are often mostly EITHER very technical, OR very artistically inclined, because we're talking about entire fields in themselves that can take years to become refined. Because time flies super-fast, and life is super-short, and we have to make choices, because we can't -do- everything... or SOME can but it's very-very rare. And if software can bridge that gap, allowing the more artistically inclined to do things that can otherwise easily involve literally -years- of study and practice... well you get the point... Which was/is the point of ICE, which could totally be a similar direction Houdini COULD be taking, is what I'm (and a number of us I think) are saying. Thanks, -J On 04/13/17 23:24, Jonathan Moore wrote:
|
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
