This thread is getting really really useful, thanks Matt… More comments below.
> On 13 May 2018, at 21:00, Matt Lind <speye...@hotmail.com> wrote: > 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. > There are historic reasons for this to be the case, in the very early days those were completely different programs, that was then unified and finally new contexts appeared (like VOPs) and lately MATs > If nodes from one category cannot work with a node of a different category, > then that's a problem too. > They deal with different data, if you look at it from that angle it makes easier to build your own strategy/style. > This is where documentation is sorely needed. > Agreed. > 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? > My basic approach is to keep as much as possible in SOPs and rely on Wrangle nodes to parallelise tasks. While VOPs are fantastic I find that, like ICE, these networks get big quickly (even more so in Houdini) so I prefer VEX Wrangles right now. Regarding CHOPs, I rely on them to do signal processing and rely on input/output devices such as MIDI or joystick to drive things. And of course constraints now that they are executed as CHOPs. And that is pretty much it. > When should a SOP be used in place of wrangled nodes, or vice versa? > If you want to have full authoring control, go for Wrangle nodes, otherwise I default to SOPs as I want a simple yet robust data management and speed is not an issue. > 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. > Agreed > 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. > If you ask me that is not the case with ICE, you really need to roll your sleeves at first and get to grips with not that different approaches. I a way I feel we tend to swing goalposts when we talk Softimage and Houdini, for example, Rendetree was a blessing but has quite a few gotchas as well, the same with ICE. > 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. > The way I organise it is by following the same approach than reading books, from top to bottom, from left to right. And when things get hairy I build subnetworks, netboxes and put down background images and notes to take the next guy in line with the way I have structured the scene. > 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, > Subnetworks in Houdini. > 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. > Would you really want an schematic view like the one in Soft??? I left that behind since XSI 2.0 when I discover the explorer… tons more value in my humble opinion. > 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. > Are you comparing the same thing? ICE tree vs VOPs makes sense and they are not that different at all. Rendertree vs MATs make sense and again are not that different anyway. ICE or rendertree vs SOPs does _not_ make sense to compare. Nevertheless with regards with clarity, the only thing I miss from the rendertree is the ability to see thumbnails quickly and easily, something I need to requests at some point to SideFX. > 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. > A tip, use subnetworks, honestly. And if you don’t at least use net boxes that you can see in the data tree. Also, you can have two network editors looking at the node and its contents at the same time, which makes it terrific with complex scenes with many levels of subnetworks. > 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. > I am sorry but I don’t agree with this _at all_, I find much easier to follow the complex nature of a character and its relationships in Houdini than Softimage, may I remind you about following operator stacks, constraints, expressions buried in local transforms vs global ones, scripted operators, relationships with blend shapes, mixer curves vs curves? On a shitty curve editor? Or the mini editor for time-warps, groups assignments collisions, delta changes????? Then you add to the mix character maintenance, versions, multi-resolution… You need order in both applications and a certain approach everyone understands and comforts to but overall, you will see less concept clutter in Houdini although may be more wires. ;-) cheers jb > 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://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-5FxtAIgyeGUkaFYUSrrLyyFGCT559IxnI2CalBtcQNCt0FbiUxYtn6yHlWA6xMWzORS-2D2F6ttvh3H2Y5-2D2BUmxGSznlWx5UUUkEobyfEw-2D2BiM367AP-2D2F2XQKmV2D4mSPod0uxfPBRyHoMPVcTQ3u5ViiG-2D2FSxwvVlovR-2D2Bd33Wj6tQWLeP0bPIu0AzS3tHWfMRcSIq5Fw2tPM0TkZOzmtTebnuScUeNq5QpxhBYr3ZQEHM59IwSB8-2D3D&d=DwIFaQ&c=76Q6Tcqc-t2x0ciWn7KFdCiqt6IQ7a_IF9uzNzd_2pA&r=GmX_32eCLYPFLJ529RohsPjjNVwo9P0jVMsrMw7PFsA&m=IMplZKKOuoDL5uedA4ZHoOaQBRAMft5emUuoFQMHNSI&s=ZD5phH36xldJOBNE4TI1rvbJtCJmq5qoZdWa3UrwUpY&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-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=>" > <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: > 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.
