[crossfire] Getting more artists

[Robin Redeker]

On Thu, Apr 12, 2007 at 07:34:38PM -0700, mwedel at sonic.net wrote:
>  IIRC, there are currently a few 3d models in place, but these are used to
> generate static images.  That works, but can be trickier to deal with.

Just FYI: I've lately checked in all the 3D models we use to render
our (now 64x64) tileset: http://cvs.schmorp.de/cf.schmorp.de/arch3d/
All of them come with a yafray xml file (and a .cfg file for the cfxmlrender
script that comes with the Crossfire perl module. the cfg file says what
the output filename should be, where in the arch tree it belongs
and the size and direction from which to render the face).
And most of them come with a blender scene file or at least a wings
model file (I'm working on exporting all of them to blender files,
as I prefer blender these days for it's animation capabilites).

With regard to the perspective: cfxmlrender adjusts the model in the
file on the fly before setting up an orthogonal camera.
Basically it goes like this:

   for 4 units height go one unit to the right and two units up.
   It basically applies this transformation matrix to the yafray scene:

      1  0  0  0.25 0
      0  1  0  0.5  0
      0  0  1  0    0
      0  0  0  0    1

> > * Animation of graphics and howto animate them and name the necessary
> > files for proper animation

We currently animate the models in the modeller and write out a yafray
file for each frame. Integrating a bone-animation framework alogn with
real 3d rendering in the client would be very nice, but thats really
really a lot of work and unneccessary at the moment.

> > * The 32x32 base size vs why not something larger?
> 
>  I know some developers have stated that current image sizes are too
> small.  We could certainly do something larger - doing 64x64 for base
> size is simple enough, and a quick resize of all images into a 'large'
> imageset could easily enough be done.  The problem here is really that
> there is now 2 image sets to maintain.  OTOH, I'd think that in most
> case, if things were drawn for the larger size and scaled down, it might
> work OK.

We've recently changed to 64x64 tiles (see also the latest screenshots
on http://cf.schmorp.de/screenshots.shtml ).
We have a script that processes our arch/ tree before generating the
face and archetype files from it. It looks whether there is a 64x64
version of the tile and if there is no 32x32 version it scales it down.
Scaling down rendered tiles looks nicely. And if there is only a 32x32
tile version, it is scaled up to 64x64 with a derivation of the hq2x
algorithm (see also http://www.hiend3d.com/hq2x.html and for the
hq2x implementation here: http://cvs.schmorp.de/cf.schmorp.de/server/utils/ )

The technical problems that come with 64x64 were for us for example the
10kb facesize limit. First we tried to send gcfclient bigfaces for
everything, but that didn't work well due some weird restrictions in the
client. We were also bitten by other limitations, eg. the fixed upper
limit of the number of faces in gcfclient.

In the end we now provide 32x32 tiles for gcfclient and the 64x64 tiles
to cfplus. Schmorp also extended the protocol to be able to send images
larger than 10kb (afaik it does transfers them in multiple pieces). (I
currently don't know more details on the implementation, as it was done
by schmorp).

>  64x64 may be too large a size however, and 48x48 may be a better middle
> ground, but more discussion would be needed on that.

Well, 64x64 offers a lot more pixels for details, which really boost the
immersiveness of the game IMO. Having so large tiles also makes it
possible to make some things smaller than others (eg. making the booze
not as big as a player character).

Greetings,
   Robin