Jump to content

Making A Community Maintained "official" Fcollada


Recommended Posts

I'm a Debian/Ubuntu developer that saw how the upstream fcollada library is non-existent, and that projects now have several forks of the same library. There also doesn't exist a "standard" shared library distribution for multiple platforms (nor is there one that is portable to many architectures).

Inspired by http://trac.wildfiregames.com/ticket/562, I've put together the the merge of the 3.05B "official" fcollada, OMKFCollada, and Wildfire's FCollada at www.github.com/fcolladaCE/fcolladaCE. I've also added an autotools build system to build shared libraries on all platforms. (03D/Google's fcollada relies on some chrome code and headers, didn't try to tackle that yet)

I've built 0AD using the new github source code (replaced all the FCollada .cpp .c .h and .hpp files with the new source code, and replaced the Makefile for FCollada in 0AD with the Makefile.orig in the github location). I've also built shared libraries, but haven't tested the shared libraries with 0AD.

to build and install the shared libraries (you need libXML2 already installed on your system):

./configure

make

make install

(will install to /usr/local, for more options see ./configure --help or to install somewhere else you can use prefex= or DESTDIR= like any other library)

(if you want stripped libraries, make install-strip would work)

(uninstall is make uninstall)

to use the shared libraries, you can either use pkgconfig/fcollada.pc OR use the compiler flag -lfcollada and make sure you #include <FCollada/{__headerfiles__}> or use -I$(CPATH)/FCollada so the compiler looks in the right spot for the FCollada headers.

I'm still working on the documentation, compiler optimization (which ones to exactly turn off), enabling fcollada's DEBUG flags, and testing. I'm familiar with library packaging and distribution, but not familiar with the usage of fcollada in 0AD so I'd appreciate help. I'd also like to give administrator rights to wildfire/0AD developers so they can commit code whenever needed.

If Wildfire/0AD is interested in using a "community maintained" fcollada, please check this out. If you think this is worthwhile, I can upload to Debian and Ubuntu and can build 32 bit windows binaries, but would appreciate help with 64 bit windows and apple.

Please check it out, it's a work in progress and not officially released yet (the version/SONAME will not change even though the source code and interfaces will). You can either checkout the source code from github or download a tarball of the current repo here:

https://github.com/fcolladaCE/fcolladaCE/tarball/master

thanks, let me know what you think

  • Like 1
Link to comment
Share on other sites

Thanks for starting the work on this! I haven't looked at it in detail yet, but I think it's what we want so we can stop relying on the bundled copy of the library.

A few random points about our usage:

* We don't need 64-bit Windows support. (We use a load of other libraries and it'd be a pain to recompile them all for 64-bit, and 32-bit is perfectly good).

* Windows binaries should be compilable with MSVC (not e.g. MinGW), probably 2005 (for compatibility when people compile the game with that version). Currently we use the .vcproj files, I think; I don't know how it'd work with an autotools-based build.

* On Linux / OS X we need to be able to optionally build from a bundled copy instead of an installed system copy, because it'll be years before fcolladaCE is available on all Linux distros. That should work without needing to be root and installing things in /usr etc. We can point at whatever relative paths are needed.

* Currently we compile separate Debug and Release versions of FCollada (to different filenames), and use the appropriate one when the game is compiled in Debug or Release mode. I'm unsure whether that's necessary - we don't really need it for debugging, but I don't know if the library has problems when it's compiled in a different mode than the game. (Maybe on Windows, where debug vs non-debug CRT DLLs cause conflicts?)

* For testing FCollada in the game, running binaries/system/test (or test_dbg) after building the game will test it a little. To use it in the actual game, first delete ~/.cache/0ad/ then launch the game. (We only convert a model once using FCollada, and then cache the result, because conversion is slow.)

Link to comment
Share on other sites

Thanks for the comments! The goal is to primarily support 0AD, so I'll do whatever is needed for the library to work with this project. If anyone sees this that is interested in helping, please contact me or just grab the code and start hacking.

These are great guidelines for now, I'll comment briefly:

* We don't need 64-bit Windows support. (We use a load of other libraries and it'd be a pain to recompile them all for 64-bit, and 32-bit is perfectly good).

Sure thing.

* Windows binaries should be compilable with MSVC (not e.g. MinGW), probably 2005 (for compatibility when people compile the game with that version). Currently we use the .vcproj files, I think; I don't know how it'd work with an autotools-based build.

autotools and MSVC don't mix, so I'll use the vcproj your currently using as a starting point - will probably use those for binary building.

* On Linux / OS X we need to be able to optionally build from a bundled copy instead of an installed system copy, because it'll be years before fcolladaCE is available on all Linux distros. That should work without needing to be root and installing things in /usr etc. We can point at whatever relative paths are needed.

You're right about using a bundled copy at first. (Just for information regarding timing: It should take about a month after fcolladaCE is released to get into Debian since I have upload rights and it will appear in the next release of Ubuntu after I upload to Debian). Right now you can actually just drop the code (and updated makefile) from github into 0AD and it will build during the update-workspaces.sh, so it looks like this requirement can be met. Still needs more testing before shipping with 0AD, but it's good to know that it can work.

* Currently we compile separate Debug and Release versions of FCollada (to different filenames), and use the appropriate one when the game is compiled in Debug or Release mode. I'm unsure whether that's necessary - we don't really need it for debugging, but I don't know if the library has problems when it's compiled in a different mode than the game. (Maybe on Windows, where debug vs non-debug CRT DLLs cause conflicts?)

I'm still studying the code to see the differences between the two. For now it looks like the unixes can get by with just a release version, but you may be right about Windows and mixing debug/non-debug dlls.

* For testing FCollada in the game, running binaries/system/test (or test_dbg) after building the game will test it a little. To use it in the actual game, first delete ~/.cache/0ad/ then launch the game. (We only convert a model once using FCollada, and then cache the result, because conversion is slow.)

Thanks for the pointers, that's what I was looking for.

I'll post updates and welcome any help if anyone has experience with or interest in this (showard@debian.org), or just grab the code and hack away.

Link to comment
Share on other sites

  • 1 month later...

It's a few of the .dae files that will not show in Deep X

I can see the verts listed but nothing in the view window.

I have several of the Collada plug-ins for Max.

3.04C and 3.05C

Which should I use?

I found the problem with being unable to view some .dae files in Deep X

Seems Deep X does not like the files created by the FBX Exporter in Max?

It maybe that my version is to old.

Edited by privateer
Link to comment
Share on other sites

  • 7 years later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...