Light Style© by Fisana

Jump to content


Photo

Making A Community Maintained "official" Fcollada


  • Please log in to reply
8 replies to this topic

#1 maqifrnswa

maqifrnswa

    Tiro

  • Community Newbie
  • 3 posts

Posted 15 March 2011 - 04:31 PM

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.wildfire....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/f.../tarball/master

thanks, let me know what you think
  • 0

#2 maqifrnswa

maqifrnswa

    Tiro

  • Community Newbie
  • 3 posts

Posted 15 March 2011 - 07:55 PM

Wow, I never gave the github link!

www.github.com/fcolladaCE/fcolladaCE
  • 0

#3 Ykkrosh

Ykkrosh

    Primus Pilus

  • WFG Programming Team
  • 4,921 posts

Posted 18 March 2011 - 10:00 PM

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.)
  • 0
Philip Taylor [aka Ykkrosh]

Wildfire Games Programmer
Contact me: philip@wildfiregames.com

#4 maqifrnswa

maqifrnswa

    Tiro

  • Community Newbie
  • 3 posts

Posted 19 March 2011 - 04:42 PM

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.
  • 0

#5 fabio

fabio

    Centurio

  • WFG Programming Team
  • 652 posts

Posted 30 April 2011 - 07:41 AM

Just wondering... what's the status of this work? If it is complete do you have a plan to upload it to Debian?
  • 0

Graphics problems with 0 A.D. under Ubuntu and free drivers? Check out the Updated and Optimized Graphics Drivers Archive: includes updated drivers with fixes and improvements for games, including 0 A.D..


#6 Jeru

Jeru

    Factotum

  • Web Development Team
  • 4,990 posts

Posted 30 April 2011 - 08:49 AM

Moved to "Development & Technical Discussion".
  • 0

Aviv Sharon [ aka Jeru ]

Wildfire Games 0 A.D. PR & Social Media Contributor
Contact me:
E-mail & Google Talk: aviv dot sharon at gmail dot com
MSN: lc_jerusalem at hotmail dot com
Facebook, Twitter, LinkedIn


#7 privateer

privateer

    Sesquiplicarius

  • WFG Retired
  • 127 posts

Posted 05 May 2011 - 12:30 AM

I've got the download and looked at some of the models.

Is there an official plug-in for Max that you use?
Some models do not display in Deep X at the moment and I haven't taken the time to really look into this.
  • 0
St. Michael, the Archangel - as Prince of the Seraphim. St. Michael is the patron of paratroopers.

#8 Mythos_Ruler

Mythos_Ruler

    Senator

  • WFG Retired
  • 14,967 posts

Posted 05 May 2011 - 04:06 PM

The PMD format is an old format we used to use. Now we use exclusively Collada for export.
  • 0

#9 privateer

privateer

    Sesquiplicarius

  • WFG Retired
  • 127 posts

Posted 05 May 2011 - 07:44 PM

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, 08 May 2011 - 02:13 AM.

  • 0
St. Michael, the Archangel - as Prince of the Seraphim. St. Michael is the patron of paratroopers.