Please separate user interface code from the data handling c

[m.e]

Is it possible please to separate out the user interface code from the rest of the application?

At the moment we have code like LoadTaskView in guifiles.py, which is supposed to be reading a flat file and loading it into a data structure, but for some reason has lots of calls to the gui3d code. Could you separate these into different procedures and preferably different modules?

Sorry if I seem to be posting a lot on this but it really is troubling me.

[mflerackers]

It is being separated, but slowly as this is not high priority for the makehuman program itself, there is a lot more to do to get us to 1.0. If you have been following the commits, you could see that the mh library is being turned into python objects instead of just a function library. Also for some time we have been moving functionality into the human class instead of this functionality being directly in the gui code. I know it's far from finished, and the goal is to be able to use the human class free from the rest of the gui, but as I said, it's not high priority for us at this moment. If we had more coders it would go faster, but right now that is not the case.

[m.e]

OK good. I have not got into it deeply enough to start following the development history. It's going to be six months before either MH or blender 2.5 are ready anyway, so as long as things are progressing it should be OK. What sort of things are you doing?

[mflerackers]

You can see what we are doing in svn here:

http://code.google.com/p/makehuman/updates/list

What we still have to do here:

http://sites.google.com/site/makehumandocs/road-map

Manuel is still working on the auto-modeling, and I have to finish the background image gui.

In between I'm working on refactoring, optimization and rewriting the C code to be more object oriented towards python. Also I'm adding GLSL support to the C engine, and should move to VBO's instead of client side lists. The GUI still needs to be reorganized needs some more controls and key navigation, and I need to write the text and font system. For the text I need more dynamic meshes as text can change frequently. The GUI has themes, but I need to add the GUI and real time switching for it. For the GLSL shaders I have to redefine the API and create a cache like I did for the textures. But now for alpha 4 I first have to add pan and zoom to the image background.

[m.e]

Which is the 'human' class? I cannot see one (I'm at svn 349). Or is this the Object3D class? There seems to be lots of classes with GUI stuff in them.

By the way, if you get the GUI separated out, you will find it easier to test.

[mflerackers]

human.py might be a good place to find the human class . And it's really not so interwoven with the gui as you think it is. Yes the Human is derived form an object so it is easier to place in the GUI for now, and we use the progressbar in some places where we shouldn't, but it's a work in progress, our goal is not a human generation library usable in all sorts of applications, that would be more of a by-product, our goal is to make an intuitive application to quickly model humans. Most of the target application code and algorithms are free from gui code, and if some aren't, they will be in the future. I don't have any trouble testing my code, as I don't need blender to test it .

[m.e]

human.py might be a good place to find the human class .

My fault; indeed it is there.

And it's really not so interwoven with the gui as you think it is.

You might consider moving the load and unload code into the Human code (and away from the file selector GUI code). There still is GUI code in Human; evan if it is just a bit of GUI code, it means that the whole GUI still needs to be dragged in, just to access the class.

I don't have any trouble testing my code, as I don't need blender to test it .

No, but you can test automatically in batch if your code does not have any GUI code in it. See http://pyunit.sourceforge.net/.

[mflerackers]

I know, that code still needs to be moved. But as you can see, age, weight, ethnics etc is all manipulatable from the human class, in previous iterations it was still in the gui. As for unit testing, I write a lot of gui code, so I can't test that without the gui. The other algorithms I rewrite and optimize, but they are pretty straightforward, so I would be surprised to find bugs there.

[m.e]

I have got some code running, which I have posted in the other forum at viewtopic.php?f=9&t=201&p=3316#p3316. This hopefully will explain what I have been trying to do. So it is possible with the existing code base, though I did need to rip some code out of existing modules.

Now I need to wait until the pose system is running so I can use it for animation, which what was motivating this exercise.

[Manuel]

Hi m.e.

I appreciate the work you are doing to try an integration in Blender, but instead of this extra work for a parallel script, why not help us write a good importer for Blender? In particular, about poses, we should write an official script that correctly imports the full MH character, including an automatically generated skeleton and linked in the blender scene, with precalculated weights (and even with facial rigging). This is a very important feature, a lot of users are waiting for it, and it's less complex than running MH inside Blender (it will not be so easy, in particular the pose GUI, trust me). We actually don't have enough resources to write it, so, if you are a Blender expert, your help is appreciated.


Regards,

Manuel