On Tue, Apr 5, 2011 at 6:58 AM, Paul Wise <[email protected]> wrote: > On Mon, Apr 4, 2011 at 10:55 PM, Philip Taylor <[email protected]> wrote: > >> It can be created and parsed and rendered (but not modified) by the >> game engine. It used to be exported by a custom 3ds Max plugin but we >> no longer use that (we export to Collada since ~4 years ago). It's not >> designed to be a modifiable format, but it's not theoretically >> impossible to modify - there's a Python script at >> http://trac.wildfiregames.com/ticket/461 to convert .pmd back into >> editable Collada format so it can be imported into e.g. Blender, >> though that currently only works for static meshes and not >> skeletally-animated ones. > > I would suggest the the pmd files be removed from the source package > and replaced with the _source code_ (the form for modifying) for the > models and that the build scripts should convert them to the form used > by the engine.
For new models and animations, that's effectively what we do (the engine loads the Collada and converts to .pmd at run-time). For old ones, we don't have the modifiable form (except as 3ds Max files scattered around various people's disks and FTP sites - the art process wasn't well organised). For old static meshes, we could use that Python script to convert them into modifiable Collada files and replace the .pmd files with those, and I'd be happy to do that. For old animated meshes, we'd need to extend that script to convert them successfully into Collada, which might be significant work (or might be impossible - I'm not quite sure). It'd be nice to do that, but it probably won't happen any time soon since there's higher-priority problems in this area. For binaries/data/tests/collada/sphere.pmd (the file that was originally mentioned), its purpose is to test the Collada-to-PMD conversion code - we can't replace it with a Collada file and then convert it automatically because that would defeat the point of the test. >> DejaVuSans.ttf, DejaVuSansMono.ttf, texgyrepagella-regular.otf, >> texgyrepagella-bold.otf are unmodified originals. > > Best remove these and package the ones that aren't yet in Debian separately. We don't use those files at build-time or at run-time (they're only used at development-time), so there would be no point packaging them for users. I can exclude those files from the distribution script since that seems the easiest solution. >> ConvertedPagella-Regular.ttf, ConvertedPagella-Bold.ttf are >> non-original and derived from texgyrepagella-*. > > What modifications were done for this? Would it be possible to merge > those upstream? No modifications except what FontForge does automatically when saving, which happens to make FreeType render them to bitmaps in a way that looks prettier. But I can exclude those files so it won't matter here anyway. >> Changed the tarball generation script in >> http://trac.wildfiregames.com/changeset/9160 > > Why are you manually creating the tarball, doesn't your build system > have the equivalent of `make distcheck` from automake? It doesn't. (The build system is certainly far from ideal, but it sort of works, and I don't have much experience with anything else, so I haven't cared enough to learn and implement any replacement myself, and nobody else has tried replacing it either. We'd probably need a script anyway to generate the Windows installer via Wine and it seems easy enough to do the tarballs the same way.) -- Philip Taylor [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
