PDA

View Full Version : Auto numbering issues in TANE...



VinnyBarb
June 2nd, 2015, 04:41 AM
Hi, I have an auto numbering issue in TANE. Looking at my signature picture below one can see on the first RDC in front a name in yellow in the middle of it, close toward the roof of the RDC there. I made that name texture the same way as I made the auto numbering textures for the numbers on the RDC and this works beautiful in TS12 when changing the last (end) number, the name changes too.

Sufficient to say it works in TS12 but as said but not in TANE. Any idea why this won't work in TANE, could it be a texture compressing issue of the name texture when installing this RDC in TANE as texture compression has now changed? The only textures showing where the name should be are the place holder textures one needs to texture there, so Trainz can remember which number (in my case only a name) to place where. Strange, isn't it? If I place a number there instead of the name texture, it works but why should there be a difference between a texture with the name on or with a number, when made exactly the same way as the auto alpha numbers are made. I made the number/name texture by placing its corresponding black/white 2 colour alpha texture (mask) over it and saving this with PEV's Img 2 Tga utility as an alpha layered 32 bit uncompressed Tga. As I did with all my created alpha numbers in the past or at the same time I created these RDCs for locomotive numbering.

VinnyBarb

WindWalkr
June 6th, 2015, 07:07 AM
It's feasible that this is a bug, although I'm not aware of any remaining bugs in this system. Previous issues that we've seen tend to relate to swapping out a texture with certain attributes for another with different attributes. For example, if the original was opaque, and the replacement was transparent, some material bindings did not update as necessary. It's possible that something similar is happening here.

Alternatively, it's also possible that you're setting a certain configuration in the texture.txt file, but your image doesn't correctly match that. For example, if you specify an opaque texture.txt, but then provide alpha in the TGA file, you may get unexpected results such as losing your alpha channel. In some cases this can differ from TS12 since the results of such a conflict were somewhat undefined there.

chris

VinnyBarb
June 6th, 2015, 05:07 PM
Thank you Chris for answering, the texture map in question is created the same way as any other auto number texture I created, with which I have no problems with. With a transparent background and only the picture intended showing to show. It is not a priority for me at present, I can do some other tests later in time to see if its behavior changes or gets fixed but it still puzzled me when testing earlier.

VinnyBarb

WindWalkr
June 6th, 2015, 08:25 PM
Another possibility would be that you have two planes of geometry very closely overlaid. When things get too close together, the GPU can no longer accurately determine which is in front, so sometimes renders the wrong one or a mix of the two.

Not sure whether this applies in your case, but it's another possible angle.

chris

VinnyBarb
June 7th, 2015, 01:00 AM
Does not apply in my case, I tried this already when checking. What I also noticed with creating these transparent auto numbers place holder panels and placing these panels on a locomotive just a fraction away from the body made so by some creators including me, these panels are now throwing shadows with their edges and the whole panel shadow on the locomotive body too. To fix this now one needs to boolean cut these auto number panels into the locomotive body itself with introducing extra and more vertices and possibly a distortion of locomotive body texture mapping there.

Not a big deal really, just an observation how shadows now show up and highlight this in TANE. Although with the previous shadow box one needed to create for locomotives, this was not shown and highlighted as it is now.

VinnyBarb

WindWalkr
October 14th, 2015, 02:07 AM
Hi, I have an auto numbering issue in TANE. Looking at my signature picture below one can see on the first RDC in front a name in yellow in the middle of it, close toward the roof of the RDC there. I made that name texture the same way as I made the auto numbering textures for the numbers on the RDC and this works beautiful in TS12 when changing the last (end) number, the name changes too.

Sufficient to say it works in TS12 but as said but not in TANE.

Are you still having this problem?

thx,

chris

VinnyBarb
October 14th, 2015, 03:16 AM
I have not installed Hotfix2, I still have TANE 76536, where this autonumber issue is still there, for the simple reason, there are still issues with Hotfix2. I am waiting for the big Service patch whenever that might be after its bugs are sorted as I do not want to change things again and again. Hence I am not uploading my for TANE created good content as in my signature picture below, where I created the SAR Bluebirds from scratch. Also like the SAR 930 Class locomotive I am presently working on, which is so obvious not quite correct looking in TS12 and does not give justice to it which it should deserve to be there in TS12, this beautiful Alco DL500. Rob needs a slap on the wrist with a wet fish (<--joke), when he created and updated that locomotive.

Anyway, I give the auto numbering a test, as said, after you get the SP patch released. Thank you for asking, I thought you might have forgotten me as someone else in the Content Creating forum has the same problem as I have with using a picture for auto numbering.

VinnyBarb

WindWalkr
October 14th, 2015, 06:08 AM
Thanks. I don't really care about the status of HF2 regarding items discussed on this forum, since we're focused on the internal builds. Since it sounds like you're not running the current builds, is there somewhere that I can source an asset for testing this issue?

chris

VinnyBarb
October 15th, 2015, 04:56 PM
Chris, sorry I am a bit late in replying, will send you the d/load link via PM over the weekend. Too much happening at the moment health wise with me.

VinnyBarb

WindWalkr
October 15th, 2015, 07:14 PM
Thanks mate. Take it easy and best wishes for your health.

chris

VinnyBarb
October 17th, 2015, 04:39 AM
Hi Chris, I just send you a d/load link from my web site via PM. Thank you for looking into this issue.

VinnyBarb

WindWalkr
October 17th, 2015, 05:13 AM
Thanks VinnyBarb. I've sent you through a reply with details on what's going on and what you can do about it.

chris

VinnyBarb
October 19th, 2015, 03:40 AM
For those interested about a solution to my problem given to me by Chris with his permission to post here:

Chris's answer after I submitted a test model:
At a quick review, here is the obvious problem:

"TS12 and below used raw "TGA" files instead of textures for alpha-number "fonts". This usage was common across various assets back in the original version of Trainz but was phased out over the subsequent years as it is inefficient (increasingly so since TS2009) and replaced with the use of actual texture (*.texture.txt) files. Unfortunately, because the filenames of the alpha-number images was hardcoded, we were not able to transition these images across to textures.

T:ANE no longer natively supports loading 3D textures from image files. Attempting to do so will cause one of the following outcomes in the internal test builds. I must stress that the behaviour in the release builds will be different, as this is one of the areas that the trainzdev group has been ironing out recently.

* If the content is built for T:ANE, it will fail outright. This will likely be detected at content validation time, although for some usages (such as the alpha-numbers) it cannot currently be detected until runtime. This is considered a fault in the content, and is resolved by changing from a "*.tga" format to a "*.texture.txt" format.

* If the content is older, and the image is <= 256 pixels in each dimension, T:ANE will attempt to import the file into a texture at load time. This is performance hungry, but we felt that it was necessary to avoid breaking various legacy content. This catches many of the old v1.x 128x128 ground textures and most specialty images such as signal coronas and alpha numbers.

* If the content is older, but the image is > 256 on either dimension, T:ANE will fail to load the content. An error is written to the logs (Developer > Show Logs) explaining the problem. This is an uncommon scenario because the majority of uses for the old TGA techniques were small.


So, your usage is obviously hitting that last scenario. Specifically, we can see the following error being logged:

- VE167: Source image texture file 'bb_alpha_numbers/alphanumber_5c.tga' is too large for 'arc:fld:$(local)/hash-0C||kuid2 184151 5250 1.tzarc|' (512x128)


There are a few ways that you can resolve this. The ones that spring to mind are:

* Reduce the image to 256x128, and keep the train as old content. This will work in both TS12 and T:ANE.

* Upgrade the train to a T:ANE trainz-build version and use "*.texture.txt" files. This will obviously only work in T:ANE and may require the internal test builds. We'll be releasing these changes to the public at some point in the future, but I can't speculate on when that will be."

Which means that I have to alter that particular texture I used as an alphanumber to what Chris suggested. I haven' done this yet but as Chris above assured me, that should work. In any cast, it is rare to have to use a texture, in my case a particular bird name, which goes only with a particular and distinctive autonumber, as an alpha number and this can possibly be achieved by scripting too. Since I am not a script writer, I have to stick to what I know.

I hope this helps someone else in the same predicament I found myself in when creating these SAR Bluebirds, which as said are in my signature picture below.

VinnyBarb

pcas1986
October 19th, 2015, 07:22 AM
I've update two WiKi pages on this issue: http://online.ts2009.com/mediaWiki/index.php/Texture_file and a CCG entry (http://online.ts2009.com/mediaWiki/index.php/CCG/Modelling:_Locomotive_Numbering)on the subject. The "normal" WiKi (i.e. that maintained by N3V) doesn't have any pages on auto-numbering/running-numbers except general notes on the KIND Traincar (http://online.ts2009.com/mediaWiki/index.php/KIND_Traincar) page.

VinnyBarb
October 19th, 2015, 04:07 PM
Thank you Paul, again I like to stress, it wasn't the actual 2 sets of auto number numbers I created and used to change with the "?" icon in Surveyor, where one changes these numbers, which were at fault. It was the 3rd set of auto numbers used (as a bird name texture TGA) created exactly the same way one creates for auto numbering and placed in the "xx.alpha_number" folder in the locomotive's root folder as per the way auto numbering works, Then named this so created new set of alpha numbers ("bird name textures") corresponding and showing on the relevant numbered RDC as an extra number set as "alphanumber_0c", ...1c, ...2c, ...3c etc.

As I only needed 3 different set of auto numbers, one up front on top on a number board, another set of auto numbers on the sides of the RDC top near each door and the 3rd set of auto numbers, their different bird names textures in my case, corresponding with its RDC number, in the middle on top of the RDC body which worked flawless in TS12 61388 but not in TANE. That is, when changing the Bluebird RDC (below in my signature picture) number from, say, 250 to 257, the right bird name for RDC 257 will appear. For a better explanation posted here (I hope) for others probably having something similar in mind with auto numbering.

Lucky for me there were only up to ten different RDCs created for each Bluebird RDC Class.

VinnyBarb

pcas1986
October 19th, 2015, 05:13 PM
OK. Are these SAR Bluebirds on the DLS in their TS12 form? I'd like to have a look at them in case I need to add something to the WiKi. I did have a look via the TS12 CM but couldn't pick them out.

VinnyBarb
October 20th, 2015, 04:04 AM
No, they are not yet on the DLS but I can send you the Zip file of 2 of these Bluebirds I send to Chris. I will send you the link via PM to d/load these from my web site. Still only in LOD0 only as I am waiting for the final outcome of all the LOD discussions going on here to implement the next 3 LODs. As said, I had these Bluebirds running flawless in TS12 61388 but in TANE with the above mentioned issues, which can easily be fixed according to Chris by making the name texture used as number smaller in size.

VinnyBarb

pcas1986
October 20th, 2015, 04:35 AM
That would be good. I can probably validate some aspects using my loco but I have a nasty feeling TANE will do a dummy spit and throw a lot of other errors - probably LOD related - at it.