> On May 13, 2018, at 10:00 PM, Matt Lind <speye...@hotmail.com> 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.
