On Mon, Jun 18, 2012 at 1:56 PM, Patrick Shirkey <[email protected]> wrote: > > On Mon, June 18, 2012 12:59 pm, Campbell Barton wrote: >> On Mon, Jun 18, 2012 at 10:14 AM, Patrick Shirkey >> <[email protected]> wrote: >>> >>> On Mon, June 18, 2012 9:47 am, Campbell Barton wrote: >>>> On Mon, Jun 18, 2012 at 9:38 AM, Patrick Shirkey >>>> <[email protected]> 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 interface??? 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. _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
