The MakeHuman API Project

[joepal]

We've just announced http://www.makehuman.org/blog/the_makeh ... mhapi.html.

Comments?

[brkurt]

We've just announced http://www.makehuman.org/blog/the_makeh ... mhapi.html.

Comments?

Hello Joel...I'm primarily interested in the clothes api. I incensed some of the elite of Marvelous Designer by suggesting that clothing needs a hierarchy of drapes and folds, and some way of controlling planar intersections/deformations through an animation.

What I've learned from MD4 (amidst the flames) was that right now, no one has a complete character solution: flesh, soft clothing, hard bling.

Oddly enough MH is presently the closest to this, and a lot of this has to do with the open-source philosophy and the congenialty of the MH development team.

So...I'm going to add a lot of clothes to the MakeClothes library--about when 1.1 comes out--and my stuff will mostly be flowing robes, and ancient clothing.

I'm quite interested in how the new API will handle large volumes of flowing cloth.

[Solkar]

That API is definitely a good idea.

Just one more use case, related to viewtopic.php?p=26434#p26434 pp

I obviously need script access to the vertex data of characters with certain significant features.

Afais, the most plain workflow currently possible¹ is
(A)load char via gui => (B)export char to .obj via gui => (C) import that .obj in my script code
That's a little like scratching the neck with the big toe.

Even if MH command line interface would permit building an ABC pipeline, that would still yield a huge overhead because of latency of program start and char customization carried along.

Thus, having fine-granular API calls for (A) and (B) at one's disposal, would be a huge asset for use cases like this.

¹Feel free to correct me if there's a more plain workflow

[joepal]

That API is definitely a good idea.

Just one more use case, related to viewtopic.php?p=26434#p26434 pp

I obviously need script access to the vertex data of characters with certain significant features.

Afais, the most plain workflow currently possible¹ is
(A)load char via gui => (B)export char to .obj via gui => (C) import that .obj in my script code
That's a little like scratching the neck with the big toe.

Even if MH command line interface would permit building an ABC pipeline, that would still yield a huge overhead because of latency of program start and char customization carried along.

Thus, having fine-granular API calls for (A) and (B) at one's disposal, would be a huge asset for use cases like this.

¹Feel free to correct me if there's a more plain workflow

I'm planning on allowing full vertex data access exposed via some (as of yet unformulated) easily understandable API subset.

However, you don't need MHAPI for this. You already have full access to the mesh data inside MakeHuman, and can already run custom made scripts via the plugins 7_scripting.py and 7_shell.py which are bundled (although not enabled) at least in the stable releases. If you begin a local script with something like

Code: Select all

mesh = G.app.selectedHuman.meshData

.. then you can access the data structures and the methods via the "mesh" variable.

I'm not read up on the exact structure here, but if you enable the "data","shell" and "scripting" plugins, you can explore the data structure under the utility tab which then appears.

The workflow would rather be:

• Start makehuman
• Do GUI makehuman stuff
• Run custom scripts to finish what you couldn't do in the gui

Ok, so MHAPI would expose these things in a somewhat more readable form, and until that's available it might be a bit cumbersome to guess what various data structures actually mean. But it's theoretically possible to work with it already.

Concerning MHAPI otherwise, it's still very much on my todo list, and I will need it personally for a project during the spring. However, work has a tendency to swamp me.

[Solkar]

@joepal.
Many thanks for the datailed info!

The mh internal script exec framework and editor does (yet?) not scale well enough - aside from limitations of the in-proc editor I e.g. need to plug certain diagnostic tools in a pipeline after my script, which is merely impossible if its output is mixed with arbitrary mh log messages.

Also, that specific script development is ~ 5% mh-specific and 95% general 3D and maths, thus it should not be governed by requirements imposed by doing it mh in-proc.

---

But - looking at the data made available to the scripting framework lead me to the notion of turning the mh app into a simple server that can deliver data to scripts-in-development by arbitrary rpc mechanisms.

Consider e.g. this rudimentary IDL

Code: Select all

module mhapi {
    module idl { /* precaution againt name clashes */
   
        typedef float  real_t;
        typedef long   size_t;
        typedef long   index_t;
       
        // for easy unicode migration
        typedef char   char_t;
        typedef string string_t;
       
        /*
            flattened to to 1d to enable versatile marshalling 
        */
        typedef sequence<real_t> real_array_t;
        typedef sequence<index_t> index_array_t;
       
        /*
         * information for reshaping the flattened arrays
         */
        struct ArrayDescriptor {
            size_t    vertex_dim; // = 3
            size_t    uv_dim;     // = 2
            size_t    face_granularity; // = 4
            size_t    vertex_adjadcency_granularity; // = 4
            char_t    order; // "C", "F" 
        }; // struct ArrayDescriptor
       
        exception ELoadError {
            string_t msg;
        };
       
        interface IModel {
            const string_t unit = "decimetre";
            const string_t orientation = "right-handed, Y up, face Z";
            // no struct consts in idl[1]
            readonly attribute ArrayDescriptor array_descriptor;
           
            readonly attribute real_array_t coords;
            /* many many more attribs */
           
            void load(in string_t name) raises (ELoadError);
            /* many many more methods*/
        }; // interface IModel
       
        interface IServer {
            string_t ping();
            oneway void terminate();
           
            readonly attribute IModel currrent_model;
        };
       
    }; // module idl
   
    /*
     * References
     * [1] http://www.omg.org/spec/IDL35/3.5/PDF/ 5.10.1
     */
}; // module mhapi

Given an arbitrary (not neccessarily CORBA) rpc server app running in the script exec subsystem of mh that "Model" Servant would in likewise arbitrary fashion expose the existing internal api to the the outer world.

What do you think?

I implemented a downsized (xmlrpc) version of that interface with SimpleXMLRPCServer and that works together with a very thin client layer based on xmlrpclib in an external script (HEUREKA!).
I suppose that even omniORB could be convinced to work in that exec environment, but I haven't tested that.

The obvious advantage of developing such an API top-down from an IDL is that this is a manifestly interface-centric development method.
It's, btw. not even stuck to a specific rpc mechanism. Given one has an implementation for, let's say, plain xmlrpc, migrating to e.g. CORBA or SOAP (there are tools to migrate an idl to xsd/wdsl) would not require much changes to the business code server- or client-side itself, just the framework around it would need to be replaced.

I'll tidy my - very thin - xmlrpc spike a little and add that code here.

Looking forward to your feedback!
Regards, S.

EDIT : added the code of my xmlrpc spike. It relies on a model named "Testling" to exist.
Of course, running the server makes the mh app unresponsive until the server terminates (by calling the 'termnate' routine from a client), and the popup "Good job!" popping up at the end is not exactly nice, but it should suffice for getting a first impression.

[Solkar]

But talking about about that "data" utility -

I'd really like to know where to get the data for masking away helper geometries' faces from.

I did a bounding box based selection to isolate a subset of the legs I want to work with, and with some numpy masking I almost got what I wanted, but with a strong emphasis on "almost"
[ attachment ]
That is a fragment of the left leg seen from the right.

The inner shape is the fragment of the left leg I was aiming for.
The outer shape is the helper geometry I need to get rid of.

Not by exporting obj (or whatever) and re-importing that file but by using the internal data interface @joepal mentioned.

EDIT: Skip that.

It's

Code: Select all

G.app.selectedHuman.meshData.face_mask

with its zeroth entry fliipped to False.

[duststorm]

A CORBA RPC interaction is one possible way, note though that it is bound to the restrictions of the AGPL license, which is that any service you create that uses MH over a network or through some form of IPC must be licensed and the source released under a GPL compatible license.
There is also a (not very well maintained) commandline fork of MakeHuman that is a bit less restricting if you need integration into a pipeline.

[Solkar]

A CORBA RPC interaction is one possible way, note though that it is bound to the restrictions of the AGPL license, which is that any service you create that uses MH over a network or through some form of IPC must be licensed and the source released under a GPL compatible license.

And why exactly do you think I defaulted the xmlrpc host to localhost and added this

##############################################################################
# Copyright (C) Solkar 2014
# memberlist.php?mode=viewprofile&u=16965
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
##############################################################################

(emphasis mine)

even to those little spikes I posted?

[duststorm]

Ho giddyup, no need to get on your horse.
I read and took note of your header message.
I just stated this for anyone getting ideas. You see, we often get a vistit from people looking to integrate MH as an interactive character creator into their closed-source game or MMORPG (or something of the kind). To some, it cannot be stated often enough that MakeHuman is not a library. (not unless you are willing to give back to the community at least)

It's perfectly fine to attach other GPL (yet non-AGPL) components around it. As long as the implementer realizes that the total package -- when linked to MH -- is covered by the AGPL.
A thin wrapper around it will not lessen the license from AGPL to GPL, much in the same way that wrapping a GPL library with a thin wrapper or pipe will not free your application from GPL requirements.

[Solkar]

Ho giddyup, no need to get on your horse.

If I'll ever need assistance to "get on my horse", you'll be the first to know

To some, it cannot be stated often enough that MakeHuman is not a library. (not unless you are willing to give back to the community at least)

I'm none of those "some" you envision, so please stop pestering me with your related wisdom here.

You see, we often get a visit from people looking to integrate MH as an interactive character creator into their closed-source game or MMORPG (or something of the kind).

This is - again - besides the point here.
Neither did anyone except you discuss any "closed-source" apps here, nor propose any RPG.