General - Viewport Drawing Styles
I think it's no secret that Blender's viewport drawing configuration settings are currently a mess, and it's great that 2.8 will address this. That said, I think there's still value in me listing the common configurations I use, in the hope that this helps provide one more datapoint for what configurations we should provide.
1) Solid-Shaded Matcaps (particularly that red-clay one) - Useful for seeing the shape of the geometry, with all its contours and such. It does a much better job than the ugly OpenGL fixed-function pipeline. The only downside though is that if any surfaces are axis aligned (and especially have insets which are also axis aligned) it's impossible to see those insets. You have to constantly jiggle the view and toggle wireframes (i.e. as the wireframe overlays have low contrast) to be able to see where they are.
2) Wireframes - This is useful for seeing hidden "inner" details (i.e. checking where stuff hidden below the surface is going, like for insides of mouths, or checking whether things intersect, etc.). Also sometimes used when trying to ensure you're selecting everything.
3) Solid Shading with Textured Solid Enabled - Default for anytime you're not doing any modelling, but want to view the model/character rig, but without the lack of a fully-fleshed out lightrig from making it impossible to see anything.
4) #3 + Only Render - Checking on the posing, without seeing all the rigs, helper lines, and lights/camera, gridlines cluttering the view
5) GLSL Preview - Checking on the lighting, in a "fast" way
6) Shift-Z Rendered View - Fine tuning the lighting using the "real" render engine
Modelling
I don't do a lot of modelling anymore, but have ended up doing bit over the past few weeks to get coverage for all the stuff I needed.
1) Ease of Viewport Orbitting
It's probably already well known that I'm very much an advocate for the "Turntable" style navigation over "Trackball". TBH, even seeing someone navigating the view using trackball is quite nauseating (it's like watching a drunk staggering around, yelling incoherently at passing cars)!
That said, I discovered that the "Mouse Depth" is really useful when modelling, especially to get close to the model and move around it at close quarters. However, it's really not that nice if I want to quickly spin around the model (i.e. it starts catching on different "orbital axes", instead of pivoting around the center of the object as I intended).
In the end, I ended up settingly on trying to toggle the Mouse Depth setting on and off. Since I only really need it in EditMode when doing certain things, I figured that it would be best if there was an easy way to turn it on/off as needed.
Proposed Solution:
3D view header should have a toggle for this. You need to change between this enough that it's a bit of a priority for quick access.
Current Workaround:
Due to time limits and not wanting to have to carry around too many personal edits in my tree (a serious professional hazard for a Blender dev, even with git stash and multiple branches), I ended up settling for adding a quick keymap entry (Numpad *) to control the setting. While not as good as the 3D header button, at least I didn't have to try to figure out how to append buttons there.
2) Ease of toggling "Limit Selection to Visible"
In this case, even though the button is just on the header, I find myself toggling that thing so often (like, once every 30 seconds or so, as I change between wanting to grab everything, and only wanting to select individual things on the front-facing geometry), that it's a pain remembering what the setting is currently set to, and having to press that button to fix things.
When I used to do a bit more modelling, I used to have a hotkey mapped to this setting to quickly toggle it (IIRC, it was Shift-Z, but that's obviously unavailable now :)
EDIT:
As I write up this list, it occurs to me that maybe the problem isn't so much the setting, but more that the selection tools aren't quite smart-enough to do what I want. Specifically, if I think about it, I only really toggle the setting to show all if I want to do a box select to select a whole region of verts (usually an extremity of the model) so that I can move it further in/out, or apply something to it.
So, actually the solution may instead be to have a variant of box select that always selected everything regardless of the setting OR it could first set it to show everything and then begin the select operation. It's a pity though that all the nice modifier hotkeys are already taken there though (Shift-B = zoom, Alt-B = the funky clipping-volume thing, Ctrl-B = bevel).
EDIT: Turns out you have to hit "Z" to enable this behaviour, but you have to do it each time your run the tool, even if you'd done it before. When I originally noted this problem, I didn't realise that this functionality was actually possible, because the headertext is not easily scannable.
Note to all devs: Commas or dots are next to useless if you want to visually delineate different pieces of info in a single-row, text-only display.
4) A way to temporarily disable parenting/constraints/rotation+location on an object to edit its geometry in local/axis-aligned space. (Like a "rest pose" button for objects)
One of the models I was working on was built "in-situ" for the scene it featured in. However, for composition reasons, it needed to be rotated to be aligned to the camera to be readable (i.e. what almost all film animators do with their characters). Ordinarily, you'd just go ahead and rotate the model and be done with it. However, in this case, I knew that I'd still need to edit the thing to add further detailing and/or to adjust the shape/size of it to fit properly, but didn't want to keep losing the transforms of the thing everytime I reset it back to "axis-aligned" state to edit.
The shot in question where this came up
Workaround
The solution I whipped up was to transfer its transforms to an empty (which is less efficient that it can/should be), then used a Copy Rotation constraint to get it aligned right, while still being able to quickly turn it off. While workable, this solution feels much too clunky to be a nice solution in general.
Proposed Solution
What I would really have liked is if something like the Local View (Numpad /) not only isolate the model, but disable (or seamlessly inverse-correct) all transforms/parenting/constraints, leaving it axis-aligned. Actually, maybe that's what Local View should actually do?
Other Solutions?
I suspect others may refer to the "Custom Transform Orientations" stuff to deal with this. I will have to doublecheck if this is the case though.
5) Quick tools to align objects/vertices/etc. by bounding-box-edges/centerpoints/etc.
After working with the aligning tools in modern versions of Powerpoint (which feature all the popup hints/etc.) it feels primitive trying to get things to line up in a nice tidy way.
The "Align Objects" tool is unfortunately a bit hidden, clunky to use, and restricted to only working on objects. For instance, it would be much easier if we could just tell the operator to align the selected objects by the top/bottom/left/right sides of the boundboxes (as seen in the current viewport), instead of having to muck around with a whole bunch of different flags to get the same effects.
6) Images to Planes Addon could be more convenient
For one of the shots, I ended up creating heaps of imported images in a grid-like arrangement.
This was done using the Images to Planes addon (bundled by default in Blender). It's really handy for getting 2D assets into your scene - either as hero assets, or simply as background plates (as in the lighthouse shot). However, everytime I use it, there are two things that annoy me a lot about it:
1) Materials should be Shadeless - If I'm importing an image into my scene as an object in the scene, I practically never want to have its colours faded out by "specular" highlights (ugh, in fact, you know what, I generally hate seeing specular highlights on things in general, but on images, it's particularly insidious as it often comes off as a murky grey desaturation effect that's hard to discern). I also don't really want it to look darkened (i.e. < 1.0 diffuse strength) or to render out black if I have no lights in the scene (e.g. if I'm going for a cut-out puppet show look). In short, it's annoying that I have to go in and check this checkbox for each and every material created. Given that there are lots more options for heaps of other stuff that doesn't really matter much already, it's no brainer to add another option for this, and have it be enabled by default. (Either that, or let's just do away with the need for an option, and just have it do this by default).
2) "Textured Solid" should be enabled by the addon in the active 3D Viewport. Again, it's inefficient that I have to either know about the setting (most newer users probably wouldn't when first trying to functionality), or that I have to remember to turn it on (after importing these images) to be able to see that everything worked correctly. I really don't know why you wouldn't want this to happen after running this operator (if you're in solid shaded mode) - by importing this thing into your scene, you probably want to see how it looks, so that you can easily adjust its placement! It's not a biggie, but again, something like this just makes the workflow a bit smoother.
7) Text Objects should get created with "Shadeless" materials too
While we're on this note, I almost never want/need my text objects to get affected by the lights in the scene. Maybe the add-text-object-operator should have an option to distinguish between 2D and 3D text objects - 2D ones should be shadeless (i.e. what I almost always need when using these), and 3D ones can stay with shaded (as is now the default).
8) Word Wrapping/Auto-Scaling for Text (Objects and Sequencer Strip)
It's a bit of a nuissance trying to find the right size for titles and captions right now. Having operators to help make it easier to do this sort of framing would be great.
Texture Painting
1) "Generated" Images and Loss of Paint Data
I was painfully reminded again how the current TexPaint situation really sucks when creating new buffers to paint into. It's frankly ridiculous that you can spend a lot of time painting on the "generated" buffer and then have it lose all your work without even reloading the file (e.g. by simply exiting viewport rendered-preview display mode IIRC).
Previously, I worked on a patch for this that would auto-save any "Generated" images that had been painted on into the file as "Packed" assets. While I haven't had time to look into this again for a while, IIRC there were objections to the fact that I added an option to tell it to always pack that particular Image datablock.
However, while working on this project, a new thought struck me. Why on earth do we have that "Generated" image type anyway? It's just asking for trouble. Unlike most other apps, we don't have "Parametric Mesh Primitives" - we generate editable meshes immediately - so why should this Image stuff be different?
Maybe, what we should really be doing here is to make the new image operator create proper full-blow images (instead of virtual buffers), and couple that with a change in behaviour whereby any images marked as "dirty/changed" should have their changes saved whenever the .blend file gets saved (i.e. if the image is linked to one on disk, the disk copy should get updated with the changes made, OR if the image doesn't have a path associated with it, it should get packed to the .blend file).
Having lost assets several times while doing this project to this problem, and countless times in the past, it's clear that we need a better solution here.
2) Erasing Alpha Turns Pixels White
Argh! Why?! I want to keep the colour information!
Rigging
I didn't actually end up really rigging anything for this project, as again, it would've taken too long to model everything, animate it all, and then render it all.
That said, I did briefly toy with the idea of creating the PacMan character as rigged geometry. Perhaps it was my lack of practice in recent times (TBH, I think the last time I actually rigged a new character proper would've been over 7-8 years ago now), but this deceptively simple task turned out to be a lot trickier than I was prepared to spend time investigating. Specifically, I found that it's not really that easy to create the iconic open/close gaping movement that works radially.
* If you use armatures, you face the prospect of adding heaps of intermediate "folding bones" (i.e. one per rib) with various weighting issues so that you can hopefully get them to expand/collpase like a fan. However, since the stuff isn't moving in a linear fashion, and you've got all this extra geometry, it will tend to bunch up and cause weird distortions at some point (even if you went completely flat-shaded I think)
* With shapekeys, you face similar issues, except now you're moving all the vertices by hand. However, you still get bunching-up artifacts.
* With curves, you run into other issues (e.g. the changing angle causes the curve handles to start acting in wacky ways, causing the shape to go soft/mushy
I'd be interesting in hearing what ideas others may have found to these kinds of problems.
Animation
In the end, I didn't end up doing much traditional keyframe animation on this project. I ended up deciding against it due to how involved the whole process would be. (In contrast, you can get away with a lot more when it's all hand-drawn, with a loose/rough art style - animating on 2's, 4's, 8's, or even 12'ves in a pinch are all perfectly acceptable within that style.
1) Posing Rigs with Traditional Posing Tools is Nasty and Clumsy
What I did however do was I ended up posing a few rigged characters into a set of static/fixed poses that I could just render out once and not have to completely animate it.
While I've always felt that animating in this way feels kindof restrictive (and certainly, Glen Keane reportedly agrees [?]), I think what really brought into sharp relief just how bad IMO this is, is that the last time I'd been posing rigs, I'd been doing it with my Pose Sculpting tools. While they're far from production ready (in quite a few ways - which is why I haven't really released them publicly for testing), the Pose Sculpting tools were really designed to make this a much more comfortable experience. Thus, one of the big takeaways from this project for me was that I really need to get back to finishing off my Pose Sculpting tools ASAP, as I believe we really can do so much better than the status quo for the 1.5-2 decades...
2) Cyclic Animation Editing is clumsy - Better slope-matching tools needed
There was also another shot that got left on the cutting room floor featuring a lighthouse beam, flashing across the screen, and illuminating some text.
The biggest takeaway from this shot (in relation to animation; most of the tex-paint issues noted above actually happened during the making of this shot) is that it would often be nice to be able to edit the start/end points of each cycle side-by-side, making it easier to adjust the slopes on either side to ensure on steady transition between the two.
Grease Pencil
Bugs/Usability Problems Fixed
While animating the shots, production was initially plagued by several annoying bugs, which made it harder to get stuff done. Namely:
1) Border select would include non-visible GP keyframes, resulting in heaps of keyframes getting accidentally deleted seemingly randomly. The insidious thing about this bug was that it is generally quite hard to spot exactly when/how/why it's going wrong when using Blender. However, you just know that it randomly eats your keyframes when trying to select and delete some, with the problem being that it wasn't too obvious (due to #2)
2) Deleting GP keyframes in dopesheet doesn't redraw the view. The main problem here was that you might not realise if you'd deleted something you didn't intend to delete!
3) Pie Menus were broken after a recent PyAPI refactor. The keymap hadn't been updated, so the renamed pie menus weren't getting found, meaning that pressing the keys would do nothing (with little warning).
4) Sequence Interpolation for Thickness/Strength was working inverted. I discovered this problem when working on the following shot
specifically, in the part where the camera zooms out, I needed to use the Interpolation operators to blend the stroke thickness to get a smoother transition. However, it turned out that because the math was inverted, instead of going from thick to thin, it was jumping to thin and then growing thick. (Or maybe I've gotten it the wrong way around now, but the basic idea is still the same). Clearly this is not the way it's supposed to work! ;)
Tip
I discovered during this project that you can create nice fading effects for things by sculpting the "Strength" values of strokes. That was what I used for the fading effects at the start.
Sequencer
As with all my video projects, this video was edited in the Blender Sequencer. While it's generally ok for simple edits, I do often end up butting heads with quite a few clunky parts of it.
1) Blend-In / Blend-Out settings on each strip
I've lost count of how many times I go to do a fade on a strip by having manually keyframe the opacity values (for images) or volume levels (for sound strips). Wouldn't it just be easier if we just had Blend In/Out settings on each strip? This would save a lot of time lost inserting keyframes just to get a simple self-contained fade effect.
2) Easier retiming tools - Add/Remove Time
Often I want to quickly push all the strips further in time (to make space for a new segment), or pull them closer together (to reduce a gap after deleting strips, or to changing the timings of things). Right now, this is a painful exercise, where I often must go in and manually adjust bunches of strips one by one, hoping that I don't accidentally get some out of sync with the others, and/or hoping that I didn't forget to do something about the marker syncing (ugh, it's far too easy to get those out of sync too).
3) Get rid of the strip-endpoint controls
Argh! Again I've lost count of the number of times where I go to select some strip (especially shorter ones) to move them, but end up accidentally only selecting one end of the strip, and then getting some weird stuff to happen. I almost never really want to have to use those controls, as they get in the way far too often, and they aren't too useful when I do manage to click on them.
If we do still need access to them (and that is a massive "if" IMO), then these should either be under another hotkey, or hidden behind a menu item/option.
4) Make it easier to hold the first/last frame of a strip
TBH, I'm still not quite sure how this works now.
Often, my first attempt is to try to dragging out the last frame of a strip. That sometimes seems to work well enough (or perhaps it doesn't), unless the strip is actually a cutting from a longer strip, in which case it won't really work as it would end up continuing on with the rest of the clip.
On failing that, I then try to split off the frame from the rest of the strip, and proceed to find ways to lengthen that strip (again with variable results).
5) Make it easier to extend the range referenced from a Scene strip
Again, with this one, I'm not entirely sure how this all works. But on several occasions, I ended up having to delete and re-add the strips to get them updating their ranges.
6) Make it easier to reload sound clips from files
Similar problems apply for external videos/sound clips - Short of deleting the darned things, it's hard to force them to reload and resize.
7) Just group Movie + Sound clips together as a single strip unless manually ungrouped. Perhaps there are technical reasons why this works like this, but from a user standpoint, the current method stinks. (Perhaps we should also just allow using the framerate of the input video too while we're at it, and do some kind of automatic resampling / or prompt the user to do so)
8) Split framing, creative cuts/edits, etc.
AFAIK, it's currently not easy to use to sequencer to do any kind of editing where you want to do any kind of split-screening stuff (with clips from different places, mashed together within some kind of template/layout). It'd be cool to be able to do this though. I'm currently considering seriously biting the bullet and getting hold of some better professional video editing tools just to be able to play with this stuff for a change.
9) Text Strip Improvements
It's great that we have this thing, but I think we can all agree that it's really primitive. Two things would solve most of the problems we have right now pretty quickly:
1) Ability to choose fonts - Why on earth we had to make it use that god-awful monospace font still annoys me a lot. Why couldn't we at least just use the standard "Blender Font" - at least that looks somewhat half respectable as a default title font when used at decent sizes! (I know there's a patch, but it's gone silent/dead again in recent months. Again, I'm quite tempted to just push this to master, hackiness be damned)
2) Auto-sizing + Centering - It's really tricky right now to get some title-sized text to fit in the frame and centered nicely, while keeping the text a decent size. The x/y controls right now are kindof nasty for doing this sort of thing. It really should just be a simple, "Center Text" checkbox (which would make x/y offsets from the position), with another checkbox that would shrink down the font if the chosen size makes it too hard to fit the text in the allowed space.
10) Make it easier to switch between referenced scene strips
It would be great to have a way to select a scene strip, press and hotkey, and get taken to another "standard/default/non-sequencer" screen layout with that scene active, allowing you to start editing in that scene. For instance, with something like that, I would've avoided the costly mistake of accidentally deleting GP drawings out of the wrong copy of a scene, losing some animation data in the process, and having to rename a whole bunch of stuff. (For reference, this is probably the shot where the background behind the monitor looks darker than in other shots).
No comments:
Post a Comment