Thursday, January 30, 2014

Additional Workflow Issues in Blender - Followup for Previous List of Limitations

After mulling over this for a few days, I realised that there were a number of items which I'd actually left off my initial list. So, here goes...

Multiple Camera Handling
It is currently a bit of a pain to switch between different cameras in the scene. You firstly have to select the relevant camera and then set that as the active one. However, IIRC, 2.4x actually used to have a submenu in the View menu for quickly switching between the cameras available in the scene. Even if this didn't really exist, it is something that I think would be quite handy to have.

UV/Texture Management
It stumps every user at some point: Why do you have to assign the image texture for your UV map twice?! Once while in Edit Mode/when editing the UV layout in the Image Editor so that you can see what you're trying to paint in the viewport, and then once again when setting up the material so that this shows up in your render. Wouldn't it be much nicer if assigning the image for the UV Map (for 3d view editing) would just go ahead and create a suitable texture, hooked up to a new material (if none currently exists), with all the setup already done? This would end up saving a lot of people a lot of time...

1) "Shadeless" setting affects the whole material, including several panels shown at top level. Instead, it is currently buried inside the Options panel, making this relationship less obvious.

2) Materials on 3D Texts should default to "Shadeless" by default. Either that, or we need a primitive type for "2D Text in Object Space" which defaults to having shadeless materials, doesn't have any  extrusion on it, and is automatically set up to sit within the camera's view frustrum and aligned to face that full-on.

1) The new Knife tool is hard to use. Perhaps I'm just too used to the old one, but the new one is really hard to grok just exactly how you're supposed to go about using it! Despite following the instructions/hints many times, it always seems to lose the current cut exactly when I've got it placed where I want it, and it refuses to actually accept/apply the cuts when asked. Modal tools done right can be a breeze to use. But when they end up being tightly constrained "interaction tunnels" with little feedback and guidance, they end up being clumsy and infuriating messes.

2) The new modal numinput (in Git master/trunk for the past month or so) is a pain to use. Perhaps the most annoying change here is the loss of the minus-key shortcut for negating changes. Forcing users to try to mash Ctrl-minus to get the old functionality is a major usability regression! 

     For starters, since Ctrl is usually nowhere near the minus key, requiring its use forces most users to have to rehome at least one hand (i.e. hand off the mouse to do a two-handed keypress, then back again) to activate this. Secondly, needing to do this type of negation is an incredibly common operation: a common sequence is to try to rotate something a specific amount, only to find that the direction of rotation is not as intended, mandating a flip (e.g. "r 90 -" is much more common than "r - 90").

    If this modal numinput functionaltiy is really needed (I still have some doubts, but apparently some people still like typing out math expressions to control their one-off interactive transforms!) then the next best alternative IMO is not to use Ctrl-minus, but to actually allow minus-minus (i.e. double-tapping the minus key) to act as the toggle shortcut. For example "r x 90 --". Although still quite hidden, it's easier to hit/activate, and has a slightly addictive mechanism that users whose muscle memory is already familiar with single-pressing minus to invert should be able to easily adapt to. Furthermore, since two minus-signs in a row would be invalid syntax for the Python expression parser anyways, why not make use of this to provide a nice shortcut!

1) When trying to add one of the blending/transition effect strips with only a single strip selected, it would be much more convenient if that operation just automatically added a colour strip to blend against.

2) Insert gaps/time/space should also offset the markers too

3) Creating effect strips when the amount of overlap isn't that clear-cut can be a tad confusing at times....

Default Screen Layouts
1) The current "Animation" default sucks. I'm surprised anyone manages to animate like that, as it's really not the way that I usually test/use the UI's. Instead, the following screenshots are perhaps more suitable (though they could also still benefit from having a dedicated "Camera View" screen somewhere).

 Anim Blocking Workspace- Dopesheet as Main Editor
 Anim Tweaking Workspace - Graph Editor as Main Editor

2) In many cases, we also need a Shading/Lighting view. This balances the need to see live feedback on what the rendered results will be with the need to still be able to quickly move lights and reflectors around, as well as the need to bring up a node tree to tweak the material setups (since most of the complex setups nowadays involve some Cycles shader network or so).  For example:

Shading Workspace


  1. Most of these are common Blender user gripes, a few are fortunately solved somewhat through addon. Francesco Siddi's Camera Selector (part of made scenes with multiple cameras easier to handle.

  2. Psy-Fi has some changes in his GSOC Paint branch that allow the Image Texture to be the default texture type when adding a texture, and also defaulted to UV mapping instead of Generated. This change was to allow an easier workflow to just add an image texture and paint right away, and for the most part his GSOC build on graphicall works well in that respect. For the lighting, I switch to texture draw mode and the lights seem active there, so I move them around there except that mesh lights have no effect until in render draw mode.

    As for the text - I add my text object when in camera view, and then tick 'Align to View', but the default can be set in User Prefs to use Align to View and then it is not an issue. Default material before adding a material is shaded, so I am not sure about changing this for text alone if it will help or create another problem for new users confused about that, since once adding a material it will be shadeless (?) in internal material, but then shaded in Cycles. Cycles doesn't have a default shadeless material per se, only the hack of adding an emission to a diffuse and turning off certain aspects in the ray visibility tab.

    I like your animation screen layouts there, and we usually use something similar depending on the animator's preferences. I myself make up different layouts based on need, and if I do the same style more than twice, I usually save it as a preset in my start up.

  3. Hmm I've always used the NLA for camera switching. I just add an action strip and keyframe for the camera (if its still just one set of keys, moving then just add more keys) and then label it something like "Top-down shot of dog" or whatever is meaningful.

    Never seen the advantage of having multiple cameras.

  4. Two minuses in input as a shortcut... It's overkill IMHO. This will be misleading even for advanced users. When you're doing a lot of things, such combinations can be hard to remember all the time.
    I think the best solution will be an option in Prefs which will determine what order of input to use (old or new). I'm happy with the old :)

  5. @Adhi: Thanks for the link. I generally don't check addons, but in this case, I think there's a case for just integrating this addon (or a version of it) as part of standard Blender.

    @Craig: That's all fine and well and makes some things common situations easier. However, from the sounds of things, it still requires the step of setting up a material+texture AFTER having already created that image for painting. (Of course, if we resolved the remaining issues re ptex integration, matters would be different again)

    Good points regarding the text issues. Indeed, having the behaviour inconsistent here may be worse. In that case, my suggestion about a dedicated primitive for this purpose (perhaps as an addon) would work better.

    @Mike: Multiple cameras are probably more useful when you're just trying to render quick testing (or otherwise) stills from number of predefined vantage points that you'd like to be able to keep track of. With the NLA method, you lose the ability to readily see where each of those might be, without first applying the relevant strip.

    @Liquida: You may be right... though that won't stop me experimenting with this anyway to actually find out instead of guessing ;)