[Sidefx-houdini-list] New obfuscation of Lookat - am I the only one saddened?
houdini at trinix.ca
Mon May 8 08:39:58 EDT 2017
Good point, the fact the objects used for the constraints are not
visible makes it harder to build expressions related to those object.
From all I've read here it seems that if the tool added the full
reference to "constraints/lookat" and if we had a way to see directly
the parameters we'd be in a good place. What if we had the tool create
spare parameters of the main parameters found on the constraint? The
rule could be that if we create another constraint instead it wipes out
those specially named parameters (so it knows they are related to the
constraints) and builds new one from that new contraints.
I think it's very powerful SideFx and us are able to build a set of
tools that creates constraints from this chop menu with even different
level of promoted control. Ex. menu Look-At / Simple, Look-At / All Control.
On 05/08/2017 05:45 AM, Andy Nicholas wrote:
> Uggh. Yep. Couldn't agree more. I love that it's in CHOPs (I wasn't a
> fan of the original design - too black box), but it's a poor attempt
> at simplifying how people interact with it for so many reasons.
> So sure, the GUI presents a simple interface to applying contraints
> (aside from the annoying viewport picking). But in 90% of cases you
> still need to modify the look-at axis or change the target object, so
> you're going to have to drill down anyway and understand the network
> (that you didn't create) to change parameters. So why try to hide it
> in the first place? Like you guys said already, it needs to add some
> spare parameters at the top level so you have direct access.
> Looking at the top level object, you're able to tell if an object has
> constraints, but you have no idea which constraints it actually has.
> Not to mention that you can't remove them or change their order of
> evaluation. If you add multiple constraints and drill down to look at
> the CHOP network, unless you're quite familiar with constraint CHOP
> networks, you'll still have no idea what constraints you have.
> Lastly, it's the old case of being able to add nodes into a tree with
> a menu system, but good luck if you change or customise the tree
> yourself. The result of menu operations probably won't give expected
> behaviour any more.
> Sorry to the hardworking SideFX dev team but I find the motivations
> behind designs like this hard to understand. It's usually as a result
> of people saying "it's too complicated, can we simplify" without
> thinking it through. Like I said, I don't have a problem with CHOP
> constraints, just how it's hidden behind a pointlessly over
> simplified interface. It just doesn't add anything.
> On 07/05/2017 18:27, Peter Bowmar wrote:
>> Just curious if I'm the only one saddened by the new, much clumsier,
>> "constraints" on Cameras, Lights etc?
>> I recall commenting on how the multiple levels of obfuscation and
>> lack of
>> UI saddened me before, but now that I actually want to use it for
>> something... wow it really slows down the workflow.
>> -You _must_ use a shelf tool for something that previously was a single
>> drag and drop operation. Massive workflow slowdown.
>> -the actual parameters that get created are buried on nodes inside the
>> object itself (!!) so both obfuscation and a massive workflow
>> slowdown as
>> you jump contexts
>> I get that it's "more powerful" in the sense it's a CHOPnet you can
>> intercept and manipulate, and I think that's great. However the
>> aren't worth it since you don't actually manipulate the CHOP data in
>> 99% of
>> simple "LookAt" cases.
>> I'm not opposed to the actual calculation being done in CHOPs, I love
>> like any self-respecting Houdini zealot.
>> I just the think the way the UI and requirement for a shelf-tool has
>> done is a massive leap backwards and makes me sad :(
> Sidefx-houdini-list mailing list
> Sidefx-houdini-list at sidefx.com
More information about the Sidefx-houdini-list