Re: Houdini : non VFX jobs?
> On May 14, 2018, at 1:01 AM, Matt Lind wrote: > > Houdini doesn't have good tools for dealing with the macro view of a scene > for the generalist. When you open a scene you're not familiar with, or one > you haven't opened in a very long time, you want to get a general overview of > it's structure in a few seconds. That is the purpose of mentioning the > schematic view as it provides that overview at a glance. > I think it does… Using Subnetworks, allows you to keep the top level very simple, just like collapsed nodes in the schematic. Tools like network boxes allow for documentation right there, same as icetrees. Color coding nodes can group them in a visual way. These all aid to reduce complexity and provide overview. > Does it tell you everything? No, of course not, but it doesn't have to > either. It does tell you the links between nodes such as who is constrained > to whom, where the envelopes reside, which nodes have shapes/lattices/etc. > and very importantly – hierarchical relationships to understand how rigs are > put together. > Again, this is fine for people who are proficient at those tasks. You make it sound so simple, yet understanding someone else's rig is never done in a matter of seconds. Not to other riggers, and especially to generalists. I would agree, that there’s more help in Soft finding the details, but not in a first glance overview. > Again, we're talking about the big picture. Explorer??? that’s for > micro-level work when you want the dirty details on an object. It's not good > for the broader picture as you have to spending a lot of time clicking on > nested node after node until you find what you're looking for, and even then > there's often a lot more information displayed than you need leading to > excessive noise. That's exactly the same problem with ICE compounds as > digging into nested compound after nested compound you begin to lose sight > over the bigger picture you're trying to grasp. This isn't a discussion about > which is more powerful, it's about presenting information that is better > suited for high level working for the non-technical user. > And where exactly do we draw the line between ‘technical’ and 'non-technial’ users? At the macro level shouldn’t it benefit both? I guess I’m failing in grasping the broad term of generalist. I strongly believe, all of our staff would fail so hard if they had to use Max or Maya tomorrow coming from Soft. > As for networks and subnetworks. Great, you have a system. Most people do > not, or if they do, it will not be the same system as yours. THAT is the > point. There is no consistent or uniform way of having information presented > to you to get the high level picture of what's going on in the scene. There > needs to be some base level of communicating to the user where things are > placed, how they relate to each other, and so on, and not require the user to > dig, dig, dig, dig, to get oriented to find ‘basic’ information. > Are you still refering to the schematic? Because I’d generally describe them just as messy, unorganized ;) > Someone can easily build a forest and hide 50,000 trees and other > geographical features inside of a single network or subnetwork which appears > as a single node in the network view, and even build it recursively. That is > not informative. This is where Houdini needs to improve. In contrast, > although it can be done, it's pretty difficult to hide those details in > Softimage's Schematic view. You open the scene, BAM! you see the complexity > right away. > :) Honestly? It’s just as easy to shoot someone else in the foot with said scenario in softimage (nesting point clouds, instancing groups) In the end you’re dealing with complexity and I fail to see how the schematic helps to decipher that in seconds. > I'm not suggesting Houdini be rebuilt from the ground up. I'm highlighting > sticking points between it's current state and why more generalists don't > adopt it. When you get into a larger production pipeline, as much as you need > the low level power Houdini provides with assets and such, there is just as > much need at the opposite end of the spectrum with getting users into the > pipeline to do work. Many of whom are not thoroughly trained and need to > learn on the fly, and probably won't have a great deal of interest learning > all the ins and outs beyond the bare necessities to get their job done to > satisfaction. As production scales up, the quality of your users tends to > drop because you have the matter of filling seats to crank out work by a > specific deadline, and each seat has a salary cap. Therefore, whatever > pipeline you have, it must accommodate these less than ideal users. Many > generalists struggle with learning and/or forming good habits even when given > good instruction as you're forcing non-technical people into a technical > environment. It's alien to them in a migraine headache creating type
Re: Any Dinosaurs Still Lurking?
Yep, still here. There's even at least one new person that joined last year that is on my team--even though we use Houdini, Maya, and Max. The "M's" will drive you mad. I'm so thankful Houdini is not owned by AD. I only get to use Soft at home on my personal projects anymore. -=Eric Turman On Sun, May 13, 2018 at 8:49 PM, Ed Manning wrote: > I still read the list pretty regularly, but have found the S/N ratio > degraded compared to a few years ago. > > I still use Softimage a lot, along with Unreal and Touchdesigner. > Real-time is getting to the fun creative exploration place that VFX was in > for so many decades (for me at least). > > Touchdesigner is getting more and more capable, and is very ICE-like in a > lot of ways (which is not really surprising given its roots in Houdini). > It's really becoming my tool of first resort for a lot of things. And many > important parts have already been moved onto the GPU, so performance for > certain things is insane. Particle counts in the millions in real-time or > near-real-time, for example. > > Dinosaurs are still around in IRL, anyway -- we call them "birds" now. > > :-) > > -- > Softimage Mailing List. > To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com > with "unsubscribe" in the subject, and reply to confirm. > -- -=T=- -- Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Re: Any Dinosaurs Still Lurking?
I still read the list pretty regularly, but have found the S/N ratio degraded compared to a few years ago. I still use Softimage a lot, along with Unreal and Touchdesigner. Real-time is getting to the fun creative exploration place that VFX was in for so many decades (for me at least). Touchdesigner is getting more and more capable, and is very ICE-like in a lot of ways (which is not really surprising given its roots in Houdini). It's really becoming my tool of first resort for a lot of things. And many important parts have already been moved onto the GPU, so performance for certain things is insane. Particle counts in the millions in real-time or near-real-time, for example. Dinosaurs are still around in IRL, anyway -- we call them "birds" now. :-) -- Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Re: Houdini : non VFX jobs?
About epiphany :) expected after few months or so, well, still nothing here :), after four years and more than thousand of hours in front of H. I'd say, H is really special case, where usual story about adaptation to another DCC doesn't work. First of all, this app is already 'adapted' to all wishes of coders, to level unseen in DCC world. OK, these people were before, anyway, they obviously did not tried to adapt self to 3d standards, it seems to me they did everything to adapt H to their habits.If anyone is example unwilling to adapt, well that's Houdini people :). In times of H13, they tried to explain me why I don't need HTML help (which btw is working with fifty fifty success here, all these years), why H textport is better, so on. For small example (one of many) how that works from another side: Houdini allows to write expression in number input field directly, which us probably great for coding, but whenever I've tried to animate in H, because I have habit to do not care about mouse position when entering K key, this was taken as expression not able to evaluate, next mouse-keyboard action caused crash. Whenever I felt relaxed enough to forget where I am, it was Houdini to explain me. For similar problems in Maya, it was just remapping of S key to something harmless. IMO, only way to adapt to and love H is just to forget any view port interaction, to do not use view port for anything else than display - then, generally it's fine, question is how much someone is able to reallocate to 'no view port centric ' method. Animator or modeler, not that much. Second, apps like SI, Maya, Max, C4d or Blender, they are similar in many ways, so actually *is* possible to use one as another, at least in introductory phase. When I started with SI, I used a few scripts to allow Max style of transform offset for around first two years, always tried to avoid SI dopeshit, and.. still I'd consider my SI experience as successful. I disabled Blender cursor as much as possible, Blender is still usable. Third, 'speaking with Martians'. At some point I've figured out that only available quaternion interpolation in Animation Editor is qlinear() thing, so no TCB keys or anything like. When complained on forums, got long answer about quaternions and math behind, explaining to me idiot, that such type of only linear interpolation is smooth enough by self (by the way I'd say it is only and only if there is constant angular speed across keyframes, otherwise is not). It was one of developers I think, clearly not showing the understanding of basics. Now what, I have to submit RFE hoping for feature granted in Maya, Max, Blender for decades. Have no energy for that, there are another options. Fourth... Maya is... Maya, it is a norm, industry standard, hundred of movies, possible careers, first DCC I was learning, huge user base. If I am good in one field and dislike the another, someone else could take the counterpart, that's it. It is bad, but not *that* bad to move on. Same works with Max and C4d, more or less. Anyway, just to put something positive, and of course shameless plug: I'm slowly working on streamlined version of this thinghttp://forums.odforce.net/topic/23842-no-skin/For some unknown reason this one seems to be most popular of all things I've tried to present to Houdini people (most popular in Houdini world means a lot of conversation with another authors or like-to-be-authors and no one end user, as usually :)). This time I'd try to make it as much 3d app independent (no chops, no VEX code), relying only on VOP structure and simple mocap style rig, there should be some way of interpolation to make it faster, so on. To be honest, I wanted to redo it in Fabric, but, we are where we are, hope to have something to conquer the 3d world :) sometime in summer. -- Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Re: Houdini : non VFX jobs?
you're dissecting things at a more granular level than is intended, and as a result you're losing sight of the overall discussion. a new user coming into Houdini doesn't have that historical background, nor does he/she care. He only sees a lot of special case tools that require inside knowledge to understand and use. That is the immediate point of frustration that isn't resolved well with documentation, and in many cases, not even discussed at all. This is one deterrent from adopting Houdini from the generalist's perspective. Houdini doesn't have good tools for dealing with the macro view of a scene for the generalist. When you open a scene you're not familiar with, or one you haven't opened in a very long time, you want to get a general overview of it's structure in a few seconds. That is the purpose of mentioning the schematic view as it provides that overview at a glance. Does it tell you everything? No, of course not, but it doesn't have to either. It does tell you the links between nodes such as who is constrained to whom, where the envelopes reside, which nodes have shapes/lattices/etc. and very importantly - hierarchical relationships to understand how rigs are put together. Again, we're talking about the big picture. Explorer??? that’s for micro-level work when you want the dirty details on an object. It's not good for the broader picture as you have to spending a lot of time clicking on nested node after node until you find what you're looking for, and even then there's often a lot more information displayed than you need leading to excessive noise. That's exactly the same problem with ICE compounds as digging into nested compound after nested compound you begin to lose sight over the bigger picture you're trying to grasp. This isn't a discussion about which is more powerful, it's about presenting information that is better suited for high level working for the non-technical user. As for networks and subnetworks. Great, you have a system. Most people do not, or if they do, it will not be the same system as yours. THAT is the point. There is no consistent or uniform way of having information presented to you to get the high level picture of what's going on in the scene. There needs to be some base level of communicating to the user where things are placed, how they relate to each other, and so on, and not require the user to dig, dig, dig, dig, to get oriented to find 'basic' information. Someone can easily build a forest and hide 50,000 trees and other geographical features inside of a single network or subnetwork which appears as a single node in the network view, and even build it recursively. That is not informative. This is where Houdini needs to improve. In contrast, although it can be done, it's pretty difficult to hide those details in Softimage's Schematic view. You open the scene, BAM! you see the complexity right away. I'm not suggesting Houdini be rebuilt from the ground up. I'm highlighting sticking points between it's current state and why more generalists don't adopt it. When you get into a larger production pipeline, as much as you need the low level power Houdini provides with assets and such, there is just as much need at the opposite end of the spectrum with getting users into the pipeline to do work. Many of whom are not thoroughly trained and need to learn on the fly, and probably won't have a great deal of interest learning all the ins and outs beyond the bare necessities to get their job done to satisfaction. As production scales up, the quality of your users tends to drop because you have the matter of filling seats to crank out work by a specific deadline, and each seat has a salary cap. Therefore, whatever pipeline you have, it must accommodate these less than ideal users. Many generalists struggle with learning and/or forming good habits even when given good instruction as you're forcing non-technical people into a technical environment. It's alien to them in a migraine headache creating type of way because an artist is generally right-brained while technical users are generally left-brained. A schematic view is right-brained approach. Explorer/networks is a left-brained approach. While Houdini has a functional equivalent of a schematic view in the network view, it doesn't provide the same information the generalist seeks because it requires additional attention to detail to dissect the graphs in a more left-brained approach. Houdini needs more right-brained tools and interfaces to accommodate the generalist. Matt Message: 2 Date: Sun, 13 May 2018 22:48:16 +0100 From: Jordi Bares Subject: Re: Houdini : non VFX jobs? To: "Official Softimage Users Mailing List. This thread is getting really really useful, thanks Matt? More comments below. On 13 May 2018, at 21:00, Matt Lind wrote: Another example is the need to learn the various categories of operators (SOPS, CHOP
Re: Houdini : non VFX jobs?
> On May 13, 2018, at 10:00 PM, Matt Lind wrote: > > An example of the boiler plate burden is exactly what was already discussed – > modeling and tweaking as that's a good bulk of the early work. Bad first > impressions can be a major deterrent. > > Another example is the need to learn the various categories of operators > (SOPS, CHOPS, VOPS, …). Sometimes nodes from different categories do the same > thing. that adds confusion. If nodes from one category cannot work with a > node of a different category, then that's a problem too. This is where > documentation is sorely needed. It's not strictly a case of a SOP does this > and a VOP does that, but rather a discussion about strategy. When is it > appropriate to use the various OPs? When should a SOP be used in place of > wrangled nodes, or vice versa? that is a huge void in the documentation and a > place where users easily get lost and frustrated to the point they throw in > the towel. I wholeheartedly agree, further improvements are needed. Have you given this feedback? > In short, Houdini has a lot of spring cleaning to do to tidy things up for > the generalist. Right now it's an idiosyncratic development environment. It > can be very powerful, but it requires a lot of inside knowledge to use it. > The generalist doesn't want to (or need to) deal with the inside knowledge. > They need something they can hit the ground running without fuss. > I’ve had three freelancers with very different backgrounds (maya, softimage) and I had them up and running in Houdini in 2-3 days. They were able to move on very quickly from there. Scene assembly, lighting and rendering. None of them had a technical background, quite the opposite. > As for the show dependencies thingy, that's just it. I don't want to see more > wires inside of a graph which is already very crowded, messy, and lacking > structure. There needs to be a way to illustrate the structured connectivity > at a high level so users aren't forced into the weeds to get basic > information. Help me understand, how is this not the case with the Schematic view? It’s still the preferred view for most of our animators. > With ICE or the rendertree in Softimage, the nodes were text-based so you > could follow the logic while hiding unconnected ports. However, even ICE > trees could get very complex very quickly, so the use of compounds were > introduced, and while that helped, it wasn't the same as a schematic view as > compounds could be recursively nested to very deep levels hiding the very > information you sought. Houdini's nodes are very iconic, but not very > descriptive as to what they do. You can see various node icon shapes, but > that still doesn't tell you the logic in the same way as following an ICE > tree or rendertree. The design/layout of the network view leads to lots of > bloat very fast making it difficult to keep track of your work when you get > beyond simple models. I don’t follow, SOPs in current Houdini show the type name of the operator (node) above the node name making a graph quite readable. I can’t see how the render- nor icetree do better here, besides the default nodes having very descriptive names. Both approaches break once you introduce custom nodes (compounds/subnets) named shortsightedly (in most cases not named) by the user. > While networks make a lot of sense for VFX work, they are often less than > ideal for character driven work. Character work benefits more from > straightforward relationships which are easy to identify and follow as > characters are often a hub for other work such as VFX, simulations, > attachments, constraint interactions, and other details which come later in > the pipeline. Networks represent spatial organization/view. No matter the task, some people prefer spatial navigation. Some prefer the hierarchical view for everything. > People working in those later steps need to be able to quickly jump into the > asset and immediately know what to do and where to do it. They can't be > burdened with a messy network graph which they must study to the N'th degree > before they understand where to start. Hmmm, I couldn’t save my live with either the explorer or the schematic in Softimage trying to figure out what a character rig does. To me this comes down to a level of expertise/familiarity to the task at hand. Cheers, Andy -- Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Re: Houdini : non VFX jobs?
2LXheI89DD7bUnzqVaJnQEBTdW08bxgXJLrEoHtcUb0Os6TNOgzkIKzPZXURWx-2D2FSJePMnVU8LRJWmAfJUhgo104PS4WFp-2D2FfJ3N5rbRuTadZflH0O-2D2Fh0M2h4yxib0ouX7j-2D2B2tixig6uQ8oA9tHKwbpeDBX96kNmyQeXTP2xyJ8o0enQb8fdkpC1N1yrj-2D2F86ylX3Yd13AvqA-2D3D-2D3D-5FxtAIgyeGUkaFYUSrrLyyFGCT559IxnI2CalBtcQNCt1ZpP5RSY8m3j3fC3Llx6XJJJcGSKy2rnhFCwKBcQ-2D2FEivZuddy-2D2FtIgmtY6BXRq3bXlgHt80z2VD2zzPUbYqMGDSg > > <https://u7507473.ct.sendgrid.net/wf/click?upn=5SmYwFIJXHmC5X9wAP0G6mg4oLGBuQENbeDkYXezg3m6vjHxJcC6rUMd8QE2MtqzS3nHFJpHH1mihN2vNWVF73yH4QzPTUaj-2BU-2FV4xCvLLTnZ7suFMzmFdGmjVRnYdJAxVY-2F5M380PkfQ8TNK8ovM5rxNeeTCOnkRGaT-2F-2Fqta38pWvWMaql23pwdaAWmes-2Fu-2FwoONKissOPCP2dnxYlCF1qRNWEOp0nYdAwcc9rC5IUfIdQsFs-2BflMjQs4kZWTvisQvKyIYVsNejBnTdqQxGuSkaI3zZNVtkWlyb616AJva8HG-2FDmAdn24eoqkkGy9efRXhSxJLvTt0nNKhLpnK5GuMonI1D4oPK9Mk4Qb3H4GH6wrsUCnQ8MdVHNwjndlcWsXlBh3-2FAjCQ5TQ-2Fcz-2BGSUI2D0eopQPihZX7BgpD5mRk62-2BOUDFV9Wh6HjMbXBxaMDgdeMAA75MiszMbLTxp7q0AY0j9tYxuOCBItkyf-2FMhFHHZtxjbC8BEPpI6pYeeIOO3ugm9zRD7Qo-2Bhz5wGuSluhlqfrdpByVf2Q9EW3RtNyfWZP1nPTEUNh-2B29En3Ew4n5vgQrvl0PzV8D8pwHIL-2BadpURMQ0BUAVEz15eGavBOfw-2BpdMhVz5dtL72-2FhjUivbtC2oKQ-2FMfH-2Bqt2VzlQOu2YZL90bNbdYBNq4AntJn5tBhHu-2FvrUMXSCny9muqCv4CJItUenAT9hSReXJKxZbF-2B6bR-2BK4p8l2dlsnE5Uh9YdlyThxJwILv2-2FUpiKNPze-2BMbrBzaQqDGd-2Bd9RUh5okxoUl-2BluI-2B8h-2BhPBG1lRZ-2BElgdbTyxa3U5qUJeow6ameyLXH7nzqStV6NGXviMfSgHaLyRwpyO9idmOgtEA4AUNhiDT3bzqBLCc5tGg1oZV9IMzBoh-2BFcTlnHwHJY-2BZ5-2BaNvTp7mLt7Tf7KdLRZVgZdM-3D_xtAIgyeGUkaFYUSrrLyyFGCT559IxnI2CalBtcQNCt0FbiUxYtn6yHlWA6xMWzOR5KZb9E7a8wc3VuhMdHmv77zzfHyxeMFAkkasbWbtueXvvZVoHGY2qUylaqPHvcLQ08I8xNto5aolwEiOqPBCFeu8-2FAqa5pbvizKaG0Jd-2BVGnrCoxqehjmabf-2B2LvebA05-2FykELK1OQ15tahPc1KtEUkVepKRXJ645g-2BO5dUNybo-3D> > UaDfO4zTapneePB0aoSve4cxp5aGXhetvS-2D2BKHLRPZ1XRT7YsM4sJM4WoSQVHdbI3PT2EoRlpdGZVMT8RzwOJdhepaUj9cKapbsZ-2D2BdHcP5Q-2D3D&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=Z6U0dqiDr9C7tT20jA4wmvFpZvvnUEa2y4sqeer3g7A&s=IIeJjTqMRI5D1mw5DEFqoSsTFp_zygLF0Kv82bXg7wM&e=>" > Message-ID: > <28c8fb7a-0412-47d4-bdb0-2a9933d41...@gmail.com> Content-Type: text/plain; > charset="utf-8"@Matt, Exactly my thoughts (but clearly better explained)I > would certainly advocate to improve things in terms of node functionality or > assisting better in certain aspects (blend shape manager, exporting bundles > in and out, or adding hierarchical overrides in takes, or adding certain > tools we use every single day, or bringing more ?uber nodes? to VOPs so we > don?t have to be so granular) but always without sacrificing proceduralism or > breaking their core design.Jb-- Softimage Mailing List. To unsubscribe, > send a mail to softimage-requ...@listproc.autodesk.com with ?unsubscribe? in > the subject, and reply to confirm. > > -- next part -- An HTML attachment was scrubbed… URL: > http://listproc.autodesk.com/mailman/private/softimage/attachments/20180513/cbcb9324/attachment.html > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__u7507473.ct.sendgrid.net_wf_click-3Fupn-3D4NJpoo1h1GOdyqBB3sJimai-2D2BQC-2D2FGskUXuPx0XSl6rNdr5Gg0XscjA7dk-2D2BFQcvfCTrPyNVTe21bXODeNjelkdcj7ocyG7Qzl-2D2FhzVov6tKwKhbBDR2u3exFK4IROOT921VAcHZqAtQcS5XkMLA-2D2Bi88Gw-2D3D-2D3D-5FxtAIgyeGUkaFYUSrrLyyFGCT559IxnI2CalBtcQNCt0FbiUxYtn6yHlWA6xMWzOR1oq5nZzpKiTYATKS3biXZT0Z4eyUP-2D2BXNFmOwuq-2D2BAXRAfqoO606O5ZityVBYlOSyb8Uq0jPNemAKF1J1OG4KuAFEh1-2D2BcB8Fg57yi21OI2bs5sYAb1O49A6-2D2FeQlD3DdNtWeBi-2D2FQuuhfd8rPafdOx4ygh4BmKGN9gixNANOA0pmjcQ-2D3D&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=IMplZKKOuoDL5uedA4ZHoOaQBRAMft5emUuoFQMHNSI&s=oCQ0_GsrewW_gH52NA-CSSmYckUXPPannw4iXB4Cldo&e=> > -- > > ___ Softimage mailing list > Softimage@listproc.autodesk.com > http://listproc.autodesk.com/mailman/listinfo/softimage > <https://urldefense.proofpoint.com/v2/url?u=https-3A__u7507473.ct.sendgrid.net_wf_click-3Fupn-3D4NJpoo1h1GOdyqBB3sJimai-2D2BQC-2D2FGskUXuPx0XSl6rNdaJFGAiSAtRlLIFMPKKS9zYUVvw6tqP6OR-2D2BwHxAPVGvQ-2D3D-2D3D-5FxtAIgyeGUkaFYUSrrLyyFGCT559IxnI2CalBtcQNCt0FbiUxYtn6yHlWA6xMWzORoz4TPI1olXS9CMFIjf-2D2FBvtTrNC-2D2B7GUdhPwq-2D2BmxPjzPqy2Tqmj-2D2F5HnOFcV50B2duYt71-2D2BhcMd-2D2BgI3qJgYk5lBitbafdOxB4XDzbEiLouZBkgoTUGaqVI73l5kHEIkMDEkd-2D2F-2D2Fwm2XjSbz7il-2D2FJgTzBdVyXcrAq2bdKTqGvCTzdd-2D2Bo-2D3D&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=IMplZKKOuoDL5uedA4ZHoOaQBRAMft5emUuoFQMHNSI&s=10nSXwU8d4fltdDDJx95_rWu6WDeLuzZYu5G9P6G1gg&e=> > End of Softimage Digest, Vol 114, Issue 60 > ** > > -- 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.
Re: Houdini : non VFX jobs?
An example of the boiler plate burden is exactly what was already discussed - modeling and tweaking as that's a good bulk of the early work. Bad first impressions can be a major deterrent. Another example is the need to learn the various categories of operators (SOPS, CHOPS, VOPS, ...). Sometimes nodes from different categories do the same thing. that adds confusion. If nodes from one category cannot work with a node of a different category, then that's a problem too. This is where documentation is sorely needed. It's not strictly a case of a SOP does this and a VOP does that, but rather a discussion about strategy. When is it appropriate to use the various OPs? When should a SOP be used in place of wrangled nodes, or vice versa? that is a huge void in the documentation and a place where users easily get lost and frustrated to the point they throw in the towel. In short, Houdini has a lot of spring cleaning to do to tidy things up for the generalist. Right now it's an idiosyncratic development environment. It can be very powerful, but it requires a lot of inside knowledge to use it. The generalist doesn't want to (or need to) deal with the inside knowledge. They need something they can hit the ground running without fuss. As for the show dependencies thingy, that's just it. I don't want to see more wires inside of a graph which is already very crowded, messy, and lacking structure. There needs to be a way to illustrate the structured connectivity at a high level so users aren't forced into the weeds to get basic information. With ICE or the rendertree in Softimage, the nodes were text-based so you could follow the logic while hiding unconnected ports. However, even ICE trees could get very complex very quickly, so the use of compounds were introduced, and while that helped, it wasn't the same as a schematic view as compounds could be recursively nested to very deep levels hiding the very information you sought. Houdini's nodes are very iconic, but not very descriptive as to what they do. You can see various node icon shapes, but that still doesn't tell you the logic in the same way as following an ICE tree or rendertree. The design/layout of the network view leads to lots of bloat very fast making it difficult to keep track of your work when you get beyond simple models. While networks make a lot of sense for VFX work, they are often less than ideal for character driven work. Character work benefits more from straightforward relationships which are easy to identify and follow as characters are often a hub for other work such as VFX, simulations, attachments, constraint interactions, and other details which come later in the pipeline. People working in those later steps need to be able to quickly jump into the asset and immediately know what to do and where to do it. They can't be burdened with a messy network graph which they must study to the N'th degree before they understand where to start. Matt Message: 2 Date: Sun, 13 May 2018 17:28:12 +0100 From: Jordi Bares Subject: Re: Houdini : non VFX jobs? To: "Official Softimage Users Mailing List. below On 12 May 2018, at 23:26, Matt Lind wrote: I wouldn't steer towards uber nodes. The larger a node gets, the more maintenance it requires and more taxing it becomes as a bottleneck. If a node gets too big, you may end up with a situation where it becomes really popular from having a larger feature set and everybody and his cousin uses the node in every project. At that point the node can become an albatross around the developer's neck because any tweaks to the node could cause negative ripple effect throughout the community should something go wrong. The whole point of having a node system is to guard against that scenario by distributing the workload and only use the features you need. Uber nodes would automatically add bloat to your workflow from the many features you often wouldn't use but have to come along for the ride. I was referring to the kind of ?uber node? you find in Softimage where you don?t have to do all the heavy lifting? certainly I agree with you, monolithic Albatros is not the idea of uber-node I had in mind. :-) I think what's needed are more dedicated nodes for modeling, texturing, and animation tasks to fill in the current voids. There also needs to be some more UI polish to work with modeling and character animation workflows. Both are merely the base level adequate. They need to improve into good or great. My take is that in order to compete in the modelling market the edit SOPs and the Retopo SOP will have to be extended to bring a lot more functionality and this is where I see the non-procedural approach acceptable. Right now these are very limited compared with Softimage. Houdini needs a few modules to account for workflows where a node base system simply doesn't make any sense or provide advantage. Think pushing and pulling po
Re: Houdini : non VFX jobs?
Just to clarify... > On 13 May 2018, at 17:28, Jordi Bares wrote: >> I would like to use Houdini, but am choosing to not pursue it until I see >> more adoption for character and modeling work. >> > FYI I am rigging and animating a human character in Houdini as we speak... > For a film. And the Film quote I mean, “this is going to be a big screen”, it is a very small project with just 3 of us in 3D working on it so please don’t assume huge pipeline blah blah blah… jb-- Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
Re: Houdini : non VFX jobs?
below > On 12 May 2018, at 23:26, Matt Lind wrote: > > I wouldn't steer towards uber nodes. The larger a node gets, the more > maintenance it requires and more taxing it becomes as a bottleneck. If a node > gets too big, you may end up with a situation where it becomes really popular > from having a larger feature set and everybody and his cousin uses the node > in every project. At that point the node can become an albatross around the > developer's neck because any tweaks to the node could cause negative ripple > effect throughout the community should something go wrong. The whole point of > having a node system is to guard against that scenario by distributing the > workload and only use the features you need. Uber nodes would automatically > add bloat to your workflow from the many features you often wouldn't use but > have to come along for the ride. > I was referring to the kind of “uber node” you find in Softimage where you don’t have to do all the heavy lifting… certainly I agree with you, monolithic Albatros is not the idea of uber-node I had in mind. :-) > I think what's needed are more dedicated nodes for modeling, texturing, and > animation tasks to fill in the current voids. There also needs to be some > more UI polish to work with modeling and character animation workflows. Both > are merely the base level adequate. They need to improve into good or great. > My take is that in order to compete in the modelling market the edit SOPs and the Retopo SOP will have to be extended to bring a lot more functionality and this is where I see the non-procedural approach acceptable. Right now these are very limited compared with Softimage. > Houdini needs a few modules to account for workflows where a node base system > simply doesn't make any sense or provide advantage. Think pushing and pulling > points on geometry to sculpt a character, or tweaking texture UVs for game > assets. Building a network with hundreds of nodes containing all the tweaks > is counter productive beyond a handful. It would be better to make a > dedicated user interface to work on that task in long session form, then > merely bake out the stack of tweaks as a single node in the tree when all is > said and done – or something to that effect. Perhaps the user would apply > markers to decide how many tweaks can be bundled together as a single node > upon completion in the same fashion a user can define an arbitrary point as a > restore point when updating Windows. > We are on the same page here as well. > The FCurve editor is mostly OK, but the layout of tools on all sides of the > windows needs a rethink. While they're making good use of screen space, it > puts more burden on the mind of the user to keep track of all the tools and > be more conscious of pointing and clicking with the mouse when tweaking > FCurve Key values so as to avoid inadvertently clicking a tool placed on the > perimeter of the FCurve editing workspace. Sometimes it's better to have > emptiness on one or more sides of the workspace. > Indeed, this is really user experience refinements rather than anything else, imho it is quite good already and love the grouping system. Dopesheet needs some love though. > What needs most attention is management of large networks of ops as when > dealing with character rigging as you need some degree of assessment of how > the character's parts are hooked up to function. A schematic view makes that > fairly straightforward and the parts that are overdriven by expressions or > other tools are easy enough to locate with arrows and wires connecting them. > Doing the same in Houdini on a complex character is quite a chore as the > trees of nodes don't necessarily illustrate the patterns of parent/child > relationship or trickle down behavior one would expect to be able to follow. > This makes the process of rigging a bit counter-productive from an > organizational standpoint and puts extra burden on new users or users who > haven't seen the asset before and need to become familiar with it before they > begin work. It requires a great deal more study to get up to speed. > Do you know about the “show dependencies” right? > What most non-technical artists complain about is the lack of attention to > detail in getting boiler plate tasks done. Not because the application isn't > capable, but because it requires a lot more time and energy than should be > necessary. It's kind of like having to rebuild your car from scratch every > time you want to go grocery shopping. Even if all you have to buy is a carton > of milk, the effort to get there is just not worth it. Furthermore, the > houdini manuals aren't particularly good at describing how to make use of the > system for these types of tasks. > I am not saying you are wrong but… could you point to some? I would love to analyse those and may be we can find ways to address those and minimise the friction. > There's documenta
