I just made a new siglight.ace using SigView technology

This one is for all of you confused with copyright problem to update your routes. I manually made this one. Not like Maple Leaf Tracks's SigLight.ace, it's DXT format, so it will save your video card memory. A 512x512 DXT texture only take 171KB memory, 512x512 Zlib texture will take 512KB (or more) video card memory. For compatible reason, this texture use same image size as MLT's texture so you can directly replace it without any other change.file see attachment, only 3kb.What I feel now is this new texture is too bright, but since I not live near railway, I need your comment. I also want to know you like what kind of lamp. After finish adjustment. I will upload it to train-sim file library and all of you can use it without restriction.

Attachments
http://www.train-sim.com/dcforum/User_files/41660ce60b33027d.zip

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

RE: I just made a new siglight.ace using SigView techno, sniper297, Oct-08-04, 00:26 AM, (1) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-08-04, 02:59 AM, (2) RE: I just made a new siglight.ace using SigView techno, black5, Oct-08-04, 10:39 AM, (3) RE: I just made a new siglight.ace using SigView techno, sniper297, Oct-08-04, 01:28 PM, (4) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-08-04, 09:06 PM, (7) RE: I just made a new siglight.ace using SigView techno, oldiedaddy, Oct-08-04, 01:34 PM, (5) RE: I just made a new siglight.ace using SigView techno, smmille1, Oct-08-04, 03:06 PM, (6) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-08-04, 10:03 PM, (9) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-08-04, 09:50 PM, (8) RE: I just made a new siglight.ace using SigView techno, sniper297, Oct-09-04, 00:28 AM, (10) RE: I just made a new siglight.ace using SigView techno, buzzbenz, Oct-09-04, 01:53 AM, (11) RE: I just made a new siglight.ace using SigView techno, Hack, Oct-09-04, 02:54 AM, (14) RE: I just made a new siglight.ace using SigView techno, Hack, Oct-09-04, 02:52 AM, (13) RE: I just made a new siglight.ace using SigView techno, CVL_Post, Oct-11-04, 09:33 AM, (17) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-11-04, 09:19 PM, (18) RE: I just made a new siglight.ace using SigView techno, Hack, Oct-09-04, 02:43 AM, (12) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-09-04, 03:45 AM, (15) RE: I just made a new siglight.ace using SigView techno, Hack, Oct-09-04, 09:50 AM, (16) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-13-04, 05:39 AM, (19) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-13-04, 11:46 PM, (20) RE: I just made a new siglight.ace using SigView techno, oldiedaddy, Oct-14-04, 03:05 AM, (21) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-14-04, 06:24 AM, (22) RE: I just made a new siglight.ace using SigView techno, black5, Oct-14-04, 07:50 AM, (23) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-14-04, 08:43 PM, (24) RE: I just made a new siglight.ace using SigView techno, wdq4587, Oct-14-04, 09:41 PM, (25) Batch file for make special MIP levels data, wdq4587, Oct-19-04, 11:49 PM, (26) RE: Batch file for make special MIP levels data, CVL_Post, Oct-20-04, 09:33 AM, (27) RE: Batch file for make special MIP levels data, wdq4587, Oct-20-04, 08:28 PM, (28) RE: Batch file for make special MIP levels data, rd4man, Oct-21-04, 03:51 PM, (29) RE: Batch file for make special MIP levels data, buttercup, Oct-21-04, 04:05 PM, (30) RE: Batch file for make special MIP levels data, rd4man, Oct-21-04, 04:24 PM, (31)

Conferences | Topics | Previous Topic | Next Topic

No problem with the brightness that I can see, and the colors are actually adjusted in the sigcfg.dat file anyway, you can make those darker so it don't look like neon at a distance. Only problem is the same one that the MLT version has, the alpha channel is visible when forest regions are behind the signal head.\Odd thing, the MLT version is a compressed 8 bit alpha, this is a compressed 1 bit alpha and it still does it. Wonder if leaving it uncompressed would cure it? In any case you could also try reducing the size to 256x256, that wouldn't be visible as far away, but would still be better than the default, and would leave a smaller area affected by the ghost image.FYI, you can also use different names and even different textures for each signal:SIMISA@@@@@@@@@@JINX0G0t______LightTextures ( 2
LightTex ( "BNSF ltex" "siglight.ace" 0 0 1 1 )
LightTex ( "ltex" "siglight.ace" 0 0 1 1 )
)That's the default BNSF from USA2, you could change that:SIMISA@@@@@@@@@@JINX0G0t______LightTextures ( 6
LightTex ( "number1" "whatever1.ace" 0 0 1 1 )
LightTex ( "number2" "whatever2.ace" 0 0 1 1 )
LightTex ( "number3" "whatever3.ace" 0 0 1 1 )
LightTex ( "number4" "whatever4.ace" 0 0 1 1 )
LightTex ( "number5" "whatever5.ace" 0 0 1 1 )
LightTex ( "number6" "whatever6.ace" 0 0 1 1 )
)to use as many different textures as you want, just change the SignalLightTex ( "BNSF ltex" ) for each signal type to match whichever texture you want to use for it

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

One of my friend - a chinese train engineer - just also told me the brightness has no problem. But what "you can make those darker so it don't look like neon at a distance." mean? I also feel it look like neon at long distance, does it better I change texture a little darker than let user change the color in sigcfg.dat ? I think most people are not professional on adjust color. Or it's better change the signal color saturation than change brightness?Then about "the alpha channel is visible when forest regions are behind the signal head". I haven't seen that yet (for I have not test much). But I think that's the problem with 3D texture render mechanism, the priority of alpha texture, no relation with texture is 8 bit or 1 bit alpha, compressed or not. We've seen such thing in some locos. I don't know how they resolve this problem and does know that can help this.Then about "reducing the size to 256x256". That will not help the "ghost image" problem if you don't change radius. If you reduce the radius, may be we can not see it as far as MLT's version. I'll do some test to see does reduce radius will reduce the visible distance.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Thank you..will try it in a few minutes.
Evrything that makes MSTS better is always appreciated..
Georges

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

"does it better I change texture a little darker than let user change the color in sigcfg.dat ? I think most people are not professional on adjust color. Or it's better change the signal color saturation than change brightness?"We got a translation problem here I think! The signal texture is not the light, it's just what is used to display the light, and I don't think changing the texture is going to do anything. The texture is essentially black and white, so there's no saturation to change?Hmmm. This is hard to do, since jpeg compression changes colors, and gifs aren't much better, but here's what I'm talking about;The one on the left is default:LightsTab ( 4
LightsTabEntry (
"Red Light"
colour ( 255 255 40 40 )
)
LightsTabEntry (
"Amber Light"
colour ( 255 255 200 0 )
)
LightsTabEntry (
"Green Light"
colour ( 255 0 255 0 )
)And on the right the colors are slightly darker:LightsTab ( 4
LightsTabEntry (
"Red Light"
colour ( 255 205 0 0 )
)
LightsTabEntry (
"Amber Light"
colour ( 255 228 196 0 )
)
LightsTabEntry (
"Green Light"
colour ( 255 0 205 0 )
)I think the first number is the transparency of the light source itself, possibly reducing that might improve appearance, I haven't experimented with it yet. The other three numbers in order are red, green, blue, with 255 being full bright and 0 being totally dark. So to get dark colors, 128 0 0 would be a dark red, 228 128 0 gives an orange, 0 0 128 would be dark blue. Most graphics programs have a color pick tool that lets you see what the numbers are for each color shade and brightness;So it's not really that difficult to adjust the colors."Then about "the alpha channel is visible when forest regions are behind the signal head". I haven't seen that yet (for I have not test much). But I think that's the problem with 3D texture render mechanism, the priority of alpha texture, no relation with texture is 8 bit or 1 bit alpha, compressed or not. We've seen such thing in some locos. I don't know how they resolve this problem and does know that can help this."http://www.train-sim.com/dcforum/DCForumID6/12229.htmlThere's a small test route, download both zips from the first post and the one zip from the second post. Run installme.bat, 1forest.bat, then 1long.bat, that will give you the combination of forest regions and long distance signals. I don't know what the problem is either, something about the remipping is making it so the alpha does not stack over the forest region alpha. Possibly uncompressed it might work, or some change to the mipmapping."Then about "reducing the size to 256x256". That will not help the "ghost image" problem if you don't change radius. If you reduce the radius, may be we can not see it as far as MLT's version. I'll do some test to see does reduce radius will reduce the visible distance."Forget that idea, I just tried it by making the ace file opaque:I was thinking a smaller texture would be less noticeable, but it maps to the same size?! Another oddity, these are flat bitmaps with no alpha channel, and yet the texture shows as semi transparent? Obviously there's more to this signal light display than I thought.Anyway, it's a good start, I didn't use those signals in PO&N 9 because of this problem, if you can make this work with the forest regions behind it you'll be my hero!

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hello sniperI do not have a "translation problem". The problem is what I said was too short. I just mean change the color in sigcfg.dat to change the saturation. Texture can change the brightness.Then about "jpeg compression" change the color. I don't know what program you used. Many program will use a color 4-1-1 compression for JPEG compress. That's not good for some picture with much color. I use a 1998 version JPEG Optimizer with "Extra color" option which can use color 4-4-4 mode for compression. New version of this program do not have such option, then whether how you adjust the quality, you can not get good result.Your edited color seems only dark, nothing else. If that's your want I think modify the texture to dark is better. If you want only long distance dark or shor distance dark. I can change for that.About adjust the color. I think the color pick of program you used is still not as good as HSB color pick of Fractal Design Painter
About adjust the color. The problem is people need know the color theory. How is RGB? How is HSB? Not the how they can adjust it.I have seen the alpha channel problem last night. It seems the problem only occur on tree, not other objects. Since I have seen such problem on some other locos. I think the problem is on the tree implement of MSTS, not other objects or lights. I haven't seen anything in ACE file can affect priority of alpha texuture, I think that's in 3D model. But if you know more information or what step can let you remove such "ghost image", please tell me. I will do further more test.Texture map is defined on 3D object. It's alway map to same size whether it's image resolution big or less. Some times you can see some people use a 512x512 pure color texture. That's really not necessay. a 32x32 or 1x1 texture is enough. (1x1 texture need special program to make).Last night, I change the light radius to half. In night, it's still can be seen in 2000m distance, but not so bright, may be more like real. But in day, it's very difficult to see at such long distance. Even at 800m, it's still a little difficult to distinguish. Compare to original size version, it can be very easily seen at least at 1200m. So reduce the light radius is not a good idea. I also have change the saturation, can not got good result. Since we can not have a night texture for signal light (can we?). We had to let it too bright in night, it's good than difficult to seen in day.I can not "make this work with the forest regions behind it". Unless we got information about why some other locos also has such problem, how they resolve this problem, and where is signal light 3D object (does it have 3D object?), or adjust tree 3D object (may be too much).

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Oct-08-04 AT 01:39 PM (EDT)

There is a similar thing in the new Wupper Express 8, due for release in 2 days.
Can the texture get DXT'd ?
Maybe with AceIt/TGATool2a, probably not with MakeAce/TGATool2.
It is a 512*512 compressed 24bit+Trans, and weighs only 24KB, so not much to gain with DXT anyway.The trick is in the Mips, if I understand correctly ?
Alpha is ON on short distance, OFF from farther.Did not notice transparency hierarchy prob in WE8, but not many forests in there, at least not near tracks. Love and Peace

OldieDaddy from Alsace

Visit also www.the-train.de !

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Since the signal colors (or colours) support transparency, my guess is that the actual signal light textures (not just the source files, but the rendered combined color settings + source textures) are always classified as an "alpha" texture.here's their definition of colour () from newshape.bnf (and I assume it's the same throughout - why floats?)
colour ==> :float,A :float,R :float,G :float,B .The 'holes' only show up on other alpha objects, since MSTS doesn't have a clue about proper sorting. Kuju must've done something to the way textures are loaded for forest regions that makes them always appear as alpha, hence the holes.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I haven't do more test yet. But I think you were right. "The 'holes' only show up on other alpha objects", not only tree. The problem is the alpha textures priority and order while render. I need learn more information about that.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hello oldiedaddyglad to see you again.Just as I said above. Compare a DXT (zlib compressed) and a ZLib compressed texture. The difference is not 3kb vs 24KB. But 171KB DXT texture vs 512KB Non-Compressed 1-555 texture in video card memory. Video card have limited memory, it can not hold much textures, if memory is not enough, it will swap with computer RAM or even with disk. That will reduce FPS and make more lag. (lag is more bad than low FPS)Of course the trick is in the Mips. But alpha is always on for you can not change texture type between mip levels. A 512x512 texture contain 10 mip levels. 512,256,128...,1. The SigView technology only change the mip levels resolution less than 32, and make light in such mip level (image) bigger and bigger. In 1x1 (and 2x2) mip level, it's solid, and may be at 2000m (2000m range to see object is MSTS limit), you seen a radius 1.04m light, in a short distance, you only see a radius 0.12m light. That's why you can still seen light at 2000m distance in MSTS.Currently such kind texture is still manually made. My method is generate a series ACE files, split files and merge. I have batch file for that. But since the command line tool for split file have some bug (a dos program written by me in 1994). It's still not the time to public the batch file. I think AceIt can not do such things now for it will generate mip levels instead use your texture's mip level as mip level (for makeace generate mip levels bug). If you want that, I can manuall make file for you or give batch file and split tool to you privately. BTW, still want you try my Acebcomp and give some comment. ftp://61.190.248.100/download/tools/acebcomp.zip (haven't update yet)

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Well, the whole thing still baffles me, but just to make one thing clear, it's the forest regions themselves, not anything with an alpha channel.On the left side of the track is a tree clump object, on the right is two forest regions. The forest region is behind the left hand signal, so from this angle you get the hole in the forest region.Moving the camera over the right hand signal now has the forest regions in the background, and the left signal has the tree clump in the background. The textures are the same for both, the two stacked forest regions use the exact same ace files as the treeclump, DXT compressed 256x256 1 bit -trans ace files. So it's not the textures, 1 bit VS 8 bit, DXT VS ZLIB, since it does it with the forest region and does not do it with the tree clump, because they both use the same ace files.The locos that have done this might be the same thing, I don't remember offhand. As I recall some forest regions that used 8 bit alphas were the problem there, but if you stack multiple 1 bit forest regions you get the "ghost tree" effect from some angles even with no engine in the foreground. Simple cure for that is to place any object with either a 1 bit or 8 bit alpha, even a small bush, between the forest regions and the track every 50 meters or so. That little trick don't work for this mipped siglight.ace, any forest region behind the signal has to be blocked completely to avoid the hole.Possibly this is incurable, if that's the case those of you who are just starting routes may want to use treeclumps instead of forest regions wherever possible. Place the signals first, then while placing trees or forest regions make sure the forest regions are not visible from the signal head. Test it in the sim, since the effect doesn't show up in the route editor.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I've seen this before - the problem's not the signals, it's the trees. It is possible the model used for the trees in the forest regions do not have the Alpha priority correct. Unfortunately, that is NOT curable without changing or replacing the model itself, as Alpha priority is assigned in the material naming when the textures are mapped.Might be kind of interesting to see if it is possible to replace the tree model with one that has a different Alpha priority - or even better, just transparency (Alpha = translucency). (Sorry though, i'm not volunteering - too much on my plate as it is!)Though with MSTS, it could indeed be a problem with the sim itself... I guess we won't know until someone tries to change the tree models used ----------- BUZZ -----------

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

IIRC, the forrest object is dynamic and thus can't be altered or modified without reversing the EXE.Cheers!
Marc - 3DTrains
http://www.3dtrains.comPro Series v4.0 SuperPacks

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>Well, the whole thing still baffles me, but just to make one
>thing clear, it's the forest regions themselves, not
>anything with an alpha channel.Correct. Aside from track objects, forrest regions have the lowest alpha sort priority in the sim, and also why you sometimes see the "ghosting" you mentioned, regardless of the alpha used in the texture.I'm not up on signals, but if they use their own signal light object, then that object needs to have its material ID set so that it uses the "Trans" alpha switch. An object could also be built using the "Test Only" alpha switch, but requires sorting in the LOD Manager. If the signal doesn't use its own light object, then the preceding is moot. Cheers!
Marc - 3DTrains
http://www.3dtrains.comPro Series v4.0 SuperPacks

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi Wang,Your engineering job for making a siglight-texture with extended visibility is sure a good job indeed! I think we sure like to know more about the technic to make a light-texture with enhanced visibility.I've downloaded your beta-tool from your post and i've looked for a min to this, but when i start the tool, it fails to load mwace.dll or cant find it.Could you make a sort off tutorial how to make a enhanced ligt-texture?
I understand that the key is to generate a ace file with special mip-levels and that a 512x512 texture has a max off 10 miplevels and a 256x256 texture has a max off 9 miplevels, e.g. a 256x256 texture has also the images 128x128,64x64,32x32,16x16,8x8,4x4,2x2,1x1 pixel images, is that right?I understand you made the light-texture by generating a texture for each miplevel and then merged it to one texture with your tool, is that right?I noticed that your light-texture is 512x512 DXT1 compresion, allthough it's only 3 kb, looks like you use Zlib compression as well, as far as i know 512x512-DXT1 compresion is allways 171kb?Also i notices that both your light-texture as the one from MLT looks square from some distances, but yours looks also as a diamant (square 45 deg rotated)at some distance, i wonder if this can be improved, so that the light-texture allways looks round more or less.Thanks for any answer and greetings from Dereck

Greetings from Dereck van Dijk, The Netherlands.
I've made some nice Dutch Payware-signals, see at www.msts.nl and click on "Dick's seinen"

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hi Dereck, >I've downloaded your beta-tool from your post and i've
>looked for a min to this, but when i start the tool, it
>fails to load mwace.dll or cant find it. You may download Mwgfx DLL set for mwace.dll. You need download
it from Martin's site. URL is in my readme.txt>Could you make a sort off tutorial how to make a enhanced
>ligt-texture?
>I understand that the key is to generate a ace file with
>special mip-levels and that a 512x512 texture has a max off
>10 miplevels and a 256x256 texture has a max off 9
>miplevels, e.g. a 256x256 texture has also the images
>128x128,64x64,32x32,16x16,8x8,4x4,2x2,1x1 pixel images, is
>that right? You said were right.
If resolution is 2^n, then number of mip levels is n+1.>I understand you made the light-texture by generating a
>texture for each miplevel and then merged it to one texture
>with your tool, is that right? There are not much secret on how to make enhanced ligt-texture.
You just need know cut file where and then merge them together.
It's need a file split tool, for easy to use reason, it's better
use a command line tool. I just have a program I wrote 10 years
ago for that. But I found some bug on it so I can not release it.
May be I can fix bug or use other tools instead. For merge file,
use "copy /b" command line is enough.A 3D ACE file contain a file head, a lines or mip levels index table,
then is each MIP levels data. File head size is changed based on texture type:
opaque=216, trans=232,alpha=248Non-Compress ACE file use lines index table, each line have a 4 bytes ptr.
So all lines index table size is (2*n-1)*4
DXT ACE file use a mip levels index table.
mip levels index table size is (n+1)*4
Since file head include a 16 byte Kuju file head. These ptr offset need
+16 when you read texture file.Then about each MIP levels data size.
Non-Compress ACE file store data by line,
each line size is:
opaque=width*3
trans=width*3+ceil(width/8)
alpha=width*4
each MIP level data size = linesize*height.
( ceil() mean get a smallest integer above the input)DXT texture store data by 4x4 pixels unit compressed to 8 byte
each MIP level data size = width*height/2 + 4
that 4 byte at each MIP level data begin is the size of this MIP level.
if resolution is 2x2 or 1x1, use Non-Compress method to store,
data size is 14 and 4 for trans. no 4 byte for mip level size.With description above you can calculate where to cut. If you like,
you may verify the length you calculated with existing ACE file size
(made by MakeACE or MakeACEWin). I will release a batch file for
make 512x512 DXT file if I get the tool fixed or find one replace.MakeACE can not make ACE file low than 32x32 resolution. You need make
the image resolution as you expected then resize to 32x32.
(use nearest neighbour algorithm for resize)>I noticed that your light-texture is 512x512 DXT1
>compresion, allthough it's only 3 kb, looks like you use
>Zlib compression as well, as far as i know 512x512-DXT1
>compresion is allways 171kb? Yes, DXT1 file can be ZLib compressed again. I've been told by Decapod.
You may try Acebcomp. It also support that.>Also i notices that both your light-texture as the one from
>MLT looks square from some distances, but yours looks also
>as a diamant (square 45 deg rotated)at some distance, i
>wonder if this can be improved, so that the light-texture
>allways looks round more or less. My one have a good feeling at screen resolution 1600x1200.
But it seems strange on 800x600.I just try make one look like MLT's one at long distance.
But I meet some problem. May be there are some error on MSTS
or DirectX process DXT texture last 2x2 and 1x1 mip levels.I will do more test on that. If I can not reslove this problem.
May be I had to give a ZLib compressed only texture for low
screen resolution.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>it's DXT format, so it will save your video card memory.
>A 512x512 DXT texture only take 171KB memory, 512x512 Zlib
> texture will take 512KB (or more) video card memory.IIRC, the video texture memory's about the same - what you save is hard drive space, not video memory, since both DXT and Zlib are decompressed when loaded to your video card. Zlib and DXT are simply compression algorithms. The idea is since DXT is native Direct-X, it should theoretically be more efficient in the sim.Nevertheless, thank you for the contribution. Cheers!
Marc - 3DTrains
http://www.3dtrains.comPro Series v4.0 SuperPacks

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

>>it's DXT format, so it will save your video card memory.
>>A 512x512 DXT texture only take 171KB memory, 512x512 Zlib
>> texture will take 512KB (or more) video card memory.
>
>IIRC, the video texture memory's about the same - what you
>save is hard drive space, not video memory, since both DXT
>and Zlib are decompressed when loaded to your video card.
>Zlib and DXT are simply compression algorithms. The idea is
>since DXT is native Direct-X, it should theoretically be
>more efficient in the sim. Not like that, Hack. Most video card can support DXT texture, so I think DXT texture will be loaded into video card memory, not decompress before load it into video card memory. But no video card can support ZLib compressed texture, for it can not be randomize seek by (x,y). So it must be decompressed before load into video card memory. And the game program or DirectX API need do more work to convert these 24+1bit/pixel Non-Compressed texture to 1-555 16bit/pixel Non-Compressed format before use it. I don't think DirectX API will do a on-the-fly DXT compress on these Non-Compressed texture before use it, otherwise it will be more lag while game playing. DXT compress is very time consumed.Why video card support DXT compressed format as texture but not support other popular format like JPEG? Because DXTn format use 4x4 pixels as a unit to compress and compressed result is fixed length. So video card can easily randomize seek a pixel on it (almost) while 3D render. Video cards have and will support more compressed texture formats. But they all use a small unit for easy to seek the pixels. In theory use small unit is not necessary, but any format must need do only a little calculate before read a pixel then can be used for 3D render quickly. ZLib compress need decompress all data before useful data so there are no way to directly use such format in video card.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Alrighty then - thanks for the clarification. Cheers!
Marc - 3DTrains
http://www.3dtrains.comPro Series v4.0 SuperPacks

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

It took me much time to debug the DXT MIP lveles problem than make a siglight.ace . What I found is MSTS or DirectX API ignore last 2 MIP levels in DXT texture file, e.g. 2x2 and 1x1 pixel MIP levels. So whatever what I input in this last MIP levels, it does not affect 3D render result. The last result is controled by 4x4 MIP level. But in SigView technology, 2x2 and 1x1 is important and different with 4x4 MIP level. I can not let DXT version works well on 1024x768 or low resoultion. It seems too bright at middle distance. But for 1600x1200, DXT version still wroks well.So I decide release 2 version, DXT and ZLib for different game screen resolution. Plus I draw the image of texture myself instead use default MSTS signal light image. Then I decide upload it to train-sim file library. But just before upload I found do not have a screenshot for it. Since screenshot is very important for download counter. I need go home take one, upload will be 12 hours later. I just put new file without screenshot here. Everyone have downloaded first one please download again. (13kb)Then about the "holes" in front of "forest regions" problem. I have do some search but it seems signal light do not have it own 3D object file. (I think MSTS use internal 3D object for all one rectange face object.) So it's seems no way to fix. The only thing I conside is does there are any way convert (or generate) the "forest regions" to "tree clump object", is that possible? does somebody can make a tool for that?

Attachments
http://www.train-sim.com/dcforum/User_files/416cf7902e72dcc1.zip

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I just add the screenshot and a "known issue" chapter in readme file. I also fix a error in document: multipy should be 8.67 not 8.33 . The file has been uploaded to train-sim file library. It also can be download here (24kb).Then about "the holes" problem. I notice in sigcfg.datLightTex ( "ltex" "SigLight.ace" 0 0 1 1 )there are "0 0 1 1" seems no one changed. But I guess change that will not resolve the problem.
Question: If I am a normal game user, and I use 1024x768 screen resolution to play MSTS, I have downloaded MLT's sigview.zip, does I need your new version?Simple answer is: No
But you may still download it for I have move description on how to install than that.

Attachments
http://www.train-sim.com/dcforum/User_files/416df6462cecdea1.zip

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

@ WDQ
Hello to ZhongGuo, friend Wang Da Qing
No time to deeply test these days.But an invitation to you :
have you got Wupper Express 8 ?
How do you think about the signal light texture wuppexsiglight.ace ?
Any suggestions for further improvement ?Love and Peace

OldieDaddy from Alsace

Visit also www.the-train.de !

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I already downloaded Wupper Express 8, but still have no time to install it. I will test it tonight I have checked wuppexsiglight.ace, it's a Zlib compressed texture. I guess there will be no difference at long distance compare with MLT's one or my version. But it really look like what I need see it in game.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hello WDQ4578
I have your siglight in one of my routes (1024x768 version) and it is very good.
For some reason it does not appear as bright as the first siglight published.
I like that because it appears more realistic..
Thank you.Georges

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Hello GeorgesLet me have some explain. The first one is the DXT version. The file uploaded to train-sim file library contain both DXT version and Zlib version. If you like more bright, you may use the DXT version I said for 1600x1200 resolution for 1024x768 resolution. But just as I said, it's not perfect on such resolution, it will looks too bright at middle distance. What I mean is when you far away from the signal, you may see signal brightness increase, or when you near the signal ,you may see signal brightness decrease.Why I can not let DXT version works well on such resolution, let me have more detail explain. In Zlib version, MIP levels 32x32, 16x16,8x8,4x4,2x2,1x1 contains 2x2,2x2,2x2,2x2,2x2,1x1 rectangle pixels for light. In a long range, brightness will not change for size of light is same in screen. In DXT version, MIP levels 32x32, 16x16,8x8,4x4,2x2,1x1 contains 12,12,12,12,?,? pixels for light. So it looks more bright (but for 1600x1200 it will not too bright than Zlib version in 1024x768). The problem is last 2 MIP levels of DXT version, I can not control it, it seems there are a bug in MSTS or DirectX API, it will ignore last MIP levels image specify in texture file. The last 2 MIP levels should be full for light. But since it generate from 4x4 MIP levels, it's depend how 4x4 MIP levels look like, if it look like 2x2 rectangle pixels in center for light, the result may be 0 and 0. If 4x4 MIP levels is look like 12 pixels for light, it may be 2x2 and 1x1 for light. Does it looks too complex? The simple result you need know is I can not let DXT version have same MIP levels image in last 6 MIP levels as Zlib version. Otherwise I will can not let it be seen at long distance.So what will happen when I use DXT version on 1024x768 resolution? It will be too bigger (12 vs 4 pixels 3 times at middle distance). At 2000m distance, it's about same for light is only 1 pixel in screen, when near you, it's also looks same. Only problem is at middle distance, and that cause you feel strange when you near the signal.If you have experience stay in locomotive cab and still think Zlib version or both is not bright enough, may be I can modify texture for that. There are not much choice on last 6 MIP levels, 4 pixels or 12 pixels, for image must be on center. But I think I can reduce size make a 256x256 DXT texture for 1024x768 resolution (will loss detail when you near signal light)

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Last night I tested it. It have much improvement over 7 or 6 version, and still maintain a good FPS at high speed.There are some flaw in Wupper Express 8 signal light. First is I notice it's too dark when I near the signal. I can not believe so dark signal can be seen at long distance. I check the image of texture (MIP level 0 ) and it seems nothing wrong, but after I replace it with my version, it's more bright in short distance and also some bright in long distance. I still have no time to check more MIP levels, but I think the texture need be change.Second is I notice double red signal flicker. This issues I just described in my new uploaded file readme. I fixed it by move one light 0.002m at Z axis. (Fixed file just has been sent to you via email).Third is I feel some light position need be adjusted in Z axis. Otherwise it will be look strange when close the signal. I think it's better done by the signal author. I suggest use SView and Scale Gauge to measure the position.BTW, I feel some object in railway system have too much high saturation, I mean that red one in end or track. If it's not made by special material which can reflect light, a normal object should not have too high saturation as lamp.In my siglight.ace, light image size is about 59, less than Wupper Express 8's one 71 pixels. So I later multiply radius 120% to see result. I feel the signal may be too bright, so I reduce the color brightness specified in sigcfg.dat to 87%, but it's too dark! Then I change it to 95%. I think it's good at long distance, when near the signal the lamp may not bright enough a little. If it's just as I think, may be don't change the color but change the MIP levels image a little dark for long distance is better. But since I do not have the experience in loco cab, what I think bright or dark may all wrong.I guess germany railway signal do not use Fresnel lens as my new textures. So the image of lamp aslo need be modified. Wish somebody can show some photos of the signal, at day, at night, especially at long distance. I also think use a good real photo as lamp texture may be better than draw by hand.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

I have fixed my tool - split, now it's a windows console program and released under GPL (I think it also can be compiled to UNIX/Linux). If anyone like it, you may freely upload it to other sites. I will appreciate that for I have no time to do that.I made 2 batch files for make 512 trans texture to DXT1 and Zlib format. While make these files, I found there are a problem: MakeACE seems have some intelligence, it will not convert a full opaque file to trans type ace file even this file is 32bit TGA file. So I also make a AceIt version batch file for it. If you use MakeACE for convert, I add some check on image <=32x32 to prevent the problem. A tricky is use earse tool earse a little on image, it will not change result but can let it output trans type ace file. sig1.tga is a example for that. _sig1_opaque.tga is the file full opaque and will not pass the check.This bat package is released for advanced user only (of course), so I will not say much about how to use it. I use a sign.dat to indicate the file contain special MIP level data for future use. That may avoid MIP levels data be destroyed while texture compress. More I need say is if you want make a zlib texture, make a Non-Compressed ACE file first, than use tools like Acebcomp or SaveTex or RR to compress it.Since my work is busy, I have not make the batch file to split MIP level data to ace files which can be viewd by TGATools 2. If someone request, I may write one and include it in package before upload to train-sim library. But if you carefully read follow detail, you may write one.Let me show some formula on how to calculate offset in ACE file:ACE file made by 3 part: file head,index table,MIP levels datasFileHeadSize = 216/232/248 for texture type Opaque/Trans/AlphaIndexTableSize = (2*n-1)*4 for Non-Compress width=height=2^n
= (n+1)*4 for DXT1
This IndexTableSize is for 3D texture with MIP levels, not for Bitmap textureMIPLevelSize = LineSize*height for Non-Compress format
LineSizeOpaque=width*3
LineSizeTrans=width*3+ceil(width/8)
LineSizeAlpha=width*4
( ceil() mean get a smallest integer above the input)MIPLevelSizeDXT = width*height/2 + 4 for DXT1 format
for DXT MIP levels 2x2 and 1x1 MIPLevelSizeDXT=MIPLevelSizeThen for example, MIP level 3 begin offset is:FileHeadSize+IndexTableSize+MIPLevel0Size+MIPLevel1Size+MIPLevel2SizeMIP level 3 end offset is:FileHeadSize+IndexTableSize+MIPLevel0Size+MIPLevel1Size+MIPLevel2Size+MIPLevel3Size

Attachments
http://www.train-sim.com/dcforum/User_files/4175dfee18538338.zip

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

hi Wang,Is it also possible to use this tool for making a light-texture with a base-size off 256x256 pixels ? my light-texture is 256x256greets from Dereck

Greetings from Dereck van Dijk, The Netherlands.
I've made some nice Dutch Payware-signals, see at www.msts.nl and click on "Dick's seinen"

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Of course it's possible. You only need change the offset in batch file, e.g. the number after "split " command lines. Use the formula I show above to calculate.I forgot say some thing. That batch file use 32x32 pixel TGA for all MIP levels below 32x32.And in fact you don't need calculate again. Most value I have calculated in batch file for 512For example the batch file for make 512x512 trans DXT file split part is:split /b sig512.ace head0 0 60 ;get head before sign
split /b sig512.ace part1 140 131348 ;get rest head after sign
;and 512x512 MIP level data
split /b sig256.ace part2 268 33040 ;get 256x256 MIP level data
split /b sig128.ace part3 264 8460
split /b sig64.ace part4 260 2312
split /b sig32.ace part5 256 772split /b sig16.ace part6 772 904 ;get 16x16 MIP level from a 32x32 ace
split /b sig8.ace part7 904 940 ;get 8x8 MIP level from a 32x32 ace
split /b sig4.ace part8 940 952
split /b sig2.ace part9 952 966
split /b sig1.ace part10 966So a batch file for make 256x256 trans DXT file split part can be:split /b sig256.ace head0 0 60
split /b sig256.ace part1 140 33040
split /b sig128.ace part2 264 8460
split /b sig64.ace part3 260 2312
split /b sig32.ace part4 256 772split /b sig16.ace part5 772 904
split /b sig8.ace part6 904 940
split /b sig4.ace part7 940 952
split /b sig2.ace part8 952 966
split /b sig1.ace part9 966Only change the number of part,then change the copy /b line remove part10.
If you want to make a Zlib (Non-compress) file, it's same way to modify.

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

LAST EDITED ON Oct-21-04 AT 03:52 PM (EDT)

To all concerned with this problem:I know nothing of any of this, but have "discovered" this blank space behind the signals. I have not noticed it before, but now have since I've installed the Clinton Sub Route. Now, I have all my routes in individual folders, and have not checked out my other routes yet, but offer the following two screanies for your perusal. This is a "Flashing Yellow" signal. Notice the difference with the light on and off; the lone tree in the background disappears with the light ON!Maybe this will help in your troubleshooting.....dunno!

Attachments

http://www.train-sim.com/dcforum/User_files/417813730d61e9c6.jpg

http://www.train-sim.com/dcforum/User_files/417813870d998e60.jpg

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

If you read the first few messages in this thread you will see that this is a known bug in the modified siglight.ace. When the signal is on the forest region behind the .ace is blocked.Regards,Eric

Alert | IP

Printer-friendly page | Edit | Reply | Reply With Quote | Top

Ya, I was trying to wade through all that, but I didn't think this was a "forest" region, so thought I'd jump in. Guess I'd better get outta here while the gettin's good, eh?!

Alert | IP

[ Home | MSTS Forum | MSTS FAQ | How To... | File Library ] Copyright © 2004 by Nels Anderson. All Rights Reserved.