Collada is an incredibly powerful file format - it certainly has the capability to support all these features, and many more - the question is if the pipeline as it exists supports these features, and that I do not know. As I said, I need to sit down and spend some time with it. For backward compatibility dae2egg should be fine, assuming we keep its code and the future panda collada loading code in-synch (Crazy not to.), and I don’t think bam files are going anywhere - we would just be converting collada files into them, rather than eggs. Its all just data manipulation at the end of the day - nothing complex, just tedius.
As for the current Chicken my intention is to maintain it for now, until such time as we have a proper 2.5 solution, but that mostly just means the occasional bug fix - I have no new features planned for it at this time.
Yeah, thats what I mean: does Panda’s dae loader supports all the engine specific stuff already, even if there isnt a special panda3d dae exporter yet.
right
But its just that I don’t get whats the advantage of replacing egg with dae if we’ll still need to use custom dae exporter to get engine specific data?
In theory we don’t need to use a specific dae exporter - dae supports everything that Panda needs, and much more. In practise I suspect the Blender dae exporter is going to need some work - but if we can do the work to the standard then there is no reason why those changes can’t be merged back into official Blender. At the very least I can stop fielding questions from people who can’t figure out how to install Chicken!
I don’t know about dae2egg’s capabilities I’m afraid - as I said I really haven’t spent any time looking into this in detail. I just know this is the direction the panda developers are intending to go.
The advantage of dae is its a standard - most 3D modelling programs have the ability to import and export dae built in - this is a major improvement over a Panda specific format where we, as a community, have to maintain exporters for every program out there. This is currently causing problems in that maya and blender are the only two well supported programs - every other modelling program has limitations and/or hoops that need to be jumped through.
I thought dae is a format which can store ‘custom’ information.
So… is that what you mean, or does dae support collision geometry (poly, sphere, box, etc), LODing, empties and such natively?
dae can store custom information, but it also includes built in support for everything you just listed (I think - not 100% sure about LOD, it defiantly has collision geometry and empties, and allows you to store shaders to apply to the model directly, so you can have some serious fun with materials.). Go read http://www.khronos.org/collada/ if you want more info, though the spec is rather long - wikipedia page might be better for an overview.
Well, those were few things that came in my mind. If dae can do all which egg does natively, then it works for me. There might not be a need to create custom exporters or improve some exporters instead (like with Blender’s), which means more supported modellers. But if many features arent supported by it then there will still be a need for custom exporters which makes switching to a new format a waste of time, in my opinion.
We shouldn’t need any ‘custom’ exporters - my point is we might need to improve the exporters that come with the software, but they would never be custom as any improvements we make can go straight back into the software we just edited. This is a direct consequence of collada being a standard - its maintained by the same people who maintain the OpenGL and OpenAL standards, among others.
And yes, they are ‘just’ automatically loaded shaders, but that is a lot easier for artists, and is supported by various computer programs to help put these things together. (Doubt that is currently supported though, but give it time.)
The key point is to stop thinking in terms of current capabilities and start thinking in terms of new and future capabilities - with collada comes access to a whole host of stuff that is currently difficult to access because propitiatory file formats get in the way. The collada file format is also much easier to extend than the egg file format, plus importers for it are common, unlike for egg.
Yup, something like that - I’m currently waiting to see what happens. I might not have to do anything - the Collada exporter for Blender is now part of the main branch in 2.5, so they should hopefully maintain it - we might just have to submit the odd patch. And I know that complete Collada integration code for Panda already exists, though I don’t know exactly in what state. But basically that leaves everything done - nothing left for me to do:-) (Of course if anything comes up and I have the time I’ll help, but I’ld be just as happy to work on my own projects. Most likely scenario is scripts for Blender that are Panda specific, to prepare data for export.)
Someone has already use the SRB (SyntheticRootBone)?? because, with the documentation and the test file of version 42 (fleur), i’ve not succeed to make my own model walk on the spot.
I’ve a SRB identical as the example. The example functions, not mine. My guy is walking from center to outside of the screen within pview.
—Edit—
If like me, you have a big screen in 16/9, the button motion extraction don’t appear - never !!! it’s under !
The solution is to modify the lines :
self.bMExtraction.update([w-wPad-500, top-1, 110, 20])
and change in
self.bMExtraction.update([w-wPad-500, top-30, 110, 20]) fro example.
And “Motion Extraction” will appear !!! I didn’t understand why my model don’t walk on the spot and the model example (fleur) of 42 do… it’s because model extraction was already on.
Sometimes… Embarassed
I tried my hands on a conversion of the script to the current official beta build of Blender 2.5 (i.e. 2.53) but the API has changed so much that I hardly can finish that any time soon. The COLLADA export feature of Blender 2.53 seems to have improved over the older versions, but I didn’t manage to export a simple static mesh with UV-coords and a texture. As it seems there currently is no decent toolchain available for Blender 2.53 -> Panda3d, yet. I will give the .x-path a try, though I’d rather want to see the solution with COLLADA.
Yeah - I had done some experiments and concluded as much. I might just do the conversion, though its a lot of work. (And as you have probably realised - its more of a rewrite.) Not sure when I could find the time, but otherwise 2.5x is going to be off limits for Panda until the collada stuff gets sorted out, and given Pandas historical development speed that could easily be over a year. The x tool chain lacks a lot of features I’m afraid - not sure how much luck you will have with that. Even if I do the conversion there are still some api changes ongoing with Blender, but they should all be locked down by 2.54, which is due at the end of this month (Though it might get delayed.).
Thanks - I’ve added it to my list. And no, it doesn’t get checked - Chicken development is basically done from these forums.
However, I don’t know if I will get around to fixing it - Panda is moving towards Collada and Chicken is rapidly becoming depreciated, plus that is a very esoteric scenario that could prove tricky to debug - there are plenty of other bugs I would be inclined to fix first. Sorry - you might want to investigate the Collada route, though I would recommend switching to a build bot release or building it yourself if you do so as the current official release doesn’t really work.
For Blender 2.49 the Collada support is rather limited, but for 2.5x it is much, much better. Also, the plan for Panda 1.8.x is to make Collada the primary format. There are problems - the most annoying right now is the lack of normal map support, and I have no idea if you could do level editing with it in the same way you can with Chicken. But Collada is supported by everyone and, despite the inevitable birthing pains, worth the effort of making the transition for the interoperability gains.
Your right in the sense that you do have a normal map, that is applied as a normal map - problem is that Blender is not outputting tangents or binormals, and without these a normal map can not be rendered properly. If you look at your link you will note that the rendering is unchanging and rather strange looking. Hadn’t realised it was letting the normal map through admittedly, but then I had opened a collada file and observed that there were no tangents/binormals, and not bothered to proceed further, as without them its a lost cause.
Panda and Blender work out their tangents/bi-normals differently - one of the axes gets reversed and the edges are different somehow. In other words that doesn’t really work - the results are all wrong and even if you edit the normal map to mirror the correct axis you end up with butt ugly seams. Either we need to add an option to replicate Blenders method or Blender needs to start exporting them, with the later obviously preferable. For now -tbnall will still look better than without, as rendering a normal map with zeroed tangents/bi-normals is really, really ugly, but we do need a solution that is correct.
Another thing I will mention whilst here - I did some level creation tests - Blender exports empties well enough it seems, and I assume that dae2egg will then import them, but properties are not exported, which makes level editing with the Collada pipeline basically impossible. I’m going to submit a bug report and a feature request respectively for these two issues to the Blender bug tracker.
Edit: Can’t find somewhere to make feature requests, so going to leave the property issue for now, but the bug report is here: projects.blender.org/tracker/ind … 9&atid=498 Who wants to place odds on it getting rejected?