below > On 12 May 2018, at 23:26, Matt Lind <[email protected]> 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 documentation on individual nodes and interfaces, but there really > isn't anything to tie it all together in a harmony that makes sense to the > end user. One hand isn't talking to the other. I am a technical user and > found this to be the most frustrating part of learning Houdini. While there > are videos, the last thing I want to do is spend hours and hours scrubbing > through videos to find the one nugget I need to get to the next step of the > task. > Very much agree the documentation efforts need a further push… these have been left behind by the rapid development and lost tons of examples that helped a lot. > 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. jb > Matt > > Message: 1 Date: Sat, 12 May 2018 09:34:28 +0100 From: Jordi Bares > <[email protected]> Subject: Re: Houdini : non VFX jobs? To: "Official > Softimage Users Mailing List. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21forum_xsi-5Flist&d=DwIFAw&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=fzmLZpiCcc3jRaGy_z5hZ4ClOjRIY3U-E2uo1Q-Lyk4&s=yE_cOiolcVwkjZL5q7mTHV8iEoTF02ZHO8yCBQqtWJ8&e= > > <https://urldefense.proofpoint.com/v2/url?u=https-3A__u7507473.ct.sendgrid.net_wf_click-3Fupn-3D5SmYwFIJXHmC5X9wAP0G6mg4oLGBuQENbeDkYXezg3m6vjHxJcC6rUMd8QE2MtqzowgyFFK4aAsDEzrdrVTV4Q6qbgbc-2D2FgnnpGob6G467zR75G56-2D2BuWz1AMtPXsoVdDXV-2D2BcQeKP7tI8SfI-2D2Feh9je45J8SGNt7RpMTV0RRx7u7ipqHdfH8mUievo2c62JbpLwyOU1kOPaRg2-2D2B2LXheI89DD7bUnzqVaJnQEBTdW08bxgXJLrEoHtcUb0Os6TNOgzkIKzPZXURWx-2D2FSJePMnVU8LRJWmAfJUhgo104PS4WFp-2D2FfJ3N5rbRuTadZflH0O-2D2Fh0M2h4yxib0ouX7j-2D2B2tixig6uQ8oA9tHKwbpeDBX96kNmyQeXTP2xyJ8o0enQb8fdkpC1N1yrj-2D2F86ylX3Yd13AvqA-2D3D-2D3D-5FxtAIgyeGUkaFYUSrrLyyFGCT559IxnI2CalBtcQNCt1ZpP5RSY8m3j3fC3Llx6XJJJcGSKy2rnhFCwKBcQ-2D2FEivZuddy-2D2FtIgmtY6BXRq3bXlgHt80z2VD2zzPUbYqMGDSgUaDfO4zTapneePB0aoSve4cxp5aGXhetvS-2D2BKHLRPZ1XRT7YsM4sJM4WoSQVHdbI3PT2EoRlpdGZVMT8RzwOJdhepaUj9cKapbsZ-2D2BdHcP5Q-2D3D&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=Z6U0dqiDr9C7tT20jA4wmvFpZvvnUEa2y4sqeer3g7A&s=IIeJjTqMRI5D1mw5DEFqoSsTFp_zygLF0Kv82bXg7wM&e=>" > <[email protected]> > > Message-ID: <[email protected]> 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 > [email protected] with “unsubscribe” in the subject, > and reply to confirm. > >
------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
