[Bf-committers] The Future of Blender Projects WAS meeting notes
ideasman42 at gmail.com
Mon Jun 18 12:59:53 CEST 2012
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
>> 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
Note that we already worked on this area docs/helpers api functions at
least... but could do more.
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.
> >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
> >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
> 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 used cube/iqm as an example but
>>> I think it applies across the board. It seems to be an
>>> issue. From my research it also seems that it is a low priority for
>>> developers but I think it would be a very powerful project to have some
>>> renewed focus on as blender could be used to spit out whole armies in
>>> batch mode. In that regard I am more than willing to discuss some
>>> improvements but I am not sure that this list is the correct place to
>>> discuss such interface issues.
>>> An API to integrate games engines more effectively is definitely a good
>>> thing(tm). Perhaps they go hand in hand?
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Patrick Shirkey
> Boost Hardware Ltd
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers