Learnings from Promo Video Project - Improvements Needed for Blender

In this post, I'll go over some of the problems I encountered while working on the promo video, along with some proposed solutions for some of these. As always, this process has only highlighted the need for developers to seriously use the software they (and/or their fellow devs) write: it's only through such exercises that we can really pick up on things that are a pain in actual usage (vs any largely hypothetical assumptions we may hold/have held).

NOTE: At least one of these improvements is now in trunk. Namely, the "reverse" option for the Build Modifier (5c74ac2). More details later...



Big Ticket Issues

1)  Asset Management and Creating Self-Contained + Reusable Assets/Effects
There were often times that I found myself wanting to be able to group a bunch of related objects together into a single easy-to-reuse package, and to be able to easily specify what the key parameters for this asset were so that users of the asset can just deal with those (instead of having to dig through the setup to find what they need).

For example, say you have a few custom properties on different objects within a group, which have been rigged up to control a whole bunch of other properties to get some desired effect. In my case, there were 3 such instances: a time control for controlling the progress of the tree transitions effect (from no fruit, to covered in fruit, to looking dead), a similar control for the landscape becoming an arid desert, and the a custom control on the spotlight (affecting energy and halo size) in the super seedling scene. In all of these cases, what you'd want to do is to have a way to just expose these custom controls so that these parameters could be easily animated on the different instances of that asset, allowing these to be animated to better fit within the scenes where they're being used (instead of having to do that externally first).

This concept is probably already familiar to most users - it is basically what we can do now with Group Nodes in the Nodes Editor. Similar things can be done in other packages (e.g. Houdini) in other contexts too (admittedly, their whole setup is a giant node graph!).

From where we are now though, the most likely candidate for this is Groups (which are kindof the defacto "Asset" type already now). Custom properties on those groups could be used to expose the necessary parameters as part of the asset, though hooking those drivers up to the internal properties used is likely to still pose a bit of a problem - likely a depsgraph/eval-graph problem once again... Then, there's the issue how exactly we end up exposing user-editable copies of these parameters.


2) Tool for completely covering a surface (or within a volume) with randomly placed objects, and the option to quickly hand-tweak the placement of said objects afterwards to improve the distribution (if it screws up)
The closest that we come to this currently is to create a mesh to act as a duplivert emitter - a technique I ended up using heavily in the promo video for all manner of purposes. Specifically, in the end, I often ended up creating these meshes entirely by hand, by Ctrl-Clicking to manually place vertices where I needed to see them.

Particles turn out to be an absolutely terrible solution for this problem (though they are the obvious first choice). Perhaps it's just our current particle system which isn't quite up to the task, but I found it was often impossible to achieve the desired results - namely, having complete coverage of the surface (or the volume - as seen from the front at least) without leaving any noticable large gaps all over the show and without spawning on top of existing particles while large gaps still exist.

Using a grid as a quick starting point was also out of the question, as those are far too regular, and the lack of tools to introduce randomness into the arrangement makes rectifying this hard.


(On a related note, a brush-based tool for using a physics-based approach to automatically "splat" objects onto a set - e.g. a carpet of leaves - would be a great addition for set dressing workflows...)


3) Tool to apply a general wavy-noise distribution/transform on to a mesh
Related to the above is a quick way to generate a messy/random field of vertices. While we could use the grid primitive to create a basic set of vertices to work with, getting these into an irregular arrangement turns out to be quite a pain.

Sure, we have the existing noise tool, but that thing needs a separate texture to be created before it can be used. In many cases, using a full-blown texture for this purpose seems a bit too heavy-handed. And IIRC, the randomise transforms operator only works on objects.


4) Event-based relative animations
It's taken a while to come around on this idea, but yes, it makes sense when doing motion-graphics type work (vs character anim) to sometimes want a way to have animations firing on particular events. For example, an effect where particles scale up to their final size everytime one of them is keyframed to appear. (Even better would be to time up a "pop" sound whenever this happens).

How exactly we set this up remains to be seen, but it's definitely now on my radar of things to ponder about in the next few years when I get the time :)

Simple But Annoying Quirks
5) Lack of helpful tooltips in many areas
Specifically, although most parameters nowadays have some kind of tooltip attached to them, these don't always provide much assistance for figuring out how exactly you're supposed to use them to get to desired results.

Part of the problem is a technical/historical one: namely, that initially many of the tooltips were really written in the context of being something you'd see when browsing through a list of these properties presented in the Datablocks view in the Outliner or in some kind of API doc. In such contexts, a lot of the tooltips we have now make sense. However, in many cases, the tooltips are used mostly when users are faced with some unknown UI element and are trying to figure out how to interact with it - namely, what it does. On this level, what we've got is admittedly a huge failure in many places. To deal with this problem, we may have to resort to having 2 sets of tooltips - one for the UI, and one to provide additional technical/supporting info in abstract contexts.

To focus our efforts though, the tooltips are particularly bad in 2-3 places:
      5a) Particle Settings
      The main problem here is that there are many very technical settings, with non-obvious value mappings (e.g. "shape" and "clumping" for children - which extreme causes them to bunch inwards, and which outwards?!). Instead, a few of these simply restate the obvious from the names (if the tooltips are present at all, and/or not simply showing the overall enum's tooltip). More useful tooltips here should provide general hints for what the results of certain "key values" of the parameters concerned will result in.

      5b) Nodes
     The node editor is particularly bad, in that not only are there no tooltips, but the ones that do show up end up showing what is ultimately completely useless internal implementation detail! It does NOT help that the alpha parameter is labelled "Default unconnected socket float value" (or something to that effect)! Nor does it help that similar weirdness can be seen on other less obvious parameters.

      5c) Enums/Comboboxes/Dropdowns
      With many of these, there are a lack of descriptions for the enum items, meaning that in many places, you just get meaningless generic labels for the property/operator in question, instead of what that thing will actually result in.

6) Animation render progress doesn't show overall progress
Currently when doing animation renders, you cannot easily check how far through the full render things are without actually checking the frame number, and trying to recall the frame range you'd used (this gets harder if you don't start from frame 1!). Meanwhile, on Windows, the progressbar on the taskbar just keeps zipping off to 100%, showing the progress per-frame instead.

It's a relatively small tweak, but one which would make a huge difference. The only question is whether we still want to be able to see how long a particular frame is taking. It's probably still useful info, and a dual-progressbar may work better in that case.

7) Group Management Tools are a bit flaky
It turns out that indeed it's quite confusing to figure out just exactly which group you're dealing with when trying to ensure that a whole bunch of related objects all get added to the same group with a single action.

And nested groups - one within the same file referencing another group - is apparently broken. Yeah... Because depsgraph XD

8) Changing Text3D alignment options changes the alignment "in-place"
Although there are some occasional times when the current behaviour for what happens when you change the Left/Center/Right alignment options make sense, it seems that far more often, it makes more sense that the opposite is true. That is, you often go about changing this after finding that the origin is in a weird place (which makes certain types of further adjustments awkward/cumbersome - e.g. the origin defaults to being in the lower left corner, but when you want to ensure that the text is centered within the frame, that placement results in needing frequent rearrangements). In such cases, it's more likely that the text overall is already in a good place - it's just that the origin is in an inconvenient place.

9) Visibility Keyframing
Indeed, it is a pain to manage currently, as you need to keyframe two properties, and manually make sure that they are in sync. I'm not sure what the best solution here is yet, though I suspect an operator button on the toolbar to "Animate Show" and "Animate Hide", which would set both properties accordingly then insert a keyframe for both would do well. Either that, an operator which sets up a custom prop which then drives the needed properties... Regardless of what solution we take, fixing this issue would be good.

10) Extend GLSL preview to letting us preview the effect of more types of lighting/material change effects.
In particular, with node materials where you switch between two different materials, you cannot preview the results of the switch just in the viewport (since only the last selected material's diffuse colour gets used).

The same goes for visualising the strength/effect of the spotlight's halo via the camera view, without having to render everything out.

Small and Simple Tweaks
11) Build Modifier does not work in reverse
Along with dupliverts, the Build Modifier was one of the most useful/important tools I ended up dealing with. Specifically, it was responsible for getting all those clouds of dupliverted objects to pop up and multiply over time.

However, there was one problem: this effect only works in the forward direction, meaning that you couldn't have a reverse effect of these clusters fading out (e.g. the apples being picked from the trees). Instead, I ended up having to settle with simply hiding all of them outright at the same time. That was since I was using the official 2.69 build instead of a custom build at the time (due to various instability problems coming from both my mingw64 builds and recent changes in the Git trunk code), so wasn't able to quickly patch this feature in as needed.

Now that I've finished working on this video project though, I've been able to quickly hack this up. It turned out to be even easier than I had anticipated, and it is now in trunk.

12) Sequencer timeline only shows timestamps in seconds, instead of breaking this down into minutes+seconds
One thing that irked me with using the sequencer was how it didn't break times > 1 minute into minutes and seconds. Doing so would make time management so much easier. I've since started a task/report on developer.blender.org to look into fixing this...

13) Occasional crashes when switching screen layouts, with a 3D View open in "Rendered" mode, and the preview render still running
Likely it's a threading-related issue. "Simple" in the sense that you just need to find the cause of the bug and fix it... NOT ;)