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? 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.
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
if __name__ == "__main__":
register()
with
if __name__ == "__main__":
write_out('/path/to/file.egg')
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.).
Is there a list of things which can’t be done in a single pass?
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?
