Retiring mh.jwp.se

After having moved the last of the automated stuff (the APIs) to tuxfamily, I have decided to retire the http://mh.jwp.se site, since it serves no real function anymore. The last few documentation items remaining on the site will be migrated to the main wiki in the nearest future.

Problems with the MHX importer.

The names of python calls in Blender 2.5x are currently changing rapidly. This is fundamentally a good thing, because the idea is to make all changes now, so the API can become stable after the 2.54 beta release. However, it also means that existing scripts, including the MHX importer, break on a daily basis. The situation for MHX is especially tricky, because not only does the import script itself depend on the API, but so do the exported MHX files. The current version works with Blender rev 31508, which I compiled from svn on Sunday morning, August 22, but not with revisions that differ significantly from that. The importer will not work with MHX files that have been exported from older versions of MakeHuman.

Another problem has to do with registration of the MHX importer. An old version (0.9) ships as an add-on with Blender, and its existence somehow makes it impossible to reregister a new one. I have partially resolved this problem by including code which attempts to unregister the importer prior to registering the new version (0.15). This works under Linux (more precisely, on my Ubuntu box at home where Blender is compiled from svn), but under Windows the MHX alternative does not show up in the import menu (at least not on my Windows box at work with a recent graphicall build by Cog). It seems like there are a few glitches in the registration process in Blender.

Hence it unfortunately seems like MHX import will remain broken for some time.

Update 2010.08.25

Now I think that MHX is working under Windows, too. It is still impossible to load the import script into Blender's text editor and execute it from there, because Blender complains that some subclass is already registered. But I found a workaround that works, at least for me. Tested with Blender 2.53.1 rev 31550.

1. Copy the file Makehuman/importers/mhx/blender25x/import_scene_mhx.py to Blender/2.53/scripts/addons.
2. Delete or rename the file io_import_scene_mhx.py which is already there. It must not be a Python file.
3. If there is a .pyc file, delete that too.
4. Start Blender.
5. It should now be possible to enable the new MHX import from File > User preferences > Addon. Make sure that you have version 0.15 or later. The version that shipped with Blender is version 0.9
6. Import the mhx file from the File > Import menu.

These steps should work on Linux as well, but it might also be possible to execute from the editor.

Update your nightly build the smart way

I will first show how to update your nightly builds in a different way. Then I will write a small analysis on why I think this way is better than updating manually by downloading the nightly build everytime.

These are the steps to get this version of makehuman and use the update script for the first time:

1. Install a command-line SVN client :
• For windows users: SlikSVN


• For linux users, use your package manager to install:
  
  1. subversion
  2. libglew1.5
  3. p7zip (this is just for the compression format I use)
  
  
• Unfortunately this is not supported for Mac users!


2. Copy this compressed makehuman version and extract in a desired location
3. Click on the update script:
   
   • For windows users: click on update.bat
   • For linux users with 64bit system: click on update-linux64.sh 
   • For linux users with 32bit system: click on update-linux32.sh 
     
   
   

Now, anytime you believe there is a change in the development, just click on the respective update script again and you will have the latest nightly build (makehuman should not be running when you do this)! This updating method will take you at most 5seconds!

Now I will list the pros and cons of this sort of updating makehuman

Pros:

• If there was a new feature developed in makehuman at this very moment, you will see this feature tomorrow if you use the usual nightly build downloads. But with this method you can update anytime to the current build!
• You will need minimal bandwidth, most update need in average 200-1000kb of data exchange. Thus, if you live or work in a place with slow bandwidth you will have the latest makehuman without downloading a full 50Mb of zipped nightly build everytime you want the latest makehuman build. 
• You will also need less time to have your updates (a second?). And you dont need a new install.
• You will do us and tuxfamily (our server that provides the makehuman download) a favor, by reducing the traffic there.
• You will have a portable updatable version of makehuman (bring it in a usb stick .. wherever you are, its an updated version!.. if you want a new update just stick your usb stick in a pc where subversion is installed and click on the update script).

Cons:

• There will be an extra hidden folder called .svn sitting in every subfolder and root directory of makehuman (this was not the case if you used a nightly build download). But this is not really a big deal, is it?
• You needed an extra installation (SVN command client), whereas in the nightly build download you didnt need that.
• You will have an unstable build (unless the build was done during a makehuman stable release date). But this is also the case if you used a nightly build. In exchange, you do have the most recent features and bugfixes.
  

Code snippets. Introduction to Python scripting for Blender 2.5x

Update: The examples in the original document from August do not work anymore, due to changes in Blender's python API. A second edition, updated for Blender 2.54 and with many new examples, can be downloaded from

http://rapidshare.com/files/425538067/Code_snippets_updated_for_Blender_254_2010_10_17.zip

Major changes:
* The scripts work with Blender 2.54. More precisely, they have been tested with Blender 2.54.0 rev 32510, compiled from svn, on Ubuntu 10.04 64 bit.
* User interfaces (panels, buttons, properties, menus, polling).
* Simulations (cloth, softbodies, particle fire, smoke, rigid bodies, fluids).
Since the API is now supposed to have stabilized, there is a fair chance that most scripts will continue to work for the foreseeable future.



Original post: Time for some shameless self-promotion with only a slight connection to MakeHuman.



I have written a little cookbook on Python scripting in Blender 2.5x. The connection with MH is that I picked up some knowledge about the new Python API when I ported the MHX importer to Blender 2.5. After a while I realized that I had learnt something that was of interest to many people, but no coherent information about it was readily available. With 2,500 downloads in less than a week, I suppose that the cookbook turned out to be useful.

Announcement
Blenderartists thread
Pdf download

Notice to Developers/Commiters

Please update your makehuman copies before commiting anything. mh_core and mh_plugins directory has been renamed accordingly and if you first commit before updating you might commit the mh_* directories to the repository again. In usual cases the repository should be able to determine renames and disregard the mh_* commits, but recently I made some mistake with my commits and commiting before updating may cause some problems.

In general, it is a good practice to follow this guideline.

1. Work with your code
2. Check if it compiles (if you changed anything in the core folder)
3. Check if the application runs
4. Update makehuman
5. Check if it still compiles/run
6. Commit your codes

Edit: I added the option of recursively including all subdirectories (except those coming from .svn) in python system path. This means that you can now try to organize your code in separate folder. For instance, I took the freedom of moving all the gui* codes into a gui folder. I will try not to touch the other codes and allow the responsible coder to categorize it within its new folder (either in app or in core).

APIs moving

After Manuel notified me that there will be some minor changes regarding API documentation, I've decided to move it to to tuxfamily too. As it stands now, it is the only part still remaining on my private server.

Until I have finished this move and updated the build scripts, the old API docs may or may not be accessible in the old place depending on what I happen to mess with.