I’d also point out, however, that even when Collada support is up and working in Panda, we’ll also be supporting the egg pipeline for years at least. There are too many useful tools that operate on egg files to just toss all of them out.
So, a Blender tool that converted to egg files would not be immediately obsolete.
Ultimately, the plan is for Collada to support more features than egg currently supports, such as cameras, lights, or shader effects–so as that becomes increasingly true the Blender->egg pipeline will become increasingly limited by comparison, but that’s the only downside; and that’s a gradual thing too.
That’s very reassuring, David. Obviously, I did not think you were going to just throw Egg out the window, but the “for years at least” part (with “years” plural) is very good to know.
I got a bit uneasy about the whole “all hail collada” impression I’ve been having lately.
So, in general, there could still be a point in establishing an egg based pipeline between Blender 2.5 and Panda?
And another question, still unanswered, will Panda support saving changes made to the models and their materials from Panda? And if so, will that happen in 1.8 or later? For tweaking stuff on a more “wysiwyg” basis that would be very useful.
I understand this kind of questions about collada support might be on the edge of becoming annoying, but it’s a very important matter.
I know the topic is about Blender and all… but Blender is not the worlds only modelling software. I think there is (or will be) a need for a standalone collada to collada exporter. How else will I add panda specific things (like tagging geometry for collisions) using a generic .dae export script from my chosen modelling software?
Yes and no. I meant what I wrote dae2dae. I can’t export a mesh that’s using dummies for bones from 3dsmax to egg but I can tag some parts of the mesh as collisions. I can export a mesh from max with dummy bones to dae, but I can’t tag it for collisions, there are no panda specific options in the collada export script. I have to hand edit the file to get what I need.
Egg2dae would do me no good it would limit me to what I have now.
It seems valuable and useful to me, though I’m not the one who would have to write it, or who would be using it. But there have been enough people clamoring that it seems sensible. Even if Collada support came online tomorrow, it will be at least a little while before that pipeline has the same level of robustness that the egg pipeline has.
I’m not sure what you mean here. You can already save models and their materials to bam format, but there is not a 100% reliable way to save models from Panda to egg, and there probably won’t be a 100% reliable way to save models from Panda to Collada. And I’m not aware of any projects in the works to add this kind of support–as useful a feature as it seems, it would actually shackle Panda by limiting the kinds of optimizations it can make internally to your loaded model. But this shouldn’t stop anyone from writing a WYSIWYG materials editor in Panda; it just means that you have to write the code to modify the source file (egg or Collada) yourself.
While I accept that blender is not the only 3d package out there, my interest is mainly in taking advantage of the new blender APIs to deliver an awesome user experience with regards to panda3d. I’m not just talking about model export, but any aspect of pipeline I can feasibly reach (tagging, material editing, shader dev, etc).
This may go against the grain for some (since a stand alone utility might be usable by a wider audience), but that’s my agenda.
As I work through things, I’ll obviously try and modularize the components so they can be reused independently where possible, but that’s not my priority.
Given that the egg pipeline will not disappear overnight, and collada support is not here yet, I’m going to assume a system for blender 2.5 that supports egg first, then collada later would be fair, right? I don’t see a reason the same UI can’t have more than one output backend attached to it – unless the whole collada vs egg thing really is that different. I mean, we’re still talking about mesh output, right?
I’ve been hearing collada is coming for about a year, if there is still a lot of work, I’m just gonna read the chicken source and try to port it to 2.5 and finally add some features. Whos interested?
Before drwr’s post we had the impression that egg is going to be tossed away.
Yeah. It just seems to me that every time someone asks about a Blender 2.5 egg exported (either wanting to write it or asking for it to be written) the response is usually “no point, collada will render it pointless”. And while I agree with it to some extend, I think Egg is still useful.
Yeah, but for long term storage it’s not the best way to go. Unless I’m taking the manual’s warnings too seriously.
I thought modifying the models’ original EggData should work fine?
I understand.
It would only make it a bit easier, but then again, it would come at some cost for sure, as you said. If that cost was hindered performance them it indeed seems not the way to go.
Yeah, the only thing is that Blender has collada support built in. Thus there will be no point adding another collada exporter to it, aside of the ootb one. That’s unless we, at some point, find Blender’s collada support somehow incomplete. That said, Egg is still important and having Blender 2.5 support for it would smoothen the transition from egg to collada, instead of doing it in a binary way (Blender 2.4 & Egg now, Blender 2.5 & Dae then, nothing in between). I have a great deal of respect and trust for the Panda developers, but we just can’t expect to get everything right on the first go with collada. It’s too big and too general. At the same time, Blender 2.5 has been out for a time now (granted, it’s been unstable, but that’s changing), it has obvious advantages over Blender 2.4 and yet we don’t use it, because every time anyone expressed such need or will to write one, all they got is “collada is almost here and it will flip the world up side down”…
Exactly. And it’s not that we have so much love for Egg, but it’s too important for us to feel comfortable when we get the impression we gonna loose what we know works for an alternative which is “on the way”.
In general, I think such important changes need more information and less hype around them to avoid this kind of confusion. No doubt collada is cool, but if we didn’t bring it up as the Panda’s holy grail whenever someone mentioned Blender 2.5, and think of it that way, we would probably already have a relatively stable Blender 2.5-Egg-Panda pipeline by now… Which would not in any way, render Collada pointless.
It would make more sense to add more features to Blender’s collada exporter, rather than have chicken support collada as well, then it would be useful to people who don’t even use Panda.
That was the general idea: after collada support would be finished, improve the exporters of 3d modellers, if needed. One of the main points of Collada was support of most 3d modellers out-of-the-box.
Anyway, who is interested in porting chicken to 2.5? I only have experince with the old Blender API and no experience in Python 3.
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.
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.
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!