TGAtool2 - makeace pixel size reduction?

I've been going around this problem since before TGAtool2, wondering if anyone has a simpler solution. If I want to take a 512x512 pixel ace file and reduce it to 256x256, what I've been doing is opening a 256x256 image, then opening the 512x512 and reducing the size, copy and paste over the 256x256, then save and export as the same filename as the 512x512. Lot of screwing around, but if I try to do it directly it don't work.Here's the before, send the image and alpha to PSP-7, reduce image by 50% and save, now I got a 256x256 texture after reloading.After I export, when I open it again it's still 512x512, with the image cramped and tiled at the bottom.Anybody found a way to make this work correctly?

Alert | IP

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

RE: TGAtool2 - makeace pixel size reduction?, lenglel, Sep-27-03, 08:54 PM, (1) RE: TGAtool2 - makeace pixel size reduction?, Woozley, Sep-27-03, 09:06 PM, (2) RE: TGAtool2 - makeace pixel size reduction?, timken, Sep-27-03, 09:17 PM, (3) RE: TGAtool2 - makeace pixel size reduction?, lfriddle, Sep-27-03, 09:38 PM, (4) RE: TGAtool2 - makeace pixel size reduction?, lfriddle, Sep-27-03, 09:47 PM, (5) RE: TGAtool2 - makeace pixel size reduction?, sniper297, Sep-28-03, 00:29 AM, (6) RE: TGAtool2 - makeace pixel size reduction?, MartinW, Sep-29-03, 10:44 AM, (7) RE: TGAtool2 - makeace pixel size reduction?, lfriddle, Sep-29-03, 08:49 PM, (8) RE: TGAtool2 - makeace pixel size reduction?, sniper297, Sep-30-03, 08:52 AM, (9) Can you tell the difference?, lenglel, Sep-30-03, 09:46 AM, (10) RE: Can you tell the difference?, oldiedaddy, Sep-30-03, 12:37 PM, (11) Can you tell the difference? (Tree shrinking!), pvoxland, Sep-30-03, 01:05 PM, (12) RE: Can you tell the difference? (Tree shrinking!), oldiedaddy, Sep-30-03, 04:31 PM, (13) RE: Can you tell the difference? (Tree shrinking!), sniper297, Sep-30-03, 08:19 PM, (15) RE: Can you tell the difference? (Seasonal Trees), pvoxland, Oct-01-03, 00:00 AM, (17) RE: TGAtool2 - makeace pixel size reduction?, MartinW, Sep-30-03, 07:57 PM, (14) RE: TGAtool2 - makeace pixel size reduction?, sniper297, Sep-30-03, 08:27 PM, (16) RE: TGAtool2 - makeace pixel size reduction?, MikeSimpson, Oct-01-03, 01:50 AM, (18)

Conferences | Topics | Previous Topic | Next Topic

Not sure, but don't you also have to resize the alpha channel
seperately from the graphic?
Lloyd

Alert | IP

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

LAST EDITED ON Sep-27-03 AT 09:08 PM (EDT)

In my experience non-alpha ace's work fine for resize, but anything with alpha gets corrupted on resize after you export it; so the long hand method of saving via a TGA must be used for alpha texturesTGAtool bug ? (edit: typo)

Alert | IP

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

Jim, after much experimenting, a long time ago in a far off galaxy.................I came up with the same method! Nothing else was easier, at least that I tried.

Steve T.

Alert | IP

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

I use Photoshop. It has an image re-size command. Once TGATool2 sends it to Photoshop I click Image and then Image_Resize and then change the Image size to 256x256, save and reload the change into TGATool. It also has several options on how the pixel color interpolation is done but I have always used the default bicubic. Works fine with the alpha too. I would think that paintshop would have a similar command someplace.Larry

Alert | IP

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

Also, have you tried Image Format Converter (convim.exe) from the same website that has TGATool2? It has a checkbox to convert the image size, but I haven't tried it.Larry

Alert | IP

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

Nope, tried the bicubic resample, same thing. On flat bitmaps either one works fine, anything with an alpha is a problem. I do send the alpha to the editor and reduce that by 50%, but since the main image is what gets clamped down to the bottom quarter, it's impossible to tell if the alpha is affected or not. I'll take a look at convim.exe, see if that makes a difference. I did shoot an email off to Martin, but since it's the wee small hours of tommorrow morning over in England I expect we'll hear back from him minyana.

Alert | IP

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

TgaTool2 was never designed to cope with images resized while in the editor.
That it may work in some cases is more by accident than design. Whatever happens you always need to have the alpha the same size (if the image has alpha) to avoid wierd things happening.If you have a paint program that fully supports Targa 32 with alpha (such as PSP or Photoshop) then the best method is to save the texture from TgaTool2 as Targa and then use the paint program directly to load and resize the targa (which can then be loaded into TgaTool2 again).If your paint program isn`t targa-supporting then you can get similar results by loading the Targa into my DXTBmp program. This *will* let you resize the image and alpha in your editor, reload and then save a new targa file.ConvIm is not really suitable as it has very limited alpha support. It would resize a Targa file but the alpha would be lost in the process (or rather it would be converted to a blank, fully opaque, alpha channel). It will also convert directly to Ace DXT1 (with resizing if selected) but in this case it uses a simple "black = transparent" system to generate the alpha so results may not be what you intended...

Alert | IP

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

Thanks for the info Martin. You have a great bunch of utilities. I really appreciate you making them available as freeware.Larry

Alert | IP

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

Second the motion, he's got the "Wright stuff"! Without TGAtool2 to work with, some projects were extremely difficult, most were impossible.And thanks for the confirmation, Martin, I like to do things speedy assembly line style, but apparently image size reduction can't be done that way. I thought maybe I was missing something.1. Open the ace in TGAtool2, save as .tga.
2. Open .tga in PSP-7, reduce size, save.
3. Open .tga with TGAtool2, export.One odd thing I found in this, MSTS wants even multiples of 64. 512 pixels, 256, 128, 64 are OK, but 96, 192, and 384 are not. All are evenly divisible by 16, but the odd sizes (A) are actually larger in kB:512 - 171kB
384 - 272kB
256 - 43kB
192 - 71kB
128 - 11kB
96 - 19kB
64 - 3kBThat's for -Trans with DXT compression, and (B), the odd sizes don't show up in the route editor! I know I remember doing some odd sizes once, trying to split the difference between 512x512 and 256x256, possibly that was a flat (no alpha) ace file.Anyway, fiddling with Phil's backdrop trees, I copied one image and exported as the 256 pixel ace file:One of those backdrops is the original 171kB 512x512 texture, the other is a 43kB 256x256 texture. If I can't tell the difference, then it don't count as quality loss!

Alert | IP

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

I'm saying the one on the left is the original,
and the right is the smaller .ace file. Anyone
want to make any bets before sniper tells us?
Lloyd

Alert | IP

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

I'd set on the opposite, 256 left, 512 right.
Will need magnifying glass to decide.
As Jim says, if you can't see the difference, it's more than good enough !
In other cases you will clearly loose quality, specially for textures assigned to large areas (bridge decks, large streets, tall buildings close to the camera).Well Jim, you got it:
Save as RESIZE.TGA, open with PSP, resize to 50% (my default), save, load TGA from TGATool2, export.
Resizes anything without any prob, except 2bit Trans which you sometimes need to reduce to 2 colors again, I use PSP's color replacer with white/white-tolerance 102 then black/black-tolerance 102.Nobody said the size must be dividable by 16.
Must be a power of 2:
2? 4? 16 32 64 128 512 (1024)Love and Peace

OldieDaddy from Alsace

Visit also www.the-train.de !

Alert | IP

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

LAST EDITED ON Sep-30-03 AT 01:07 PM (EDT)

My idea was that the larger textures would look better if the tree lines (or individual trees, for that matter) were placed close to the tracks. However it may be that there is so much variation anyway from one pixel to another that smaller textures work just about as well. Since most of the time the trains are in motion anyway, what's a little fuzziness or reduction in detail going to do to the look of the forest anyway? There might be another side benefit to smaller textures, and that is that tendency of pixels at a distance to change ("shimmer"?) as the distance between the train and the textured object changes. Having fewer pixels to twinkle might reduce the shimmer? Do smaller textures improve on frame rates? Fall colors are spreading over the north woods of Minnesota where I took most of the photos. -- Phil VoxlandP.S. That test screen grab looks like the tracks are passing through a field of Ultra Golden Grahams. (My late night snack of choice).

Alert | IP

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

Hi Phil !
Good to see ya here !Wow, are we getting flaming fall textures soon ?
I mean real pictures of yours, as we've already tweaked a few, they will be in 'StadtbahnU79' soon .Well, as your great pics are VERY sharp, 256*256 is NEARLY as good.
Close to tracks, 512 will definitely look a lot better, avoiding large pixel areas.
And yes, I believe that larger textures call on CPU resources, i.e. framerates. And route compacting, of course.Will small texture sizes shimmer less ?
Don't think so. Small bushes/clumps flash more than anything else.
Shimmering seems to be driven by:
-proximity to ground terrain (superposing textures/transparencies ?)
-Mip levels ?
-'griddy' patterns in the pics/trans
-shape file settings (As Kujukluwns did not hand out the 'rules' of the graphic game, enough work to experiment & fine tune for months...)Your PV trees are not a big issue, nor are Judd's RealPines.As often in real trial & error life, just a matter of finding the optimal settings, size/quality balance...
Hope you will find the right day/light/mood in Minnesota to astonish the rest of the world with autumn/winter/wintersnow/spring sceneries !
THANKS for your superb contributions !Love and Peace

OldieDaddy from Alsace

Visit also www.the-train.de !

Alert | IP

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

Hmm, I went and deleted the test, but I think oldiedaddy was correct. Or maybe not, now I can't remember. "Do smaller textures make better framerates", I dunno, after two years I think my chances of figuring out the secret to better framerates in MSTS are about the same as Da Bears chances of going to the Superbowl this year.It's logical when you stop to think about it tho, if I have 1000 different objects on a tile and they're all 171kB, that's 171,000kB that needs to be loaded from disk to RAM, then transferred to video RAM, when the sim loads that tile. Given 1 meg per second transfer, that's 2/10ths of a second, or long enough for the screen to redraw 3 to 6 times. 43,000kB would theoretically load and process in one quarter the time. In a battle of milliseconds, it should (theoretically!) all add up to less stuttering.Forest regions revisited;The smaller the forest region object, the more can be packed into a given area. Those weeds are 2.5 meters across and 3.5 meters high, and packed as densely as they'll go, something like 99,999. Looks but really tanks the framerates, going from Anderson to CPR Malice on PO&N6 I get a lot of video stuttering with drops to 8FPS, and average something like 12-15FPS with a max of 20 on that section.After using Phil's backdrops with narrow forest regions (stretched out in length but leave the default width) in front of them, maximum 1111 to 2222 for density, I was getting 35-40FPS on the same stretch. After adding the weeds, even with only densities of 9999, I dropped to 20FPS.So I started experimenting with larger weeds.Those are 16 meters wide and 8 meters high, with a max density of 1111 to 2222 just like the trees. They don't look quite as realistic, but since they do look pretty good from most angles and I'm getting 30-40FPS over that section, I'm continuing that experiment.

Alert | IP

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

Thank you so much for the kind comments and encouragement! I really must not promise anything about specific trees and seasonal varieties. I must say that what I have put up in the library are items which I have (selfishly) created for my own much-too-large route. I have still so many miles to plant trees and forests, that I have trouble even thinking about seasonal variations. From your samples, it is clear that you have mastered the art of tree modifications already, I compliment you upon those. If you will permit some suggestions, the popaut and birchaut trees you show are excellent, but those orange fall colors are much more typical of other trees, for example maple or elms? I thnk they deserve to be used in the program, howver. A birch or poplar, in a good fall year will be more of a yellow. This fall has been very dry throughout Minnesota, and trees, as well as farm crops are suffering, and it shows. While normally fall trees can be spectacularly colorful, it seems that this year those trees will be a very subdued or "unsaturated" color. Beautiful in a different way, certainly. There is a variety of Maple tree, that can become an almost unbelievable red. I think in the train simulator it would look unnatural. In a bad year as this is for those Maples, they will not be so brilliant. The Tamarac is a very unusual tree. It's needles will become a very golden yellow in the fall and then, almost suddenly, all the needles fall from the tree and through the winter and early spring the tree is almost a dead looking skeleton. It would be very difficult to model the winter Tamarac because the branches become very thin. (Another side-thought) I hardly understand why MSTS at this early stage has something like an Autumn/Snow variation in it's seasonal choices. Autumn colors are rather short to last, and while snow is a possiblity in Autumn, it is apt to melt quickly. So it's good for postcard pictures but not as a lasting landscape. This doesn't have a lot to do with shrinking pixels and textures, which was the orginal topic! Again thanks to Oldiedaddy and Sniper***'s wonderful variations on the trees and treelines I put together a while ago.-- Phil Voxland

Alert | IP

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

Sniper...The reason the "odd" sizes come out larger than the power-of-2 ones is because DXT1 can only be used on the latter. Odd sizes wil be created as normal 32 bit or 24 bit Ace and even with zlib compression these will usually be larger than a bigger DXT1 texture.The only sizes that can be used with DXT1 are 4, 8, 16, 32, 64, 128 and 512. And of course these must be square images.I assume that the route editor will only display DXT1 textures so that would be why the odd sizes aren`t appearing.

Alert | IP

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

You forgot 256. Yeah, it's wierd, I thought I remembered making a 196 texture, coulda been a terrtex. For whatever reason the odd sizes don't show up in the RE, I didn't look to see what they looked like in the sim. No point, if the objective is to make the file sizes smaller then the odd sizes are no good anyway.

Alert | IP

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

Hi Jim,With regard to speed of loading of textures, Martin Wright sent me the following in an email recently which explains the matter very wellquote
It is noticeable that in the default routes virtually all the scenery
textures (and ALL the terrain textures) are in DXT format right from the
start.
This is partly space considerations but is much more related to performance.
Rendering large areas of terrain with loads of trees and objects can be done
much more efficiently with DXT textures because they require only nominal
changes during loading to convert them to true DirectX format which is
hardware-supported on most modern graphics cards.
unquoteI have now added a couple of options to Route-Riter to help with file compression.
1. 'Copy ACE no Alpha' will check all the .ace files in a selected folder and copy those without an Alpha channel to a temporary folder where they can be easily converted to DXT1 using ConvIm.exe in a single operation.
2. 'List .ACE Types' produces a report on all the selected .ACE files giving the filename - filetype e.g. mytexture.ace - 24 bit + trans.
This allows you to quickly print off a list of files and see which ones you need to convert to DXT1 without having to load each one individually into TGATools2.Route-Riter v4.2.29 will be on my http://members.optusnet.com.au/virtualtrains site this afternoon (this will be a .exe and help file only).Mike

Alert | IP

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