Special Aircraft Service
Individual Mods and Packs for IL-2 1946 => Skins, Maps, Missions & Campaigns => MapWorx (Common) => Topic started by: StG77_HaDeS on June 10, 2010, 05:39:05 AM
-
Hello all, :)
I hope Bombsaway will tolerate this little "reminder" :)
So guys you should always remember that:
When you do a map do Not Forget that for every single texture you make that does NOT have alpha-layers you Have to make it 8bit. And this applies to the map files as well like:
map_f.tga, ed_map.tga, etc, except those who are gray-scale files and the map_r.tga .
I have seen very nice maps, and this also applies to cockpits up to an extend, that are almost unplayable due to many 24bit textures that degrade performance so much.
-
This also has the benefit of reducing by a factor of 4 the size of your map files (easier for people to download, takes up less space on the HD) makes maps load faster in the FMB, in addition to using less memory when in game. In Gimp, set >image>mode>indexed with palette of 255 colors for all your textures and ed_maps.
Thanks, HaDes.
-
Dont worry Hades, I never take offence to stuff like this:) Thanks for the tip. :)
-
Bonus is that 8bit terrain textures appear sharper at greater distance ;)
Cheers, Neil :)
-
Just reading this now
This is what I do with textures that do not have alpha channels in them.
I make them 1024x1024 adjust colouring etc then index them.
8 bit I have seen something like this in Photoshop but nothing like this in Gimp.
Is the above ok or not?
Cheers Kirby
-
From what I've seen, original game tex are usually 512x512 for the *.tgb's and 256x256 for *.tga's.
1024x1024 can be used "sparingly" (for drawn airfields) but only if used for *.tgb and only if 512x512 is supplied as *.tga all in 8bit of course ;)
The use of Zuti's friction mod also helps to by removing the load from using so many airfield plates.
Cheers, Neil :)
-
I'm getting a bit confused.
I know that normally, in older maps and such textures were 512 ... then some time ago, when new maps started appearing, made by modders, especially winter textured maps, 1024 textures were suddenly in use and heralded as being far superior in graphic detail to 512 textures ...
Since, I think it's been almost standard to make maps in 1024 textures ...
But, what's the best solution graphically? 512 or 1024 textures? Do 1024 texture supply more detail than 512 or is it immaterial?
I'm not asking about loading times for maps or downloading times for links, obviously the 512 textures will make the files smaller. But that is not a primary concern I think. If you want a good mod, well then, the difference between a 40mb or 60mb download should be immaterial ...
I'm just asking about how maps look in game. Which gives most detail and better looking maps: 512 or 1024 textures?
-
I would go for Game's native resolution 512 and 256. I have made the 352nd's map to use 512 and 256 size textures in my install. I am satisfied so far. In next UP maybe we will get these maps to have 512 and 256 textures. and maybe it would be wise to redo all the textures to these sizes.
-
I would go for Game's native resolution 512 and 256.
I just resized the textures for a map from 1024 into 512 and at first sight there does not seem to be much difference ... both 1024 and 512 texture versions look more or less similar. But I do say at first glance, since I've obviously not had that much time to redo a number of maps to compare ... only one so far, but it did come as a surprise, and this puts things into a bit of confusion.
And ... when making maps this is an important point, as making 512 textures from GE is ever so much easier than making 1024 textures. Since textures are usually made from screencaps of satellite images, it is much more difficult to find suitable areas for a 1024 texture, which encompasses 4 times more land area than a 512 texture ... and is therefore so much more likely to contain disharmonious or unsuitable elements ...
So it would useful to try and find a general consensus on this - are 512 textures just as good as 1024 textures graphically?
-
Yeap. the 512 are as good as the 1024, remember game's engine is made for 512s textures so any higher than this it basically ruins performance and does not add to the "beauty" of the map.
So yes people, 512 and 256 resolution for textures is the way to go. And Canon can also make his textures-plates to 512/256 and gain significant in performance ;)
-
I was doing my textures at 512 but was gonna resize to 1024 so thanks for the advice you may have saved me a lot of work
-
I use a 1024 tex each for 3 airfields and 1 city. All are 8bit and saved as 'texname'.tgb. A 512 tex is also saved as 8bit and named 'texname'.tga. These are mapped once over a large area, not tiled repeatedly over and over.
All the rest of the tex for my map are 512, 8bit for the 'texname'.tgb and 256, 8bit for the 'texname'.tga :)
Cheers, Neil :)
-
These are mapped once over a large area, not tiled repeatedly over and over.
I'm trying to understand what is meant by that ... what do you mean by 'mapping once'?
-
I,m intrigued as well..... is this a technique that we're missing?
-
I'm trying to understand what is meant by that ... what do you mean by 'mapping once'?
Like this....
(https://www.sas1946.rocks/images/imageshit/img704/4343/cityq.jpg) (https://www.sas1946.rocks/images/imageshit/download/704/cityq.jpg)
Cheers, Neil :)
-
Neil it's not clear from the pic what you mean!
Till then
I advocate a bit for the 1024 textures:
The difference between 1024 and 512 textures:
1024 covers 1600 meter x 1600 meter in game
512 covers 800 meter x 800 meter in game
So if you use 512 the repetitive pattern will be more easily visible than for the 1024 ones, or in other words you need to be more careful about doing the 512 texture in order to avoid the tiling effect..
-
The performance gain is very importand and the 512x512 textures are the way to go.
If we need a standard then the native 512x512 is the way to go.
And yes map makes should be careful and aware about the "tiling effect".
-
To make it even more confusing: I noticed that the Korea map by Checkyersix has all kind of textures: 512x512, 1024x1024, 8-bits, 24-bits, 32-bits, 1mb, 3mb and even 4mb. I don't know the reason of all this different files as I'm not a mapmaker but I don't have a decrease of performance on my midrange system fortunately.
-
Sorry Lowfighter I haven't seen your reply until now :(
I guess what I mean is that the large texture is not used over the whole map. It is used once over a single area and nowhere else. Also a lower res version of the tex is supplied so that at further distance the lower res tex is used by the game.
@Hades.. The large tex is necessary in this case as it is mapped over a large area (city/airfield) where as a smaller size texture is just to blurry for this type of application.
I have created the map with much attention paid to economy as I only have an old P4 based machine. These textures are reduced to 8bit and the smaller sub-texture is also supplied. As it is a little over 1Mb in size I believe this is quite acceptable :) If there is a performance hit I certainly would have noticed it and wouldn't have used it. ;)
Cheers, Neil :)
-
In my experience map textures size is not so important. If it is done properly every textures can be 1024x1024 and there would be no problem. 512x512 are overall blurry and looking not so convincing in game.
But for that, every texture must be indexed. There is no problem if you have 20 textures with size 1024x1024 if they are indexed, that's only some 20Mbs of memory space. Which really is nothing. If they are not indexed, it could go up to the fourth times that, some 80-100Mbs, and that's a bit "heavy" for the game's engine. If you see 1000 squares in game covered with those 20 textures, its still 20, not 1000, the game repeats them, it will take place for just 20 of them in the memory.
On some weaker machines game is stuttering because graphic card can't do anisotropic filtering (so, its good to disable that on lap tops), and not because of big texture sizes.
@ lowfighter
With due respect, I think that you made a mistake. One square (or one pixel) in map_t, is always covering area of 1600x1600 meters in game if there is no multiplier number at the end of textures slot in load.ini file. For example:
LowLand2 = NTL_/land/summer/NTL_Darwin_Small/NTL_Darwin_Small_burmascrub.tga
Would be 1600x1600 meters.
LowLand2 = NTL_/land/summer/NTL_Darwin_Small/NTL_Darwin_Small_burmascrub.tga,2
Would be 800x800 meters.
LowLand2 = NTL_/land/summer/NTL_Darwin_Small/NTL_Darwin_Small_burmascrub.tga,4
Would be 400x400 meters.
LowLand2 = NTL_/land/summer/NTL_Darwin_Small/NTL_Darwin_Small_burmascrub.tga,8
Would be 200x200 meters (and there is no greater number than 8 )
That means that textures covers "whole square" (in 1600x1600), only quarter of square (in 800x800) and so on. In that way you get better and sharper looking texture, but because the rest of that particular square (or pixel in map_t) is covered with that same texture in that same size (2, 4, or 8 ) tilling is more visible.
You can also add "-" sign at the end of the texture slot. In that way you would have less tilling look, but also more blurry look of the texture in game, because texture is made bigger than one square in map_t.
For example:
AirField3= NTL_/land/summer/NTL_Darwin_Small/NTL_Darwin_Small_DarwinAF.tga,-2
Means that texture is fourth times bigger (not 2 times because we are talking about square meters here) than square or pixel in map_t and in game, it is also showing only one quarter of the texture for one pixel in map_t (which would be one square in game).
In my experience it is best to make originally textures which would really cover 1600x1600 meters. In example if the texture is made from the Google Earth images, scale it down to the real earthly 1600x1600 meters and then take it. There is a liner tool in Google Earth to measure that.
Thats how I see that.
Examples:
(https://www.sas1946.rocks/images/imageshit/dead/dead.gif)
(https://www.sas1946.rocks/images/imageshit/dead/dead.gif)
-
Interesting stuff Avala. I found using 1024 textures on my Netherlands map hardly slows my 5 year old pc down (even while those textures are not indexed yet, as I am still tweaking them). But they look way better than the 512 ones for sure!
(http://www.marcelboonstra.nl/michel/01.11.2010%2017-10-22.jpg)
-
I remain confused about what I'm reading here...
I was used to believe that:
1-The area covered by a single tex.tile is NOT dependant by the resolution of the picture but by the parameter at the end of of the line in the load.ini (nothing, -4, -2, 2, 4, 8)
2-1024x1024 pictures combined with the parameter 4 in the load.ini in some texture slots (city & airfield for example) gives a more detailed result than 512x512 & 256x256 pictures.
3-Alpha channel in some pictures (32bits texs) is used to control the way 2 different tiles mix together when they are next to each other (optionnal feature I suppose) .
4-Alpha channel (32b. texs) is MANDATORY is some specific texs like TREES : without transparency, the automatic trees appear like plain rectangular boxes.
Do you agree with that ?
-
We're now about 2 years on and starting to use 2048 textures now in many maps. So far, these have been 32 bit/RGB files (not indexed).
So how does this thread apply to the new upcoming texture norm?
-
Dear SAS MapWorx gurus,
I have a desert map I'd like to donate to SAS.
Not quite finished - but possibly never will be. It's been fun for years - but seems I"ll be done before it is!!
However, I first need to know if it's acceptable to you, in its current form.
eg I'm not sure about this:
"There is no problem if you have 20 textures with size 1024x1024 if they are indexed"
What does "indexed" mean? [I'm using GIMP]
Also, how do I check if the images are 8 bit?
[That said- this map currently causes no problems on my old, slow computer. its a desert - there are no towns!]
Finally: does SAS allow textures made from "google earth" screen grabs?
F_F