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 <jordiba...@gmail.com> Subject: Re: Houdini : non VFX jobs? To: "Official Softimage Users Mailing List. below On 12 May 2018, at 23:26, Matt Lind <speye...@hotmail.com> 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 <jordiba...@gmail.com> Subject: Re: Houdini : non VFX jobs? To: "Official Softimage Users Mailing List. https://u7507473.ct.sendgrid.net/wf/click?upn=5SmYwFIJXHmC5X9wAP0G6mg4oLGBuQENbeDkYXezg3m6vjHxJcC6rUMd8QE2MtqzowgyFFK4aAsDEzrdrVTV4Q6qbgbc-2FgnnpGob6G467zR75G56-2BuWz1AMtPXsoVdDXV-2BcQeKP7tI8SfI-2Feh9je45J8SGNt7RpMTV0RRx7u7ipqHdfH8mUievo2c62JbpLwyOU1kOPaRg2-2B2LXheI89DD7bUnzqVaJnQEBTdW08bxgXJLrEoHtcUb0Os6TNOgzkIKzPZXURWx-2FSJePMnVU8LRJWmAfJUhgo104PS4WFp-2FfJ3N5rbRuTadZflH0O-2Fh0M2h4yxib0ouX7j-2B2tixig6uQ8oA9tHKwbpeDBX96kNmyQeXTP2xyJ8o0enQb8fdkpC1N1yrj-2F86ylX3Yd13AvqA-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuQRjm0agkzZbZZ2hn4Kci6KMA4QX66wMUg4qN1y5js3uEeka1XIoaWfvqGVa1DCaLHvxej-2B2zDDO-2Fzxi-2FgRCCQ04799XDxSJDv1bEbVAfHh1mnAHAUhWAVxRTELlOKxDiyx12fY9nxZgzPV2illtOt20sAPsi-2FWio9AIUUkg2HDXpo-2FHVUITj4g0ZbvXW81VO0-3D <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_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuQRjm0agkzZbZZ2hn4Kci6KMA4QX66wMUg4qN1y5js3uHojLtaxGv3XFfigzmytNJ85JvzxQhocSBcNokWfXEI7y95Y7T9WPOLEmVUO2Uk0Cp3qspNqAHVHBERBg4e7NcuOeekRHwCx6vP1XByGITJFpsIB6Sk-2Bu8B6Qn7U5MalzyO95HnoGqoag8tfZVL4f9A-3D UaDfO4zTapneePB0aoSve4cxp5aGXhetvS-2D2BKHLRPZ1XRT7YsM4sJM4WoSQVHdbI3PT2EoRlpdGZVMT8RzwOJdhepaUj9cKapbsZ-2D2BdHcP5Q-2D3D&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=Z6U0dqiDr9C7tT20jA4wmvFpZvvnUEa2y4sqeer3g7A&s=IIeJjTqMRI5D1mw5DEFqoSsTFp_zygLF0Kv82bXg7wM&e=>" <softimage@listproc.autodesk.com> 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: https://u7507473.ct.sendgrid.net/wf/click?upn=4NJpoo1h1GOdyqBB3sJimai-2BQC-2FGskUXuPx0XSl6rNdr5Gg0XscjA7dk-2BFQcvfCTrPyNVTe21bXODeNjelkdcj7ocyG7Qzl-2FhzVov6tKwKhbBDR2u3exFK4IROOT921VAcHZqAtQcS5XkMLA-2Bi88Gw-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuQRjm0agkzZbZZ2hn4Kci6KMA4QX66wMUg4qN1y5js3uHCNwlaBkmG7eDGsQx3fa9Map6L-2BWj1PfjsJvFT4sbYVr0AX4uknDGJkolSMbHZF8nXl6HoJ-2FPiaDdTeXBoJZSHXJ-2FQIU23C2WiEh5fPmSfQvDk5YopphnoJKvqmJOxgI5CKmEA3R6d-2BpPClqc43nw0-3D ------------------------------ _____________________________________________ Softimage mailing list Softimage@listproc.autodesk.com https://u7507473.ct.sendgrid.net/wf/click?upn=4NJpoo1h1GOdyqBB3sJimai-2BQC-2FGskUXuPx0XSl6rNdaJFGAiSAtRlLIFMPKKS9zYUVvw6tqP6OR-2BwHxAPVGvQ-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuQRjm0agkzZbZZ2hn4Kci6KMA4QX66wMUg4qN1y5js3uDAo32baxnbu68cAH-2BmvAm7KSKiV0R4U-2Fp-2BUZgrTGloM5c3awN0rrTlT3tLfNjyNwPhKwOC-2FFqVCeMz7lX2kZFh2ZzhIFFuNEK5Uf4gl0piUFnjLm38zgyCilJM6gxlw7I6g1uHbd-2FxODN1TdvlCzbs-3D 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.
