Comments/Ratings for a Single Item

@HG: maybe a same letter could support 2 pieces that share a lot in common and that are unlikely used in the same variant?

The letters are used to request a piece for inclusion in a variant that Jocly doesn't know yet, when you are implementing that variant. Jocly is not psychic, so if Lion and Leopard would both be L, and you ask it to put an L on the board, it would not know what to give you. Even if it could read your mind to know you were trying to implement Metamachy, it would still not know which of the two to include, as it wouldn't know the rules of Metamachy (or there would be no need to implement it).

Current assignment is A=BN, B=B, C=C, D=RF, E=FA, G=[F?R], H=BW, K=K, L=KNAD, M=RN, O=WAD, P=Pawn, Q=Q, R=R, S=fW, T=QN, U=[W?B], V=mBcpB, W=FC, X=mRcpR, Z=Z.

Last point, have you seen my message on the png icon for the Badger?

Ah no, I missed that. Apparently the default color blue for Alfaerie is not set correctly in fen2.php. I now rendered it again explicitly requesting the correct color, and uploaded that. Getting to see it might be hard for you, though: the old one would have to be flushed both from your browser cache and from the CloudFlare cache. The latter you can force by suffixing with ?nocache=true (in an ID as part of the graphicsType).

50x50 and 35x35 are the standard sizes of the Alfaerie sets on CVP, so I rendered it at those sizes to include it in those set. And 249,249,249 is the standard filling for Alfaerie white pieces. I don't know why you would want to use a deviating color.

I hadn't seen this message before, I was wondering if the "piece-creator tool" was a home-made command-line tool?

It sounds magical to me, could it be used by other people?

Yes, it is, and yes, it could be used if you can compile and run C programs. I might push it to the Jocly repository, but it is still very much in a state where I regularly have to change it. And it is not very user-friendly. I had started to write a tutorial on its use:

Basics

A Jocly 3d image for piece xxx consists of three files: xxx.js,
xxx-diffusemap.jpg and xxx-normalmap.jpg. The .js file contains
the 'mesh': lists of point coordinates that define the 3d shape
('vertices'), lists of coordinates of points in the map files
to cut out part of these and paint it on the surface of the 3d
object ('uvs'), and a list of vertex and uv numbers to indicate
how these points are connected to form triangles and quadrangles
('faces').
  The diffusemap is an image file in true colors, which will be
used to paint the faces of the 3d object as specified by the
uvs. Jocly might manipulate the colors, e.g. to create black
versions of the piece, and account for light/shadow effects.
  The normalmap is an image that controls the direction of
reflections relative to the surface, encoded in false colors.
This is used to create the illusion of height variations on
faces that are really flat. The neutral color is light blue,
for indicating a flat surface. But Jocly manipulates this
such that adjacent faces that do not make an acute angle
appear curved such that they seemlessly fit together.
This way the Pawns head, which in vertical cross section is
just a hexagon, reflects light as if it is a perfect sphere.

The Tube tool creates 3d objects as a sequence of 'rings',
with equal number of points along their circumference.
Corresponding points of adjacent rings are connected to
form quadrangular faces, to make a (cylindrical or conical)
tube 'section'. The entire series of rings thus defines a
tube of variable diameter.
  The lower and left 81% of the map files (which always are
512x512 images) represent this tube surface, and wraps
around such that left and right edges connect. A red/green
scale to the right of this area in the diffusemap indicates
which part of the map corresponds to which tube section.
This can be useful when you want to edit the image (e.g.
with Gimp or MS Paint) for painting details on it.

One of the sections can be a cone, where a single point
(the top) connects to all points of the preceding ring,
to form triangular faces. A disk in the upper right of the
maps is used to color this cone. This facility is mainly
offered in case you want to paint something on a nearly
flat top, which would be highly distorted if you would
have described it as a tube section with one of the ends
invisibly narrow.

Design cycle

The Tube tool takes its input from a file specified in
the command line, e.g.

tube piece.dat

Running this would create the .js file, and both maps
in .bmp (Windows bitmap) format. The latter then have
to be converted to .jpg by commands like

convert piece-normalmap.bmp piece-normalmap.jpg

on Linux. (On Windows I would know no other way to do it
than loading the .bmp in MS Paint, and then saving again
in .jpg format.)

We can then copy the .js and .jpg files to the directory
of a piece in the Jocly library, e.g. to

jocly/dist/browser/games/chessbase/res/staunton/rook/

calling them rook.js etc., overwriting the original rook.
(It would be easiest to put these commands for conversion
and copying into a shell script, as you will run the
combination of commands many times.) This replaces the 3d
rook image by your piece. By letting Jocly then run normal
Chess you would then see that piece appear on the corner
squares, where you can examine it in close up to see how
you are doing.

To better judge which ring needs adjustment, you can run
the tube command with an extra parameter 't':

tube piece.dat t

This will cause the sections to be alternately colored
bright green and red. Normally they would be painted in
a nice wood-grain pattern. It is recommended to rn with
this extra t until you are satisfied with the design, and
then drop it to get normal colors. This only affects the
diffusemap that is produced.

The input format

The input file starts with an integer to indicate the number
of points along the circumference. Usually 16 is sufficient.
(More points gives better quality, but makes Jocly slower.)
Then follows a list of height-radius pairs describing the
rings, as whitespace-separated real numbers. The total
height of Jocly pieces is typically 3.0 - 3.5, while a
radius 1.0 extends nearly to the edge of the square.
  It is usually good practice to put each  ring on a
separate line, so you can easily see which numbers are
heights, and which radii.

Simple case: cylinder symmetry

To create a cylindrically symmetric piece you only have
to specify the height and radius of all the rings, which
by default are each in a horizontal plane. The list must
be followed by a specification of the output filenames,
or it would be printed on the terminal. E.g.:

16
0.000 0.700
0.050 0.700
0.500 0.500
0.860 0.860
1.360 1.000
1.860 0.860
2.220 0.500
2.360 0
out: sphere

This would describe a (rather course) sphere on a pedestal.
The sphere in this case encompasses the top 5 sections;
6 sections is about the minimum for a full sphere, but the
lowest slice is replaced by the pedestal here.
  Running Tube on this input will produce files sphere.js,
sphere-diffusemap.bmp and spere-normalmap.bmp, which you
then convert and copy to Jocly. Congratulations! You now
created your first piece.

Surface details

After the specification of the output file you can still
specify some details to be drawn on the maps: ridges and
eyes. These don't affect the mesh file, but can create
the illusion of extra structure.
  A 'ridge' is drawn all around the object, parallel to
the rings. There are two kind of ridges: V-shaped and U-
shaped. To get one we have to write a line

ridge: height width depth

where the latter three are real numbers. The height is
tricky as it does not correspond directly to the height
at which you defined the rings, but is measured along
the surface. This to be able to distinguish location
on tube sections that are (nearly) horizontal, or even
hanging down, (like the brim of a hat) so that the same
height is passed multiple times.
  To facilitate this, running tube will print a list of
the rings, with the 'height along the surface' in the
last column. You can use that as an aid to position the
ridges.
  The depth is positive for ridges lying on the surface,
and negative for grooves. With positive width the ridge
is V-shaped, with negative width it will be U-shaped.
  There is a trick to optically soften acute angles
between sections (which Jocly would not do automatically):
You can put a V-shaped groove exactly at the connection
to 'neuralize' the angle (like you shaved if off), and
then an equally wide U-shaped ridge on top of that.

Eyes are round, darkened pits. They are specified
through a line

eye: height angle size

where 'height' is again the height measured along the
surface. The 'angle' parameter specifies the horizontal
location on the surface, as the angle with the forward
direction (in degrees). So 60 would mean looking a bit
forward but mostly sideways. Eyes are always created
in symetrically-positioned pairs.
  The eyes are drawn as circles on the maps, but because
the maps can be highly distorted when transfered to the
surface of the tube (depending on the local diameter
and total height), they might show up elongated.

It is possible to specify a different color for a tube
section. To this end you must write behind the spec
of the ring that finishes it

paint: color

or

shade: color

where 'color' is a hexadecimal color number (e.g. ff000
for red). The difference is that 'paint' sets the color
to the given one, while 'shade' will use the latter as
an offset to add to the color it would normally generate.
(Such that 101010 would make it a bit lighter, and
f0f0f0 a bit darker.) This would preserve the wood-
grain pattern in the section.
  Note that it is possible to adjust the color of the
entire object by specifying such a color offset on
the command line as the 2nd argument.

With these techniques you should already be able to
produce pieces like they could be made out of turned
wood with a laith. The lower part of pieces usually
look very much alike, and once you have a satisfacory
representation of that you can use it for creating
multiple pieces by just putting different heads and
hats on it.
  Note that the .js file contains an over-all scaling
factor, which by default is set to 1. By editing the
file afterwards you could change that to shrink or
expand the piece. So if your design turns out too
tall after making all necessary adjustments to get the
right shape, there is no need to change all the input
numbers; you just change the scale. (Contrary to
intuition larger scale makes the piece smaller.)

Creating (modest) asymmetry

For pieces that are mostly cylindrically symmetric, but
have parts that stick out in one horizontal direction
at some heights (such as the vizor of the Champion or
the cap of the generals), we can shift some of the rings
off axis by following the height-radius pair for that
ring by a colon and two more real numbers. The first of
these indicates the elliptic distortion of the ring: the
width is multiplied by it. This causes indentation or
protrusion in two diametrically opposit directions,
either sideways of forward-backward. When the number is
1 it has no effect, and the ring remains circular.
Otherwise cylinder symmetry is broken, but the piece
still has forward-backward mirror symmetry.

The second number is the forward shift, in the same
units as the radius. This causes a forward-backward
asymmetry. To make the piece bulge out on one side
you would specify a larger ring than the adjacent ones,
but specify a shift equal to the increase in radius,
so that one side stays in line with the other rings,
and the opposit side bulges out twice as much.
To prevent the larger radius makes the piece bulge
out sideways too much, you can compensate the radius
increase by specifying an ellipticity < 1.

Bending

So far all rings would be perfectly horizontal. It
is possible to deviate from that by following the
height-radius pair with a semicolon and two more
real numbers. This can be done even after you specified
an ellipticity & shift with the aid of a colon (but
not before that!).
  The first number indicates the (forward) tilt of the
ring plane, as an angle in degrees. So 90 would make
the ring stand up vertically, where what formerly was
the front of the piece now points down. The center
of the ring would stay on the vertical axis, so you
would usually combine this with a forward shift to
create a bended tube. To get a smooth bend you would
of course need many intermediate angles, increasing
the tilt in steps of maximally 15 degrees.
  The second number is the 'up-curve' distortion.
It bends the plane of the ring into a horizontal
cylinder with a forward-pointing axis, like the ring
is 'smiling'. This is done before applying any tilt.
The number represents the radius of this cylinder.
So to bend the ring into half a circle you would have
to make that about 65% of the ring radius. This
feature is not often needed; it was added for making
the wings of the Phoenix, where a very narrow
sideway ellipse is bent upwards.

Giving an occasional ring a small tilt has an effect
that is barely distinguishable from making it elliptic.
So the tilt is mainly used to bend the tube that
defines the piece in small steps to a large angle
with the vertical, perhaps even inverting direction
and grow downward again (such as in the Stork).
  Because tilt and shift have to be combined to make
the rings connect in a natural way, it is usually
a pain to get this right. Especially on very tight
curves of the tube. As an aid Tube not only prints
the height-radius pairs, but also the coordinates
of the forward-most point in each ring. This can
tell you how much you have to adjust it horizontally
and vertically to make the front of the piece curve
in a smooth way.
  This is not so helpful when you bend the tube
backwards, so that the backward-most points get
critically close together. But in that case you can
first design the mirrored version that does bend
forwards, and then flip the sign of all horizontal
shifts and tilt angles.

The 'lift' directive

Sometimes you get something that looks like you want
it, except that some section is too short. E.g. a
piece with a complex hat, and you think the body should
be just a bit taller. Of course you can increase the
height coordinates in all rings above the top of the
body by an equal amount to shift the head up, and
repeat that until you get it right. But by putting a line

lift: h,f

with h and (optionally) f real numbers between the ring
specifications you will shift all rings specified after
it up by h, and forward by f. That makes positioning the
upper part of a design much easier.
  Lift directives are cumulative: the adjustment of
height and forward shift of the specified rings always
equals the sum of all preceding lift directives.

Pseudo-rings

Negative radii would make no sense, and the Tube program
uses these as a kludge for changing some of its settings
during the generation of the tube. In this case the
parameter that normally indicates the height is interpreted
for a different purpose. The actual (negative) value of the
radius indicates which purpose.
  Any negative radius terminates the tube we have generated
so far, and makes the ring that follows start a new,
disconnected tube. This way we can create multiple tubes.
  When the radius = -1, the first parameter indicates the
new number of points along the circumference to be used for
all rings of the next tube.

  When radius = -2, the tube that was just completed is
duplicated. The first parameter in that case indicates how
much the two instances will be shifted to the left and
right. This is useful for making ears or horns.
  When radius = -3, the latest tube is also duplicated.
But in this case the instances are separated by applying
a shear transformation, which shift each point by an amount
that grows as we get further from the left-right plane: the
forward-backward coordinate of a point is multiplied by the
first parameter, and the result is added to or subtracted
from the left-right coordinate. This can be used to 'unfold'
wing structures.

  When radius = -4, the first parameter represents an angle
(in degrees). The whole structure that follows is then
rotated by that angle around an axis that runs left-to-right,
at the height of the last ring in the previous tube. This
is the angular equivalent of the lift command, but unlike
the latter can only occur once.

 

@HG: I reply to your last point: "50x50 and 35x35 are the standard sizes of the Alfaerie sets on CVP, so I rendered it at those sizes to include it in those set. And 249,249,249 is the standard filling for Alfaerie white pieces. I don't know why you would want to use a deviating color."

I don't want anything deviating! I want consistency on the contrary.

When I download https://www.chessvariants.com/graphics.dir/alfaeriePNG/wking.png or wrook.png, etc., I get a 48x48 image and the white is 255.

When I download wbadger.png in the same directory (and also wowl.png), I get a 50x50 image and the white is 249.

I have the feeling that there no consistency there. Or am I missing a point?

Interesting!

I'll try to compile it and use it out of curiosity when the time comes.

Current assignment is A=BN, B=B, C=C, D=RF, E=FA, G=[F?R], H=BW, K=K, L=KNAD, M=RN, O=WAD, P=Pawn, Q=Q, R=R, S=fW, T=QN, U=[W?B], V=mBcpB, W=FC, X=mRcpR, Z=Z.

You omitted N, which I assume is the Knight. That leaves F, I, J, and Y. Can pieces be assigned to longer strings than single letters?

Can pieces be assigned to longer strings than single letters?

No, because the letters are used in a FEN. Letter + punctuation would be an option. But probably not worth the trouble, as I think we already cover almost all frequently used pieces, mostly with not very non-intuitive abbreviation.

When I download https://www.chessvariants.com/graphics.dir/alfaeriePNG/wking.png or wrook.png, etc., I get a 48x48 image and the white is 255.

Indeed, strange. And the GIF image of King is 49x49. All I can say is that every image I made (and I made a very large number of them) in PNG or PNG35 were rendered with the http://winboard.nl/my-cgi/fen2.cgi piece server, at a size 50x50, using its default white color, which is 249,249,249. As I recall it most of the old GIF files were also 50x50. (I am pretty sure of that, because I could not use them in WinBoard, which required 49x49 as the closest size.) The Wazir on the alfaerie GIF page is 50x50.

So I guess there is no consistency. It is the King and the Rook that have the wrong size and color, though. I should remake those one of these days.

"It is the King and the Rook that have the wrong size and color". Well, I'm not going to test all of them, but also Pawn, Knight, Queen, Camel, Fool, Wazir, Tiger, Rhino, Frog, Ram I stop, all in 255/255/255. I bet they are the vast majority.

In term of size, all of them are 48x48, incl the Wazir.

It seems that only those you added recently are different.

To understand, why 249/249/249? (F9F9F9). Why not FFFFFF? I suspect there is a technical reason, maybe to contrast with a FFFFFF background? I'm curious.

No, because the letters are used in a FEN.

Hah;) are non-ASCII suitable? I say as guy who overwrites pieces with them)

In term of size, all of them are 48x48, incl the Wazir.

Not on this page, they aren't. Wazir, Giraffe, Lion, Camel... All are 50x50. The orthodox pieces are 49x49, though.

I don't know where the F9F9F9 comes from. But all SVG Alfaerie piece images must use that as white fill color, or the rendering engine would not replace it by the color you requested. (And in particulare, not with blue if yioou request a black piece.)

The rendering engine's default has always been set to leave the white color as it was. And it has always been our way to convert the SVG to the PNG images in alfaeriePNG and alfaeriePNG35. But perhaps the one who has been making those other images (I suspect Greg Strong) has used an explicit w=...... argument to request pure white. I never did that, as it didn't make sense to me that the PNG images should not use the same white as thenatural color of the SVG images.

Hah;) are non-ASCII suitable?

Not really. Most people would not be able to type those in a simple way. Which sort of defeats the only purpose of the cbPiecesFromFEN function: to simplify things. People would even have difficulty remembering what non-ascii they would have to use for a given piece. Even with the ASCII alphabet that danger exists, which is why I try to make the assignment as straightforward as possible.

I am now in a state where I have almost no uncommitted patches (except those that I intentionally don't want to commit, such as the reversion of the gulp update, and 'games' I added for testing purposes to index.js). I also have applied the addition of the Terror, and pushed everything to the trial branch of my repository.

I even pushed the command-line tool for 3d piece creation, in a new directory jocly/tube.

I've published the changes on github
As I've modified the hawk sprites in the meantime, I think you'll need to get the latest version of
wikipedia-fairy-sprites.png

I've seen jocly/tube, so I'll have to study that in depth.

How do you see the next step? Is it possible to pull down the refactoring of the documentation (html of rules, images ...) to get index.js files closer? or Shall we do it on a brand new branch?

@HG, Fergus: I believe that the folder which counts is the one I'm pointing. Because it concerns the .png. The page you are referring just displays .gif. The .png are those called in the Game Courrier presets.

Maybe something modifying automatically all Alfaerie png's into 50x50 and setting white to F9F9F9 for all will improve the quality of our graphics. To be seen with Fergus?

@Jean-Louis: the gif files are the original alfaerie; the png are intended to be their anti-aliased replacements. Color or size change was never intended.

I believe the original white color (i.e. in the gif) is ffffff. It doesn't help much that the gif already have inhomogeneous size (49x49 or 50x50), but it was alway my intention to use 50x50 (and a new series of 35x35).

So I think we should re-render all SVG with the aid of fen2.php with arguments s=50&w=ffffff. (Actually I should set ffffff as fen2.php's standard white color for alfaerie.) I think I can do that today by turning the directiry listing of alfaerieSVG into a shell script that does the rendering.

As I've modified the hawk sprites in the meantime, I think you'll need to get the latest version of
wikipedia-fairy-sprites.png

The (ever recurring) problem is that yesterday night I still made some more 2d sprites for the 3d pieces I had already created with Tube, so that I could add and commit those. As a result we have again two incompatible 'latest versions' of the fairy-sprites file. Git cannot merge binary files, so I will have to create the merged image by hand, and then commit the rusult as a new commit, different from the original one. As I also had to do for adding the Terror. I will download the version from GitHub and take the new Hawk image out of that to copy it over the old one in my latest version.

This is really a very annoying characteristic of Jocly. It would have been much better is all the 2d sprites were just separate image files.

I think it should be possible to pull and merge the documentation reorganization into the same branch, as they should consider only independent changes. I will try it later today. If not we should copy it to a different branch, and then rebase one on top of the other; I am sure that will work.

Many of the games I made would need documentation too; since I was hacking those into the library, and control.html would not display rules and such anyway, I never bothered with that. The new pieces would need images that can be included in rule descriptions too.

I've started making graph images to help with the doc. I can make more images if it's useful.

The documentation is an important part of the project, because it's likely that in 2 or 3 months' time, all this will be available in the mobile applications for a wide audience who aren't necessarily comfortable with English and who want to get straight to the point. For example, for elven, it's important to explain the rules for the lion at the beginning of the page.

Note that my branch trial is rebased if you want to try to pull it.

We should make sure  that the external links in the documentation go to pages that the authors will be able to maintain over time, because updating mobile terminals will depend on the users.

I'd therefore advise anyone who has variants in jocly to make sure that the rules/description/credits pages are suitable for them with joclyboard.

I tried to use fr-terror in Makromachy and Minjiku Shogi, but it doesn't show up, and the JavaScript console of the browser reports an error (in a piece of code that looks totally unfamiliar to me, so presumably in the rendering library). So there seems to be something wrong in the .js file. (It seems to contain a lot of cruft, besides the lists of coordinates.)

Some other thoughts:

Visuals: When I look at the 2d visual you made for Mirza, the Griffon symbol strikes me as way too big compared to the symbols for the orthodox pieces. In fact the latter strike me as way too small for the square size that is used, and located too high in the square (which might be a consequence of that). To a lesser extent that also applies to the Prince symbol. (I suppose it doesn't stick out that much because it depicts a naturally smaller object.)

The black Cannon2 seems to have a black line above it in your visual that doesn't belong there. In the 2D representation of Makromachy I don't see that, though. The squares are smaller there, and this emphasizes that the white Cannon2 is really drawn too low.

I guess we should make an effort to harmonize the fairy-sprites.

PiecesFromFEN: For variants with complex promotion rules it is still a pain to extract the piece-type numbers for use in the promote routine. Would it make sense to make these numbers more predictable for the programmer? We could adopt the convention that P and S come first (in that order), and take the numbers 0-1 (or 0-3 if both are present, which would be extremely rare). After that all non-King pieces in alphabetical order of their ID in the FEN, and King last. This would be just a matter of re-ordering the tests for the presence of the pieces in cbPiecesFromFEN. In Grand Chess they would then know that A=2, B=3, M=4, N=5, Q=6 and R=7.

The assumed piece values are what they should be for an 8x8 board. For larger variants people might want different values (upgrading sliders as compared to leapers), and it currently would be a pain to redefine all values through statements like "p.pieceTypes[name2nr['rook]].value=...". If people want to redefine values, it is likely they want to redefine it for all the pieces. So perhaps there should be a function for that, which takes an object with the new values as argument. Like

p.setValues({P:0.8, N:2.5, B:3.75, R:6, Q:11});

Of course that might be futile, as people implementing the variant might have no idea what the piece values are, and actually make things worse than just using the default 8x8 values. So perhaps the default values should take account of the board size, to reduce the need for hand tuning.

Tube: The pieces we can generate now are acceptable, but I still think their diffusemaps should be better. They seem a bit bland to me. E.g. if I look at Saint or Caliph, their down-pointing surfaces are not nearly as dark as the head of the King & Queen. The natural shading algorithm gets some assistance there from a darkness gradient in the diffusemap for the head sections. I think we should have that too. It might be hard to do it automatically, but we could provide a command to order it in the tube input file. Like allowing mention of a second color in paint/shade, which would then then be interpolated to start at the first and end at the second as we traverse through the ring. And then redo all pieces we made so far, to replace their diffusemaps.

I made some adjustments to the fairy-sprites file, to better align all the pieces there, and improved some of the images I added. Some images are still unacceptably poor, though, and need reworking (too thin lines (axe, black admiral, mamoth and diamond), white outline (bull, ship, squirrel), too large (squirrel, griffon)). I am not sure whether that can be done on the existing 100x100 raster images, though. Certainly not with GIMP. So perhaps they will first have to be remade as SVG.

fr-terror : you are right, I had a conflict on that file, I thought I resolved it correctly, but I didn‘t. I pushed a new version.

Your evolutions for PiecesFromFEN are interesting, I will certainly use the setValues functions if possible.

I managed to compile Tube but I am not yet able to make the most out of it. Of course we can replace the diffuse maps if we have improved ones.

Concerning the visuals, I made it from screen capture from joclyboard, that may be why the chessboard square render badly.

Your idea to use SVG would be a great improvement for Jocly but I'm not sure how feasible it is. I assume you already have an idea of how to do it.

I confirm that the order of PiecesFromFEN work as expected. I have tested and modified grand chess but not commited it yet.

I also confirm that the default in wild-mirza-600x600-2d.jpg comes from windows resizing in joclyboard. The visual is modified. but of course the problem remains.

I saw that you'd managed to pull the refactoring of the doc to your branch. That's a good news. Let me know if there's any point in my continuing to refactor the docs of chessbase/decimal and chessbase/shogi directories, or if there are more disadvantages than advantages because of the risk of conflicts.

I saw that you'd managed to pull the refactoring of the doc to your branch. That's a good news. Let me know if there's any point in my continuing to refactor the docs of chessbase/decimal and chessbase/shogi directories, or if there are more disadvantages than advantages because of the risk of conflicts.

I had no merge conflicts with the docs; just with the fairy-set-view and sprites. So it is fine if you go ahead, as long as I will stay away from it.

@François: I have now committed rule descriptions for Minjiku Shogi and Makromachy. They refer to many images for the participating pieces that do not exist yet, though. The images that do exists are all in res/rules/fairy. I suppose that we would want a complete set of images for the entire fairy-set-view in that directory, with their 2d and 3d representation side by side.

For the pieces generated by the Tube program it is still a bit early to do that, as their 3d appearence might still be improved. There are many other new pieces for which these could be made, though. Did you plan on making those, or shall I do it?

Yes I will try to help to fill res/rules/fairy, I don‘t know yet how I'm going to get the 3d images consistent with the rest though.

for tube unfortunately I am not yet able to be useful so far.