i’d be quite interested in a chicken port.
havent massed with the new api yet but it cant be harder than the old one, right?
i’d be quite interested in a chicken port.
Guess I should probably say something… New api is a lot easier - I did actually sit down and plan an entire 2.5x Chicken - intention was to clean room it, using the old code for reference where useful, as the current Chicken is atrocious in every sense. I don’t have much free time these days - if I did I would help/do it myself in a weekend, as I am already very familiar with how to do this, but I can certainly give anyone who is making a serious effort access to the chicken sourceforge page when they have a new version to upload. Given my lack of time if this project is to be continued it makes sense for me to hand it over to someone else anyway.
I’m not so much concerned about the new 2.5 API than porting to Python 3, which Ive heard being called another language.
There are not so many differences, it’s quite easy to pick up. A lot of the things are the same, you just need to know the important differences, e.g. you’re supposed to use print() as function, not as statement.
Python 2 to python 3 is not an issue - differences only take minutes to pick up, though old habits do always die hard, so you will find yourself doing things the old way quite regularly. Your mistake is thinking that it will be a port - the structure of chicken is a mess, and needs to be trashed, and the Blender api is completely different, meaning about 70% of the current Chicken code needs a complete rewrite regardless. Even the basic structure of Chicken is both ugly and incompatible with Blender 2.5. It will be a complete rewrite - all the current Chicken code will provide is a reference for the many subtleties required.
I would also consider changing to an action based system for animation - with Blender 2.5 that makes a lot more sense, rather than the current timeline system. Especially as the Collada exporter is action based, so it makes sense to start moving people onto that way of doing things (You also might want to consider using Collada’s scene based approach for deciding what to export, or at least having an option to do it that way.).
I can’t declare I will help writing it at this moment because I have never dealt with Blender’s Python API, either 2.4 or 2.5. I started digging into it, though, so as soon as I get the hang of it I would definitely like to help.
Additionally, this initial work by Hypnos has been laying around for a while now => [minimalistic exporter for blender 2.5). I don’t know how good or bad it is – it sure is very basic, but can’t judge the quality of this basic stuff – but I thought a link to it should be here, so if anyone decides to dig into this matter right away, they can at least take a peak into it.
lethe, I didn’t realize you were the author of Chicken. Good deal. I’m not looking to take over the project, but I’d love to pour over Chicken’s source for examples of how the machinery should work, then perhaps reorganize it from an architectural perspective (since it sounds like that’s what’s needed). Am I right in thinking the last release was taken directly from trunk (rev 93)?
Setting up a separate project on bitbucket should mean that “passing the torch” shouldn’t be required now, or in the future. It should also give you a convenient way to participate (as your time allows). Mercurial will be a snap if you’re already used to svn (if you aren’t already familiar).
I’d urge you to offer any insight you have from working on Chicken though. As I said, I’m new here – new to panda, and to blender, but I have a few years of building tools for maya (in python) under my belt so I think this will be a fun project. I can’t promise anything either! I work a day job, and this is “for fun”. All in all, I’m just excited to be working with blender 2.5x (heh). I think there’s room for something magical to happend panda-wise.
I’m sure a lot of people in the community would be grateful to you if you could pull this off. I know I would. And knowing how this forum and community works, you don’t need to worry about support in your way through it.
Blender 2.5 to egg is something I would LOVE to see. Lethe told us a long time ago that he would not do it
because it would just be quickly replaced. Why waste the time? I have been waiting a LONG time for this COLLADA thing to come into being but it has not.
I am on the Blender dev list and you see them talking about merging Collada into truck and then you keep seeing them say lets wait on that. I know they are hard at work on it but how much longer must we wait? At this point I have been just doing my art in 2.4 and hating it. 2.5 is WAY better and we need an exporter now.
Exporting to BAM is just a waste of time because that format is not stable between editions of Panda3d and is a binary format, as I understand it, which leaves us with Egg format. Egg format is not going to be dropped so it IS useful to have a Chicken that exports to 2.5 to EGG format! It sounds like that exporter will continue to be of value for some years to come.
I would suggest that because Lethe has no time but REALLY knows what is needed, that he should write up an outline, sort of play team leader. Then those with more time can implement his design. That should let Lethe put his great and deep knowledge of Blender and Panda3d to best use without using up to much of his very limited time. At the same time it should be enough to guild those with the time to program into writing a great exporter.
Douglas E Knapp
I am not the author - just the maintainer, as it got handed over to me when the previous owner didn’t have enough time - guess there is sort of a tradition in that regard;-) And I use git for most of my revision control these days, and whilst not as familiar with Mercurial I can certainly manage it.
There is a slightly newer version of Chicken than R93 on sourceforge actually, but its only some very esoteric bug fixes that are in code that needs replacing anyway, so I wouldn’t bother.
I will try to help if I can - at the very least I might recognise some bugs with which I am particularly familiar.
Some general advice would be:
- The current Chicken requires Panda, when most of the time it exports without using Panda at all - make it optional this time!
- The current chicken is plagued with badly defined modularity, especially in terms of methods that have too much functionality in them, and globals that get changed in hard to track ways - some proper oop would really help. Feature creep is basically to be expected once an initial implementation is working, so try to make sure that it is a design that can cope with that - consider subdividing tasks more than you typically would (Especially materials/textures.), and even having plugin-like constructs.
- Plan for animation from the start - its the most complex part, and a lot of the problems with the current exporter can be traced back to animation being hacked in.
- Testing the current Chicken is a pain as installing it takes multiple steps - there needs to be a script that automatically installs it to your current (and potentially non-standard) Blender install as well as packaging it.
- Make sure installation for the end user is easy - the vast majority of questions I had to field were about installing it. Blender 2.5 makes this a lot easier, but I was considering the idea of making a .blend file you open that then does the installation - that is entirely possible now!
- Remember command line scripting of it - its very useful, especially for automatically going through a bunch of test .blend files.
- There is an entire directory of test .blend files on sourceforge, for regression testing - have a look through it, and copy whatever is of use.
Good luck, and I’ll try to be of some assistance:-)
To comment on Douglas’s stuff:
Yeah, I had rather thought that Collada support would exist in Panda before Blender got much past alpha, but it hasn’t played like that unfortunately. But Blender has all the Collada stuff in trunk now - they were for a while keeping a separate branch that was ahead of the main branch for Collada, but I thought they had decided it was stable enough to stop that now.
Whilst I am certainly willing to help I am not sure high level management is really needed - this is more the kind of project that a bunch of people discuss in a forum, such as this one, and then someone goes off and gets the ball rolling, before others then join in with the bug fixes and extra features. I think that will get to a working version much faster than if we over-plan it - the needed design is not complex, and should be quite obvious to anyone who has enough oop experience and knows how to jot a design down on a few bits of paper first - the real trick is after the basic version is working, of getting rid of all the bugs. That and getting animation working can be a touch hairy, and I expect will result in some rather comedic bugs when transformations go wrong!
Planning for animation from the start – for sure. So as to be sure all the cards are on the table, the manual states eggs can contain:
A Model (static geometry)
An Actor (dynamic geometry)
An Animation (to be applied to an actor)
Both an Actor and an Animation
Is there anything else that could be missing from that list?
Alright, great. Lots of direction for me here. I guess at this point, it’s time for me to disappear and get started on the planning and experimentation (on the blender side). I’ll be back with more questions as I get into the details. Thanks so much for all the guidance!
Okay, I’ll have a look at 2.5 API
btw, chicken R93 ?
Ok, just had a look - R91 is the most recent release, R93 is what it is up to in the repository, so R93 is the absolute latest.
That is more of a users view of an egg file - they are internally a lot more complicated than that. I would have a look through the list of classes in the Chicken exporter as it stands, but also check out http://panda3d.cvs.sourceforge.net/panda3d/panda/src/doc/eggSyntax.txt?view=markup, which is basically the actual spec. I would also get some egg files and read through them, including some that have been laid by the current version of Chicken.
To give some kind of overview an egg file starts with the coordinate system to use, then it has the materials and textures used throughout and then you have the object hierarchy, and finally the animations, which can be in a separate file (It is possible to have one skeleton shared by multiple meshes in separate files that have a common pool of animations - you will need to support that, though its not hard as your basically just appending the files for the single file export.).
The object hierarchy is precisely that - a hierarchy of objects, which can include empties, static meshes and animated meshes. Animated meshes come with a skeleton, which is then referenced by the associated animations.
Objects with geometry contain vertices and polygons, and if animated also contain joints to form the skeleton. The class will inevitably have an inheritance tree that has empty at the top, from which a static mesh inherits, from which an animated mesh inherits. Al 3 of these object types can be in a single egg file.
A vertex always includes its position, but typically has a surface normal and often tangents/binormals as well. A polygon indexes the vertices it uses, its textures and materials. Joints (Bones) give their matrix transform, in global coordinates, as all transforms are in an egg file (Watch out for that one - Blender will only give you back local transforms, so you will need to convert. I/the current Chicken source can help with that.) and the vertices that are members of the joint, with their weighting for vertices that are members of multiple joints.
An animation has some basic properties such as name and framerate but then gives the sequence of states for each bones transform.
I’m sure there is other stuff that I have forgotten - expect to write a lot of if statements!
Such is life (thought perhaps there’s another way through delegation). The egg spec is exactly what I needed. What a good read. Shame really. Any time I look at a format spec like this, I lament the fact “it could have all been expressed in json”. Heh.
More of a general question – is there ever a need in the production process to go from egg to blend? Do I need to worry about the round trip?
People often ask for this and the reason is obvious. Here on the community people use different 3d modelling packages and often only share the egg files, which is kind of universal format for us. This brings the problem, that egg files you get from others are hard to modify. You can try to convert the egg to x and import that one in blender, but usually it ends up in a mess.
That said, a way of importing eggs into blender would be great, but I suggest you don’t mix it with the chicken exporter.
I have been living without a two way translator forever with panda and can keep doing so but it sure would be nice.
I would say do the blender -> Egg first and then if you still have the time and desire do the egg to blender bit.
BTW thanks for doing this!!
Douglas AKA Human-bean and magick-raven or even magick.crow
Someone above threw in JSON.
Speaking about file formats, is there an egg parser around, which is not part of Panda (or at least is independent of other panda parts)? I agree with lethe that the exporter should run independent of Panda, but for that we’d need an external parser library/module.
blender -> collada -> egg -> panda idea:
How similar or how different is the egg format from collada?
Could we work around the whole issue with the egg exporter using a collada exporter in blender and converting that collada file into egg? I know it sounds like more of a work, but we can go sure that blender’s collada export will be further developed and maintained for sure. And on the other side we don’t know how much time it will take till Panda’s collada importer is ready.
Collada has two problems. The Blender exporter does not work AND the Panda side does not work. Shoving it all through Collada would just bring us back to our first problems and make the system reliant on Collada. (Note, does not work is likely overstated but you get the idea.)
Having the ability to check with Chicken if my models looks good in panda previewer has in the past saved me a LOT of time! I hope when you say that you are taking Panda out of the exporter, you are not talking about removing this feature.
I have used this feature to make sure I had the right model, to see if the model faced the correct way and to see if the colors were working.
The ‘blender -> collada -> egg -> panda’ route already exists, and does in fact work for static geometry - it just does not support animation or advanced materials right now, making it useless in the real world.
By removing Pandas dependency what I mean is Chicken will run without Panda, but have features that only work if Panda is available, unlike now where it won’t run without Panda, but the vast majority of exports do not require it to use Panda at all.
With regards to importing egg into Blender I agree with everybody else - export is the important one, and to be honest I wouldn’t bother with import myself - that is just not the purpose of the egg file format.
Another thing that I thought off - be careful with materials and textures - due to the differences between Blender and Panda you will often find cases where the same material or texture is applied to multiple objects in Blender, but for Panda you have to have multiple versions of the same object due to setting differences that are pushed into a material/texture in Panda but kept separate in Blender. This involves some automatic renaming - you might want to copy what Chicken currently does, or do something different.
Making the exporter Panda independent doesn’t mean it can’t use Panda. I’d only be happy if the core functionality works as standalone and all those additional features give a warning on missing panda.