The qc source path is specified via the dirpath property in the QF Entity
Classes panel of the scene data. The scanned entity classes are stored in a
plist in a blender text file for persistent storage (so the directory
doesn't need to be scanned every time). Also, so the data doesn't have to
be parsed every time, the data is stored in a normal python class hanging
off the properties class (evil hack?).
Slightly cleaner EntityClass building, and now the directory scanner is
part of the EntityClassDict class, which also supports reading/writing
plists (for persistent storage in blender).
They are written as normal string items, so anything using the plist later
on will need to know the context, but at least now there's no need to first
convert int or float data to strings before writing a plist.
More or less.
This is a bit of an experiment (which seems to work nicely) in that qfcc
and pak are build natively in one build tree, then the full system is
cross-built in another tree using the natively build qfcc and pak. Both
trees are created by cross-configure.sh as sub-directories of the current
directory. However, cross-configure.sh still assumes it is being run in a
subdirectory of the main quakeforge directory.
cross-make.sh checks if the native tree is in the current directory and if
so, builds it, otherwise it just runs make for the cross-build tree (this
allows for running cross-make in a sub-directory for things like sorting
out build issues).
CC_FOR_BUILD is the recommended name these days (HOST_CC was from an old
gcc version, and is confusing anyway). Also, CC_FOR_BUILD should be set by
configure.
Unfortunately, just because the header is there doesn't mean anything will
actually work :(. Also, the check is based on the host vendor/os for now.
Yes, it's rather lame but it will do for now.
With this, QF will build on an almost fresh ps3toolchain install. Only two
"fixes" are needed:
o In $PS3DEV/ppu/powerpc64-ps3-elf: ln -s ../include sys-include
o libsamplerate cross-built and installed.
One common use for a mesh having multiple UV maps is when combining several
mesh objects into one: the base UV map is the result of joining the meshes
(and will be a right mess of overlapping UV islands), but an additional UV
map is then setup as a copy of the first but with the islands re-packed so
nothing overlaps. The export script now searches for the active UV map and
uses that for both UV coordinates and the skin texture (when none is
specified).
If there's no export script, or the export script has no frame information,
animation data will be collected by running through blender frames 1 to the
current frame (inclusive). Each frame will be exported as a single frame
rather than as members of a frame group.
I'd forgotten I hadn't implemented exporting vertex normals. While I've
modified things for making better use of blender's tools and avoiding the
unnecessary use of objects, the code is taken from the ajmdl blender 2.4
export script.
