[Bf-committers] Shapekeys, Proportional Editing and GSoC 2014

[Grigory Revzin]

Hello everyone!

I'm new here, so I'm sorry for this being a rather long email.

In short:
1. I'm a 1.5-year Blender user, and a student with C, C++ and Python
knowledge interested in participating in Blender development, and GSoC
2014
2. I was using Blender for creating numerous complex shapekey-based facial rigs
3. I have  proposals and ideas backed by considerable shapekey
experience on what to improve with the shape key editing and a strong
will to develop this area of Blender, I would be happy to talk with
people who work on that area of Blender

In long:
The name's Grigory Revzin. I'm a second-year electrical
engineering/programming student at Bauman Moscow State Tech
University. I've been using Blender for about 1.5 years (and reading
bf-commiters for half a year :), mostly for Source Engine modeling
(using Tom Edwards's wonderful Blender Source Tools).

So one of my latest projects was working on a series on high-quality
shapekey-based facial rigs for a character to be used in Valve's
Source Filmmaker, similar to the facial rigs used in production of
'Meet the...' TF2 videos, e. g. [1]. Creating such rigs usually
involves creating more than a hundred of shape keys for a character,
so I've accumulated some experience with modeling shape keys in
Blender. I coded some bpy tools to support the technology as well,
available here for on github for viewing [2] --- basically, it's just
stuff dealing with different ways of storing shapekey data.

So gradually I accumulated some ideas on what can be improved with
shapekey editing in Blender and I decided to start doing some actual
Blender development (GSoC 2014 did influence my decisions :), and also
a need to do some 'real-life' C coding

Some of the ideas I got are listed below:
1. Blend from Shape needs Proportional Editing, this aids a lot in
creating such facial rigs.

2. A way to transfer shapekeys between two somewhat different meshes
is needed. Suppose there's an array of mostly similar human
characters. Even just having a base to improve will speed up the
production a lot...

3. A more powerful UI for editing shapekeys altogether. This is a
topic on its own, the general idea around it is that the UI must allow
for easier and faster blending and previewing. E. g., in the following
screenshot of Valve's in-house shapekey editor for Maya [3] I'm adding
one shape key into another (Blend from Shape). The horizontal mouse
movement controls the blending intensity, and the vertical is
controlling, how adjacent non-selected vertices are going to blend, i.
e. simple proportional editing with shape blending, etc...

So I decided to start with coding the first one to get familiarized
with Blender, as I already prototyped such a thing with Python (here
[4]) when working with facial rigs; I coded my own simple Proportional
Editing factor computation routine.

I built the Blender source files (MSVC 2008 32bit) without any
problems, the guides on this are good, thanks!, I adjusted small
things, I placed breakpoints and made edit, kept diving in got a good
understatement on how Blender's transform engine works, and how
Proportional Editing selection factors are computed. So my initial
idea was hooking up the transform engine or just the PE factor
computation to Blend from Shape

Unfortunately, I don't see a legitimate way of using the transform
engine in its current form for that task, since it doesn't provide the
interesting stuff to the outside world (ED_transform.h). It's
impossible to use the PE factor computation routines or any other
transform routines on their own
(createTransEditVerts/editmesh_set_connectivity_distance from
transform_coversions.c and calculatePropRatio from transform.c) as
they aren't globally visible and the Blend from Shape modifier is in
editmesh. (Currently, Blend from Shape (mesh_ops.c) just operates
directly on shapekey data.)

That means that editmesh has to have its own PET factor computation
routine, but that means code dupes if the transform engine is
unchanged, which isn't good.

So the solution I propose is making PE factor computation a kind of
global, editor-independent routine, so it isn't confined to the
transform engine (maybe put it somewhere close to BMesh code -- PE
uses BMesh for connectivity distances so that'd be a logical thing to
do).  Apart from shape key editing, I can see some interesting
applications for PET in weight painting (I'm not that sure though).
Anyways, PE selection is kind of a useful thing to have around... The
adjustments to the transform engine should remain small and relatively
easy, too, no huge changes! Then shapekey operators (and any other
code, for that matter) can use PE computation.

Or maybe opening up the transform engine to the outside world so any
part of the code or even bpy can use it, not just the transform ops?
This looks like a bigger task with deeper adjustments, but it's in
line with the principle of genericity from my point of view.

I understand this is a pretty sensitive part of the codebase, so I
seek some advice from the maintainers and module owners.

Regarding GSoC, I'll happily work on any of these tasks if they'd be
considered fitting. I would love to improve the shape key part of
Blender :)
I don't have previous FOSS contributions to show, but I do have an
expirience with Blender and developing Python for it. As for the C
part, I have no trouble reading Blender code (and coding - [5] - this
is a small university assigment, generalized sorting algorithms and a
simple profilier).

If any of these ideas can be considered fitting to the GSoC (or just
fitting into Blender development), I'll happily formulate a more
detailed and polished proposal.

Thanks for your time and sorry for the long text.

- Grigory Revzin

[1] http://www.youtube.com/watch?v=36lSzUMBJnc
[2] http://github.com/revzin/HWMToolkit
[3] https://dl.dropboxusercontent.com/u/91422001/maya.png
[4] http://dl.dropboxusercontent.com/u/91422001/sbfs.png , code here
https://github.com/revzin/HWMToolkit/blob/master/sfm_hwm_sample_project/hwmtk/op_softblend.py
[5] http://github.com/revzin/IU4Sorts, sorry for the comments being in
Russian --- they're redundant anyway