Because no one offered to write a collada importer (right here), and I really like the collada format, I was so stupid to say I’d write one, and now I guess I’m stuck to it for the next days/weeks/months.
Anyways, I’m making it in C++, and just like all the other somethingToEggConverters.
I’m doing this in my spare spare time, so don’t expect this to be done in the next release already
If somebody offers to help coding, that would be greatly appreciated.
EDIT: Oh, sigh. I first started writing it in collada DOM, until I noticed that it came with another 4 thirdparty libraries, libxml2, boost, pcre and tinyxml. FCollada depends on its turn on cg(no prob) but also on DevIL(ahhgr).
Does panda have some builtin xml parser? Otherwise I think I’m going to grab something like libxml or tinyxml, cuz I think the last thing Panda3D needs is another 5 thirdparty libs.
One thing you should consider if choosing a lib…
Look for platform independency. If we have lib in the requirements which is unlikely to be ported to osx/linux/windows in the next time it would be sad.
If it’s impossible to find one, adding the support for it is better then nothing
Panda has no xml parser of its own. Feel free to grab the XML parser of your choice. As Hypnos suggests, portability is one of the key important factors.
Ah, thanks. I’m just going to try out tinyxml (means no lib at all, just a few source files to add), if that wont work out i’ll choose a bigger lib. I’m kinda tired of this thirdparty compile hell on windows.
By the way, does panda have c++ classes which will make my life easier, such as string parsing functions, str2int conversion (and back), etc, etc. Otherwise I would have to implement those myself, which is no problem but I try to avoid duplicate work.
There’s a handful of handy functions in panda/src/putil/string_utils.h. In particular, it has string_to_int(). For going int -> string, we normally use the ostream operator; if we want to do this in-memory, we use ostringstream.
One advantage to using C++ instead of Python for the model converter is that it can then be integrated into Panda’s existing SomethingToEgg framework, which allows the low-level importer to load your dea files directly, e.g. loader.loadModel(‘foo.dea’); and you automatically get the features built into Panda’s common model conversion process, like optional scaling or normal generation.
It also means that non-Python users will have an easier time converting files, since they wouldn’t have to deal with any of the Python issues that might come up otherwise.
Of course, there are other advantages to coding in Python instead of C++. I’m not in a position to dictate one approach or the other. Since pro-rsoft is volunteering to do this gratis, I’m happy that it gets done either way.
Ah. Thanks for all your replies, guys.
drwr, those were exactly the functions I needed, thanks alot.
treeform: I’m going to do it in C++, for the reasons that drwr said, plus, I want to gain more experience in C++ programming.
I just have one question, if I am going to use TinyXML, it only consists of, like 5, files. It’s manual page says I could either just put the source files in some panda dir and let makepanda compile it, or I could also compile it first as library and use it as thirdparty package. What would you do?
If you say just include the stuff in the panda source, in what directory would I put it then? Just pandatool/src/dae/ or so?
If there’s no reason to modify TinyXML, I’d recommend putting it in the thirdparty directory. This keeps the two projects better isolated, and makes it easier to upgrade to a new version of TinyXML if one comes along.
Ah. Thanks.
Would this mean we just put the five tinyxml source files in the thirdparty directory and have makepanda compile it into a lib (it just takes about 22 seconds to compile here), or put a pre-compiled library there?
PS. I’ve been working on the exporter fulltime for a few days and its really getting along well.
Ah, ok. It’s licensed under zlib so I would basically be able to mix it with anything I want, even modify it. I’ll just see what will work best later on.
Little question: Should cameras and lights be imported as well?
We don’t yet have an interface in egg for representing the properties of cameras and lights. You can import their node positions and orientations, though. This is what we do with maya2egg.
Okay, I thought I’d give you guys a status update.
I chose FCollada anyways. I went for tinyxml first but then found myself duplicating a lib like fcollada and buried in a bad C++ hell. FCollada works much better for me.
Here’s what supported:
Integrated in SomethingToEggConverter, useable from ptloader so I can directly pview or load .dae files.
Scene graph with transforms.
Basic geometry, including normals, uvcoords, binormals, tangents, etc.
Materials. (I think even multiple.)
Multitexturing.
Normal maps, gloss maps, and a few more of those.
Basic skeleton hierarchy.
NURBS curves (untested though.)
Multiple UV sets.
Color blend attribs and transparency.
Some small stuff that isn’t worth mentioning.
Here’s what is basically there but untested/doesn’t entirely work yet:
Reading ranger2.dae
Warning: unsupported instance type found
opon reading the generated egg i get
Loading ranger2.egg
Warning in ranger2.egg at line 8, column 30:
<Scalar> texture_type { 2d }
^
Unsupported texture scalar: texture_type
Warning in ranger2.egg at line 15, column 30:
<Scalar> texture_type { 2d }
^
Unsupported texture scalar: texture_type
Warning in ranger2.egg at line 22, column 30:
<Scalar> texture_type { 2d }
And when the entire thing loads the turrets that supposed to be in different parts of the ships are located at 0,0,0 with wrong scale and rotation. I think you are not multiplying the matrices right.
The warning just says that it found something like a camera node or a light node which the egg format doesn’t support yet, so I’m not converting that.
The EggTexture error is related to a bug in panda. Is fixed in cvs and will be fixed in 1.5.4, for now, edit the egg file and replace “texture_type” with “type” everywhere.
Upon a quick look, your .dae file uses a very funny way to describe transforms. It seems to have both and elements, so it could be that my converter is first parsing the matrix, but then overriding it with the translate, which is 0, 0, 0.
Thanks for reporting this bug, I’ll take a look at it. I’ll update the .zip file above when I manage to fix it.
