Yet Another Blender Egg Exporter (YABEE r13.1)

[ninth]

Egg exporter for the Blender 2.5, 2.6

Exporting:
- Meshes
- UV layers
- Materials and textures (Partially)
- Armature (skeleton) animation
- ShapeKeys (morph) animation
- <Tag> and collision otions export through Blender's "Game logic" -> "properties"
- Non cyclic NURBS Curves


Old versions: R7, R10/B2.57, R11/B2.57

New versions and docs: link

Doc by Preusser http://www.2shared.com/document/jfPo7OPo/yabee.html

Last revision: 13.1 for Blender 2.66

Mercurial repository http://yabee.googlecode.com

[Anon]

Yeah, I was thinking of doing one, I'm really tired of waiting for the full Collada support. I think a 2.5 egg exporter wasn't written till now because both Blender 2.5 and the 2.5 API were beta. Blender 2.57 is considered stable, but the API, according to the site description, is still subject to change. I'm not sure if it's worth to write one now, but I also don't think there will be any huge changes to the API.
Just to make sure, is this reference up to date?
http://panda3d.cvs.sourceforge.net/pand ... iew=markup

Also, I have written some similar tools, but I've never worked with morphs, so i could use some help on that.

BTW, this won't run on 2.57.0
this line:

Code: Select all

from bpy_extras.io_utils import ExportHelper

[ninth]

Thanks for the link. It's tonn of works to make support all panda egg features )
Hm. I test script on Blender 2.57.1 r37344 Ubuntu 10.04.
An example of the interface code I get from the standard script, going with blender, so you can see how this line looks in your version. For example in *.OBJ exporter.
Also you can remove interface code and replace

Code: Select all

if __name__ == "__main__":
    register()


with

Code: Select all

if __name__ == "__main__":
    write_out('/path/to/file.egg')


to avoid use interface functions.

[Anon]

I guess this proves one more time that Blender 2.5 API is still changing, the code you had written for 2.57 didnt work for 2.56, thats why Im wondering if its worth to wait a bit more.

[ninth]

Yes, I agree. But I think in the future changes will not be so major that the script could not be brought into compliance with the actual version.

[Nemesis#13]

Yay, finally somebody started on this
On time or not, many surely will find this post very useful.
Since there are a few people interested in this, how about starting a community repo now (github, bitbucket, sourceforge)? We could use this code as a base.

Will try it out by chance.

Thanks again.

[Anon]

if we are going to work together, we need to follow some common set of rules. We can break down the script into blocks. I think we could have every entry as a separate function. Make it so you don't need to know the internals of each if you want to add something new. This will also make it easier to modify the code.

I'm still getting used to the new 2.5 API.

[ninth]

If someone makes a repo, I'll be happy ;)
I'll try to break down the script into the blocks, but it may be a bit difficult. For example: Blender holds UV information in faces, Panda - in vertices.

[Anon]

I dont know what you mean by Blender holding UV information in faces, Ive never heard of such way.
I think you can do:

Code: Select all

uvs = []

for face mesh.faces:
    for vert in face.verts:
        uv = vert.uvco
        uvs.append(uv)


These are called "sticky" UVs, there is also face.uv, maybe its the one you are using.

[ninth]

I get UV layers throug the object.data.uv_textures becouse object can contain more then one UV layer

[Anon]

Didn't think of that.
Im not sure.

BTW, can you post a link where you downloaded your Blender version? The latest one from graphicall doesnt even render any buttons.

[ninth]

I use ppa repository
sudo add-apt-repository ppa:cheleb/blender-svn

MultiUV


As i known, multi UV used for shadow maps, normal maps etc.

[Anon]

Yes, I know that Blender and egg support multiple UV maps. I just mean I'm not sure how to access them. From what you say by your method you get face UV maps, but you need vertex UVs, right?

As for Blender 2.57, I'll just try the not so new versions and see if they have the same problem.
EDIT: OK, got a working 2.57, reading your code now...

BTW, is there no epydoc/ doxygen API reference for 2.5? I got used to those.

[lethe]

I can provide access to the sourceforge repository if people are serious about developing it - not sure if that is what people want to do or not. I would want to make sure that the revision history in there remains however, so people can continue to get the 2.4x version (i.e. deleting the existing files (Though you would probably want to keep the exisitng test suite) and then checking in the new once would be fine, as the history would remain, but resetting the repository would not.).

As for breaking up the functionality I would strongly recommend separating it into classes, preferably spread over multiple files, and using inheritance where appropriate - Chicken did that and it *still* ended up as spaghetti - without at least them I suspect you would be doomed. Also be careful of the material/texture system - its very easy to end up with a never-ending sequence of if statements, as there are so many possible combinations.

[ninth]

Anon: http://www.blender.org/documentation/bl ... pi_2_57_1/ it's all that we have
As for me - i mostly use dir/__doc__ and examples.

lethe: thanks for advice ) I'm not sure about the seriousness )
I'll continue to publish the script in this thread and if someone will want to add something, then we'll can think about the repo)

[Anon]

I don't see a need for classes. I've never needed them in Blender scripts.

As for the repo, we could just make a new one. If it is written from scratch and doesn't work the same way, I don't see a point in calling it "Chicken exporter". It would be misleading. People would think it works the same way, has the same GUI, etc.

[ninth]

imho, object-oriented style is not only useful but also just a good tone)

Yes, it's really not chicken. But I would like to make a script similar with chicken's features.

Added hierarchy conversion for the selected objects as shown below

[Anon]

imho, object-oriented style is not only useful but also just a good tone)

I think for a "simple" exporter it wont help much. I know its not "simple" to make, but what the script basically does is retrieve data and write it to a file. I dont see how inheritance and polimorphism, etc. could be used here. I do use oop in most of my projects, but I think an exporter could even be put in a single module. Ive worked on some importers/exporters and other Blender scripts before, so I dont think im a noob, but the formats were alot simpler than egg. Many Blender exporters seem to work the same way. If you could give an example of how using oop would help here, then I'd be happy to learn.

But I wouldn't wrap everything up in a class just for the "good tone" (Im not really sure what you mean by that).

BTW, if its just preference, then Ill still be happy to work with you on this, its not a big deal.

[lethe]

Go look at the current Chicken exporter if you want to see why its a good idea. It divides the functionality up in a neat and easily extendible way - and yes, inheritance is used because a static mesh is an empty with extra stuff, and an animated mesh is a static mesh with extra stuff. It also makes handling the hierarchy and the shared nature of materials/textures relatively neat (I know Chicken is a terrible example, as its a total mess, but its the most relevant one to give.). Also note that an export can not be done with a single pass, at least not sensibly, so you have to store data - if you use functions alone you will end up either emulating objects or duplicating calculation, both of which would be silly.

Most exporters are relatively simple, because they are simple file formats with few features, but egg is not a simple file format. Collada is a format of comparable complexity - if you look at Blenders Collada exporter it has multiple classes in multiple files extending to thousands of lines of code (In c++, but the point remains.).

[Anon]

Also note that an export can not be done with a single pass, at least not sensibly,

Is there a list of things which can't be done in a single pass?

Most exporters are relatively simple, because they are simple file formats with few features,

Yeah, I know. Ive worked on one which supported materials, textures, bones and animations, but it was still alot simpler than egg.

You have worked on the Chicken exporter for some time, do you have some suggestions on how to structure the code? Is the current one okay? Or should we just work and restructure the code in the future if needed?

[lethe]

Its not so much can't be done as not sensible to be done - for instance animation data is in a different location to the associated mesh, potentially in a different file; textures and materials are at the start of the file, and due to the differences between blender and panda you often need multiple variants of a what is a single material in Blender, as Panda pushes more rendering information into the material, so you actually have to go through and analyse all the objects before you can generate the materials/textures at the start of the file and the animation data at the end of the file, or in a separate file completely. When building the hierarchy and doing instancing you often need to reference other meshes, which might not be created when your creating the current mesh, so that has to be done in a separate pass. From a gui point of view its quite useful as you can reuse the code that analyses the mesh to check that it can be exported and provide the user with the relevant options. Its also quite helpful as it separates the steps - analysing the data and working out what you have versus writing the data. There is probably other stuff that I have forgotten - at the end of the day such an approach is more flexible, so when you find yourself implementing something you didn't initially plan for its not as painful.

The current Chicken is a total mess, but only at the code level and in its abuse of globals etc due to the many hacks that have been used, but structurally is not unreasonable, except for that fact it has 90% of the code in a single file, which is several thousand lines long - if I was reorganising it I would give each class a file, as well as a file for each of the interfaces (command line and gui.). But as a general rule of thumb I would have an object for each entity that exists in the egg file and then the code would first map Blender onto that structure before doing the export via a hierarchy of method calls. Chicken goes a bit further than that, as it copies everything from blenders data structure into its custom data structures - whilst more convenient I wouldn't go that far as python is not very efficient at packing data into memory, and the Chicken exporter is very slow and memory heavy as a result - I would be more inclined to have 'VertexSet' objects rather than individual 'Vertex' objects, that wrap the relevant blender object without copying it, but allow the storing of additional info as required.

[ninth]

Well, as for the objects, here my current hierarchy:

Code: Select all

Group
|-EGGArmature

EGGBaseObjectData
|-EGGJointObjectData
|-EGGMeshObjectData
  |-EGGActorObjectData


BTW, added armature export )

[Anon]

Wow man, youre fast.

ERROR:

Code: Select all

 'Armature' object has no attribute 'faces'

It seems like you didnt check properly if the object was a mesh or armature somewhere. In the B2.4 API you could check that by object.getType() or I guess type(object.getData()).

[ninth]

Simply select the mesh with the armature modifier. Do not select armature.
------------
Fixed.

[hawginsck]

I am soon going to test this out, but I just wanted to let you know, that this is sooo awesome !!?!
Thank you

[ninth]

Thanks )
-------------------------------------
Added basic skeletal animation export.
Animation is written in the same file as the model.
Parameters are set in the constants: FPS, START_FRAME, END_FRAME

[Anon]

progressing pretty smoothly
No errors for me.

[Nemesis#13]

Code: Select all

@@ -192,8 +192,7 @@
         
     def collect_vtx_normal(self, vidx, attributes):
         if vidx in self.smooth_vtx_list:
-            no = self.obj_ref.data.vertices[vidx].normal * self.obj_ref.matrix_world.rotation_part()
-            no = map(str, no)
+            no = self.obj_ref.data.vertices[vidx].normal * self.obj_ref.matrix_world
             attributes.append('<Normal> { %.6f %.6f %.6f }' % (no[0], no[1], no[2]))
         return attributes


worked for me after applying this.
keep in mind that map is a class in python 3 and it returns a map object, unlinke the python2 function map() which returned a list.

Big thanks for this script

[ninth]

Nemesis#13, thanks, fixed )
Also added some functionalities to work with shape keys (morph) animation.

Anon, not so good as we would like. There were some issues. I will create a separate topic.

[Bamboo_Pandamonium]

For me, the script will create a file, but the file won't load in Panda. I could be doing something wrong. It tells me something about the <Texture> (a tag?) and then says, "all matching files on model path invalid (the model path is currently: "/c/Panda3D-1.7.2/test folder;/c/Panda3D-1.7.2/etc/..;/c/Panda3D-1.7.2/etc/../models")." I don't know what that means.