[Bf-committers] rigging [was: Re: The Future of Blender Projects WAS meeting notes]

Campbell Barton ideasman42 at gmail.com
Mon Jun 18 14:20:59 CEST 2012

On Mon, Jun 18, 2012 at 1:56 PM, Patrick Shirkey
<pshirkey at boosthardware.com> wrote:
> On Mon, June 18, 2012 12:59 pm, Campbell Barton wrote:
>> On Mon, Jun 18, 2012 at 10:14 AM, Patrick Shirkey
>> <pshirkey at boosthardware.com> wrote:
>>> On Mon, June 18, 2012 9:47 am, Campbell Barton wrote:
>>>> On Mon, Jun 18, 2012 at 9:38 AM, Patrick Shirkey
>>>> <pshirkey at boosthardware.com> wrote:
>>>>> On Mon, June 18, 2012 8:55 am, Campbell Barton wrote:
>>>>>> @Patrick Shirkey,
>>>>>> please don't request specific features on this thread - this has the
>>>>>> effect of turning all planning threads into wish-lists which active
>>>>>> devs tend to skip reading & not take so seriously.
>>>>>> This is a developer list - if you want some specific engine or one
>>>>>> feature back from 2.4x you can code it right?
>>>>> Of course.
>>>>>> What you _could_ suggest is an api for game engines to be more easily
>>>>>> integrated - so adding engine support worked better (something
>>>>>> Apricot
>>>>>> project was supposed to resolve but didn't really).
>>>>> I was attempting to make the point that the whole process of exporting
>>>>> a
>>>>> model with an active rig is not obvious.
>>>> Could you explain what you mean by this? - for the developer or for the
>>>> user?
>>>> What should be changed/improved?
>>> >From a Developer perspective it seems to be a bit hard to program for
>>> the
>>> exporter API when someone like Eihrul has troubles with getting the iqm
>>> exporter to work cleanly. That suggests to me that the learning curve
>>> for
>>> getting things right is a bit steep.
>> Exporting armatures is tricky - but I don't think the API has bad,
>> more that we could use better docs, examples and possibly add some
>> helper functions (get the bone relative rest/pose in different spaces
>> - its a common problem that different formats expect this data in
>> different spaces).
>> Note that we already worked on this area docs/helpers api functions at
>> least... but could do more.
>> see:
>> http://www.blender.org/documentation/blender_python_api_2_63_release/info_gotcha.html#editbones-posebones-bone-bones
>> http://www.blender.org/documentation/blender_python_api_2_63_release/bpy.types.Bone.html#bpy.types.Bone.vector
>> also x_axis, center, children_recursive ... are helpers to make the
>> api easier to use.
>> However I think converting between different rig representations is
>> also inherently difficult - especially when the format has for
>> example, bones that dont have a length - or the length moves along a
>> different axis then in blender.
> I agree that it's inherently difficult. IMO, there is some distance to be
> traveled before the way Blender handles this process can be considered
> user friendly.
>>> >From a users perspective it's really quite difficult to export a
>>> skinned
>>> and rigged model correctly. So that suggests the interface is too
>>> complex
>>> or abstract. Perhaps there needs to be a wizard that steps through the
>>> process.
>>> >From an advanced user perspective I see no good reason apart from "no
>>> one
>>> has had the time/money" that it is not possible to apply a set of
>>> standard
>>> (preset) movements to any mesh (or mesh type). That would allow very
>>> quick
>>> prototyping of potential models for game engines and virtual 3d
>>> environments.
>>> arm, finger, leg, toe, head, eye, mouth
>>> These are rig configurations that are essential to exporting 3d models
>>> and
>>> it seems like a glaring omission that Blender doesn't provide some sane
>>> and well tested defaults which can be quickly applied by a normal user.
>>> If
>>> they are already there then they are well hidden or abstracted.
>> Have you used rigify? Sounds like this should do what you want.
> I saw it but it was not obvious to me how it is supposed to work. Even
> after watching some video tutorials it stills seems confusing as there is
> a lot of implied knowledge on how to handle blender, what if/ik is, how to
> navigate the interface, etc...
> While rigify is a good place to start it is still not obvious how to
> export a "rigified" rig to an external format. For example unity provides
> a convertor that strips off all the unnecessary rigging that rigify
> creates before exporting. With other exporters they just silently or
> obscurely fail. In the case of iqm and the Buck Bunny model I spent
> several days figuring out what to disable and communicating with the
> developer of the exporter just to get the mesh to export correctly. I
> tried but failed to get the skins to work. I didn't even get close to any
> kind of movement in the exported model. While I had the time and patience
> to justify the effort I know that it turns off a lot of people from even
> trying.
> I guess my plea is that Blender folks consider the usability of the
> rigging system and exporter process some more. All the power is there but
> it is a mind boggling process for us mere mortal users to take on. The
> possibilities for rapid 3d prototyping for movie and game systems by
> solving this usability issue are enormous.

What is confusing from your mail is you confuse ease of
rig-development with ease of rig-use with ease of using blenders

These may all be issues for sure - but makes it hard to follow when
user/developer issues are mixed up in same suggestion.

>From what I can see all that you suggest can be done with normal
development - no need to plan it or have it as some target for a
release. - but some developer would need to spent time on these areas
and focus still.

More information about the Bf-committers mailing list