PDA

View Full Version : Autonumbering in TANE, can this be made simpler?



VinnyBarb
June 8th, 2015, 09:19 PM
IMHO, auto numbering for locomotives is currently created in a very complicated, cumbersome and a sort of performance diminishing way. Let me elaborate, after presently implementing all the different mesh panels on a locomotive to carry the auto numbering alpha numbers textures, first a creator needs to texture map these said panels needed, each with a differently named texture map, which act as "placeholders" for the different alpha numbers (0 to 9, meaning 10 numbers in total) being used and getting placed presently by the game code on these "placeholder" textured panels. Each one of these different placeholder textures is needed, for the game to know, which transparent auto number needs to be placed on which panels plus each of these textures is of course presently a different Material Type in one's Material Editor.

Why you may ask, why do we need "placeholder" textures applied to these number panels? Well, a locomotive number usually has 1 to 4 different numbers displayed on their body, the singles as last the number, the 10s as second last number, the 100s as third last number and so on. In extreme cases (including some rolling stock) up to 6 of such numbers are needed. For each of these "placeholder" textures a creator presently need to create a different material type in his/her 3D program's Material Editor and we all know, any extra material type introduced is a performance robber/dampener. Whereas as explained below, each auto numbered mesh panel only needs 2 triangular faces, only one polygon for such mesh and no texture mapping needed with a certain place holder texture each, providing these individual number panel meshes in a locomotive's body are square or oblong and named in a such new convention. Compare this to the performance cost of each extra Material Type presently needed for such number meshes, some say something like 300 extra polygons per extra Material Type used with their EXTRA chunks introduced on top of it too.

Say a locomotive has 3 numbers on it that need to "auto" change, well, it does not auto change as such but by using the "?" icon in the locomotive menu in Surveyor, one can change this, as well as with some scripting too. Still with me? These 3 numbers mentioned above are, AGAIN, the "ones", the "tens" and the "hundreds" of a locomotive number and beside creating the different "placeholder" materials needed, in our example case in the picture below with 3 extra different material types now used. This is, if only one such number "font" display is needed. Now if one needs 3 different "Fonts", meaning 3 different distinctive looking numbers on a locomotive such as one "font", a somewhat larger and different looking number looking like an ATSF font on a cab side under the cab window and another "font" on the side or rear of a locomotive with, as said, another smaller and plain looking "font" needed there and another again extra different looking "font" number needed on a number board above the cab in front, this gets blown out to 9 different material types being used for a locomotive.

That is my Material Editor showing only a few Material Types getting used on a locomotive I created with 3 different "fonts" and 3 different numbers being used:

http://www.vinnybarb.com/pics/anxx3.jpg

where above one possibly would need an extra reflective material plus whatever other extra material type would be needed. Even if only 2 "fonts" are being used for 3 numbers on a locomotive, say, on the cab side and a side/rear simple different looking number, it is still 6 extra Material Types to be used and introduced into one's Material Editor beside the Material Types one is already using to create the locomotives without the numbers.


http://www.vinnybarb.com/pics/anxx4.jpg

I have seen some locomotives in Trainz with 4 different fonts and 4 different rows of numbers, the 1000s number, the 4th number counted from the rear of a number which again would increase the number of Material Types used.

Suppose there is a different and new way to name the different number panel meshes needed for the ones, tens, hundreds and so on with a distinctive name for each of these number mesh panels, any extra font getting used with an extra distinctive letter or number code used on that on that particular number mesh's name described very much simplified below and with obviously some new game code needed for this.

Say, the number mesh panel to display only one single "font" and the one particular alpha number needed there to be named something like "mesh_x1", the ten number panel as" mesh_x2" and so on. Now if there is now an extra "font" getting used, 2 different "fonts" now, for which extra mesh number panels are getting introduced and used, say with now 2 different looking numbers displayed on a locomotive, say a large number on the side of the cab in an ATSF or whatever different font and also a plain black/white looking "font" number on the side/rear with their extra number panel meshes needed. Naming these extra number meshes needed now with the extra "font" such as "mesh_x1a" for an extra font alpha number to be placed on the single extra font number mesh needed and also further named "mesh_x1b" and "mesh_x1c" and so on for the 10's and 100's of these extra needed font number mesh panels. And so on, further "mesh_x1e" for the 1000's numbers, so the game knows, hey, there are now 2 different fonts getting used, place the corresponding different alpha numbers on the correctly coded and named mesh panel(s) on the locomotive.

Again, naming these panels as above as a DISTINCTIVE named mesh panel for the different numbers and fonts needed which are actually used on a locomotive. Not any EXTRA material types would be needed that way, only these new and distinctive mesh naming conventions would be needed to be in the game code and as such referenced and configured in the config.txt referenced there with the actual alpha number texture maps names one would need for a particular mesh number panel. And similar for any extra font needed with their extra number mesh panels needed and named as distinctive meshes again as above continued like "mesh_x2a" and "mesh_x2b" and so on for any extra numbers for that font needed.

This would IMHO simplify auto numbering as this is still quite a mystery to some/many and would make it much easier to implement or easy to change in one's locomotive asset's config.txt only needed to set up this up. Beside the extra mesh number panels one would need in any case with the old numbering system presently in place. Of course the relevant text entries there in the config.txt now only needed to point correctly to the Alpha Number Texture Maps contained in the CDP for correct placement where these need to be and so on. Plus having now the extra bonus of not having these extra Material Types needed and hence being better performing in game.

Is the above a good idea and would this be at all feasible in TANE? Or is this perhaps a daft idea and not possible to make this work or even if this might be possible in a somewhat slightly different way or even in a completely different way without these extra Material Types needed? Can anyone please add to this or has someone perhaps a somewhat different idea or proposal for auto numbering for TANE. As TANE now is still getting created and updated on the fly, now would be the best time to introduce a simpler way for an auto numbering system into the game code and change this there. I not being a programmer myself, does all the above makes sense to any programmer/coder or is this not practicable/feasible at all?

Food for thoughts.

VinnyBarb

VinnyBarb
June 11th, 2015, 03:55 AM
Some one? Any one care to comment?

As said above, wouldn't it be much much easier to name a particular numbers panel a distinctive coded name and this will place the right number texture on it, instead all the current heavy handed, performance robbing way we content creators have to implement and get auto numbering to work. The above described way it is very much simpler to get there in just a few steps, providing the way this should work is reflected in the code of Trainz/TANE.

Again, any comments, suggestions or criticism is welcome?

VinnyBarb