Chicken, an Egg exporter for Blender 2.49 and lower

Ok guys, here’s the new release:
Chicken R42
and the R42 test model

I haven’t marked this release with an official version number (yet) because it hasn’t been tested that thoroughly but it seems to work fine and it does have some cool things over version 1.0, so you might want to try it out if you didn’t try version R33 or if you want ThomasEgi’s fix for external constraint targets.

I would like to post a feature request, if possible. It would be great to lightmap the scene in Blender, and then export it with Chicken. I am not sure what is needed, but as I heard it is possible with Maya exporter…

What do you mean by lightmap the scene?

Blender can be used as lightmapping tool (it has lightmap-baking feature). It would be great to export this lightmap together with other textures, and use it in Panda.

Well, if the textures you are baking to are images that have been saved and are not packed, Chicken can export them just fine. I tested this just now.
What you might want is another script that processes your geometry, creates appropriate UVs and assigns appropriately sized images to faces, bakes a render and then saves those images. That would be awesome, but I don’t think it fits in with an exporter because you probably wouldn’t want to do that every time you export and it has nothing to do with exporting to specific format like .egg.

Hmm… I think what is needed is possibility to export multiple UVs and several texture layers. At the moment Chicken can export only one layer of textures (I can be mistaken).

It does export multiple UV sets, however it can’t map textures to them because that information is currently inaccessible from Python scripts. However editing your .egg file to do that by hand is very simple.
Basically you have to add the following line to the block you want associated with a specific UV set.

 <Scalar> uv-name { name }

where the name within the brackets is the one you gave to the UV set.

EDIT: after trying to test exporting the lightmap with another texture I realized it does have a problem. It’s currently only exporting a texture for the image associated with the currently active UV set so it also doesn’t export a reference to the other texture. So, I guess you’re right and it does need some work to export lightmaps in a useful way. I’ll look into this.

Great! Thanks for the info. I am going to try :slight_smile:

I’ve just committed revision 43 of Chicken with the following changes:

The only modified file was chicken_export.py so you can just grab that from the SVN repository here

To clarify, if you want to use lightmaps you can now have two UV sets, each with their associated face image. These will be exported as separate textures properly referencing their UV set.
For materials with textures, I’ve made some placeholder logic that assumes textures use UV sets in the order they’re listed in the material’s texture list if there are enough UV sets, otherwise they use the first UV set. Hopefully in a future Blender version Python scripts will be able to access which UV set a material’s texture is mapped to.

Anyway, I think you can’t bake lightmaps to material textures, so you’ll probably want to use face images instead. I guess this’ll only start being a problem when I add support for normal maps which can only be specified in a material texture. I’m not sure how I should handle the situation where you have a normal map in a material texture, and a lightmap in a face image.

UPDATE:
The Blender Python API documentation is pretty shitty after all. The material texture UV layer is accessible from Python even though the documentation has no mention of this fact. Therefore revision 44 will fix the fake logic that’s in place with the actual working logic.
Also, I forgot to mention when I replaced NMesh with Mesh I put some code in there that should allow exporting the effects of any modifier on static meshes. I haven’t tested it, but it should work in principle

Hi psiberpunk, would it be possible to make a few requests for your exporter? What i need may be a bit complex and i’m not good enough with Blender to make the changes myself.

My request is about adding more ways to export a scene. The interface would be added with a combo box to choose the scene export mode. We could choose 3 different ways to export our scene. When the user presses this combo box it shows a list with the items:

  1. EXPORT STATIC SCENE
  2. EXPORT LIBRARY
  3. EXPORT STATIC HIERARCHY

Maybe each export mode could be a separate script in bpymodules.

  1. is the way Chicken works at the moment. I think you could ignore exporting animated objects in this mode since in most cases what people want is to export animated objects as a library of objects that will be placed dynamically as game actors.

In alternative we could export a huge static mesh representing the entire scene and use Blender texture baking to bake a lightmap into a texture.

  1. is for animated actors and objects that will move in the scene. This mode would ignore hierarchy and export only meshes, materials and textures - like a library of things. Perhaps this way you could remove the restriction of exporting only one armature and one action anim at a time.

  2. the only interesting thing to export in this mode is an hierarchy of transforms and the tags with user info that are attached to each object, together with a tag “$OriginalMesh”=“the mesh linked” or some other name. Meshes, textures and materials would be discarded when exporting.
    NOTE: Empties can’t be used to do this because we need some geometry pieces to help us visualize the scene we are making. We then discard the geometry and export only the hierarchy with the transforms and tags. This is useful to build a random dungeon or town where all geometry pieces will be assigned to their positions dynamically at runtime.

OGRE supports modes 2) and 3) with separate scripts and this is the most flexible way since mode 1) can be build by linking meshes and materials at runtime and then flattening the geometry and convert it to an octree.

Hi guys, I just committed revision 44 of Chicken to SVN. Here are the relevant changes:

  • Added basic support for exporting Normal Maps (also displays errors in cases where you’re doing something suspect). Automatically calls egg-trans to calculate tangents and binormals for appropriate UV sets
  • Fixed support for modifiers on static objects, modified errors so it only complains about modifiers for animated objects

I’ll briefly explain the new features:
-To export a normal map, you have to assign a material to the object, assign an Image texture to it, that takes UV as map input (you can leave the specific UV set empty and it’ll take the first one you have on your mesh) and maps to Nor. Chicken will warn you if the material is not marked as using Tangent Space normal maps (which is what you’ll use in Panda), and also if the Texture doesn’t have the Normal Map toggle active (because that would mean it’s a height map, not a normal map).
Basically the warnings it throws indicate stuff that won’t affect export but that it won’t look like it does in Blender when you render your object.
To turn on the Tangent Space Normal Maps, look for the Nmap TS button in the material buttons panel (F5) under the Shaders tab.
To flag your texture as being a normal map, go to the texture buttons (F6) and activate the Normal Map toggle button (this will only appear if the selected texture is of Image type).

-To use the new support for modifiers for static objects, you don’t need to do anything special. Just select a static object that has modifiers on it and export it. You should see the effects without the modifiers needing to be applied before export. Note however that this is currently impossible for animated objects and you won’t see any effect for modifiers that aren’t the Armature modifier.

I’ll probably be working on exporting other special textures (gloss, height, etc.) for the next revision.

@zingbat:
Those are interesting features. In fact I had something of that sort in mind. I’ll get back to you when I’ve thought some more about it. For now, I’ll just say I agree we need something like that, but I’m not sure I like the “modes” approach so much anymore.

Hi psiberpunk,
I just downloaded and installed your chicken exporter for Blender (took me a while to find out where to put the scripts exactly), but it doesn’t seem to work.
As soon as I select the script from the list in the scripts window, Blender shuts down immediatly, without giving any error messages.
I’m using Blender 2.45 on Ubuntu 7.10 and the only thing I did was open up Blender and try to open the script, nothing else.
If you could help me get this exporter running without crashing blender that’d be great.

That’s odd as I develop Chicken with Blender 2.45 on both Ubuntu 7.10 and Windows XP. I’ll say this though, whenever I made any small mistake on Ubuntu, it would always crash Blender, whereas in Windows it will tell you what went wrong. You probably made some mistake installing the script and that’s why it’s crashing.
I’m sorry, but I can’t help you because I have no information to work on. For some reason Blender 2.45 is not error-tolerant at all on Ubuntu 7.10. Seriously… modify any script that comes with Blender so it’ll throw an error, and it’s almost 100% certain Blender will crash, leaving you with no idea what the hell happened.

Is there any short manual on how to correctly install the chicken export script? I’ve been looking for it for some time but couldn’t find anything. At last I got the script to show up in the scripts list, but as that doesn’t seem to be enough to get it to work, a manual would be cool.

Basically all you need to do is unzip the file you got from Sourceforge into your home/.blender/scripts directory. Is that what you did or did you do something else?

Hmm, that’s exactly what I did in the end. I noticed That the plugin is called “Chicken $RELEASE_VERSION(.egg)” , could that be the problem?
I managed to start blender from xterm and that got me a load of error messages when it crashed. I could post them here, but it’s really a lot, so here’s only the first few lines:

======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7b1bd65]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7b1f800]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7a4dd81]
/usr/lib/libapt-pkg-libc6.6-6.so.4.5(_Z13ReadConfigDirR13ConfigurationRKSsbj+0x317)[0xb65ac3b7]
/usr/lib/libapt-pkg-libc6.6-6.so.4.5(_Z13pkgInitConfigR13Configuration+0x82b)[0xb65e19db]
/usr/lib/python2.5/site-packages/apt_pkg.so[0xb666dac2]
/usr/lib/libpython2.5.so.1.0(PyCFunction_Call+0x14d)[0xb7e6088d]

Wait, which version did you install? It should not say $RELEASE_VERSION if you downloaded a .zip file from Sourceforge. Did you just checkout chicken_export.py file from SVN by itself and put it in your scripts directory? That won’t work because chicken_export.py isn’t the only Python file that comes with Chicken and it requires that all of them are there and are in the appropriate places.
If you get the script from SVN and not from one of the .zip files I’ve uploaded then you have to checkout the whole thing and run the build-release.py script so it’ll make you a .zip file you can install.

Ah, that makes sense :slight_smile: I just got all the .py files from the svn repository (4 in total) an put them in the scripts folder. I’ll try downloading the zip file and see what happens. Thanks!

now I’m confused, because the Chicken R42 release zip only has a couple of images in it, no scripts. But the 1.0(final) release is 2 years old. So which zip should I download and unpack to get the latest version?
Or is it better to just get the whole checkout and build the .zip through the build_release.py script?

The latest version indeed would involve checking out the SVN trunk and running build-release.py, because it’s at revision 44, and R42 stands for revision 42 which was a few days earlier and thus missing some features.

The R42 release zip does contain the scripts, I just downloaded the file from sf.net and verified it. Also the 1.0 release is not 2 years old since I released it on New Year’s eve 2006 :slight_smile: so it’s only 16 months old.

Anyway, to save you the trouble, I’ll make a zip of revision 44 and upload that. It’s odd that you can’t see the scripts in the R42 .zip though, because I assure you they are there.

UPDATE:
There we go Chicken R44

UPDATE2:
I found out what the problem is. Apparently when build-release.py builds the zip file it sets the permissions of the script files to No Read and No write. If you extract the zip in Windows this won’t cause any problem, but in Ubuntu it will look like they’re not there. Nevertheless, they will extract in Ubuntu, but you’ll have to change their permissions to Read Write in order to use them.
Sorry about that. I’ll try to fix this problem and upload a new file when it’s done.

UPDATE3:
I fixed the problem in the build script (this is not in SVN yet) and now the generated zip file has the correct permissions and looks fine in Ubuntu. The above link now points to the correct file. Note that I didn’t update R42, only R44.

Thanks DmanBXP for reporting this. Perhaps this problem was discouraging other Linux users, and I hope this solves what issues you were having with the script.