voidhawk

Are you looking for just the grass tiles, or all the various terrain tiles? Without having tried doing any terrain mods, it is not clear to me how the annotated textures would be of help here, as there does not seem to be any complicated 3-d wrapping going on. Isn't there simply 1 texture per tile (except for grass?) Perhaps I am missing something? Anyway, if you think they would be helpful, I can certainly take a stab at it.

Hmm, after thinking a bit more about it, I suppose if one wanted to mix and match actual winter textures with the annotated ones, the re-naming of the annotated texture files would be the way to go.

<blockquote>quote:</font><hr> wow, another good part is you can have a WINTER annotated set by simply adding a "1" in front of each of the summer bmp's! <hr></blockquote> I presume you are joking, right? I didn't see a smily though... [if you are still wondering, there is no point in doing winter textures of course - unless you prefer a "snowy" to a "whitewashed" version ]

Neo???

<blockquote>quote:</font><hr> I don't do vehicles, but damn, that's a good idea! <hr></blockquote> JuJu - if you want something else done like this, just let me know, and I can make another zip file.

<blockquote>quote:</font><hr> Btw, please tell me you used some sort of batch automation for all those .bmp's! <hr></blockquote> Yes; a combination of Shell, Awk and the netpbm graphics programs. See also the "Comments" section on the web page itself: Voidhawk's Annotated Textures for CB:BO

Re: useful for CB:BB All I'd need would be a list of the file names and the corresponding texture dimensions, and I could do it in a day or so; I wouldn't even need access to the actual textures. Thanks for all your positive comments!

Ever wondered what texture maps make up a specific unit, or how they are actually mapped to the underlying 3-d model? Well, an easy way to find out is to use the annotated textures illustrated here. They are of the same resolution as the original ones supplied with the game, but contain checkerboard-patterned, colour-coded, annotated textures instead of the actual game textures - see the images below for some examples. The 16x16 background pattern allows for convenient observation of where textures meet, how they are draped over the model, and how much scaling occurs when mapped to the model. The consistent colour scheme (based on the last digit 0-9 of the file name) can be used to figure out a texture's number if the actual number happens to be partly or wholly obscured. For instance: For more sample images, and a small zip file containing all vehicle and gun textures, see: Voidhawk's Annotated Textures for CM:BO

<blockquote>quote:</font><hr> > How about some scenarios utilizing it? <hr></blockquote> Doesn't the game CD's "The Sunken Lane" use a diagonal map?

Gyrene, Very nice - love the detail on the switches too! Hmm, perhaps a little darker than I was expecting, even from looking at the real-life photos, but very nice overall. The narrower track gauge look much more to scale too. The hi-res files are OK; can't open any of the lo-res bmp files on my Windows machine though.

Michael - I agree with your analysis about the purpose of a tapered bore; mine does seem a little shaky... Hey, but what about the cold fingers of the gunner?

Then again, the Littlejohn adapter actually has holes in the barrel to allow the gas to escape...it used a special projectile too. So, perhaps not relevant at all. Now back to your scheduled programing...

Reduced gas leakage. I seem to remember there were guns with a tapered bore (tapering to a smaller diameter) that, in conjunction with a "softer" projectile base, would increase the muzzle velocity. Can't quite remember what they were called, but "squeeze gun" comes to mind. I'd expect it to play havoc with barrel life though. Ah hah - found a link - for instance, see the following for the "Littlejohn" 40mm gun taper bore adapter: http://www.users.globalnet.co.uk/~autogun/sgun.htm

Getting a little off-topic, some interesting links below for some examples of effects of cold temperatures on steel: http://www.disastercity.com/titanic/index.shtml http://www.cts.umn.edu/T2/TechExch/2001/julsept/hoan.html

<blockquote>quote:</font><hr> I have seen statistics on Russian test of steel APFSDS where penetration went down up to 20% when the rod was cooled to -20 degrees. <hr></blockquote> Wonder if they cooled the target down to the same temperature too? Steel gets more brittle with lower temperatures, so you'd expect that to apply to the target too. Another effect to consider is the shrinking of a gun barrel's internal diameter as it gets colder, thus "squeezing" the shot more, and thus increasing its muzzle velocity. I'd imagine the gun barrel would heat up pretty quickly after a couple (few?) shots though.

As much as I like mods (and this new one too), perhaps a plug for the thread I started a week ago or so regarding mod texture sizes getting out of proportion to their actual use is in order: http://www.battlefront.com/cgi-bin/bbs/ultimatebb.cgi?ubb=get_topic&f=1&t=022092

Track gauges are exactly the same in Britain, France, Germany, and indeed, most of the rest of the world. Exceptions are parts of Spain and Russia, amongst others. What is different though is what is called the "loading gauge", which is mainly determined by the size of tunnels and how far the platform edges stick out. See this link for a good (modern day) comparison: http://www.crowsnest.co.uk/gauge.htm Still waiting for a train mod...

<blockquote>quote:</font><hr> I have noticed a large map scenario with a lot of units will cause the resolution of my graphics to drop - sometimes considerably! A tank or a building that's sharp as a tack on a small map will get muddy and fuzzy on a large map. <hr></blockquote> What kind of graphics card are you using?

Yes, performance is one aspect, and as you say, as long as there are not too many units involved, the performance impact of a couple of hi-res mods may be overshadowed by the effects of the terrain and building textures. However, some graphics cards (such as the Voodoo 3) can't even handle textures greater than 256x256 from what I gather. Now...I used to have a V3, and although some of the textures (such as the sky) are larger than this limit, they were still displayed...which leaves me a little puzzled. Perhaps the V3 driver simply scaled down the texture itself (by discarding pixels rather than interpolating?) Anyway, it would still still seem like a good idea to be able to scale down textures on the fly using a tool such as CMMOS. As for the W9* implementation of my program...that could be a while as I do not have a W9* development environment - but I'd be happy to supply my algorithm to anybody who wants to turn it into a W9* program that operates on bmp files.

You mean there are actually other games? - voidhawk

I reali[sz]e that texture size has nothing to do with the size of the screen display - what I said was that the extra detail that is possible in the larger textures is only visible if the object in question occupies the same, or larger, number of bits on the screen. For instance, a texture that is 512 bits wide will not show any more detail than a 256 bit texture when the texture is mapped to an object on the screen that is only 256 screen pixels wide. Textures can be scaled down without getting pink edges by handling samples containing the transparant color in a special fashion (majority rule), as I did with my own "halving" program. No more pink edges, and transparancy is preserved. Sure, object will look a little more blurry when viewed close up (see constraint above), but there is a memory cost associated with the larger textures. A texture 3 times the linear dimensions of the original will use 9 times as much (video card) memory; 4 times as large results in 16 times the memory use! As an experiment I swapped my bmp directory to such a "halved" (i.e. only textures that were bigger than the ones that came with the game were halved in linear dimensions) directory. And guess what - it still looked pretty good. Sure, there was some blurring visible on levels 1 and 2, but not on 3 and beyond. This suggests that hi-res textures are not needed for typical views - and that is why other 3D applications use MIP mapping for performance reasons - but at the expense of memory (as now both large and small textures have to be stored.) Anyway, that is not the issue here, and CM does not use MIP mapping as far as I can tell. As I said at the start, I love those hi-res mods too, but not everybody can run with them, and it is worth keeping that in mind with all these very nice hi-res only CMMOS mods coming out.

Optimistic bump for the daytime crowd...

That sounds like a good idea - perhaps even as some kind of "global" option, e.g. just for files that are larger than a certain size. When I made the reduced-resolution copy of the bmp directory myself, I wrote a script that for each of my current bmp files, found what the corresponding "CM original" bmp size was (not a trivial problem), and then only scaled-down the ones that had a larger resolution than the original ones (and met some other criteria, to avoid scaling down improved buttons etc.) CMMOS would not know what the "expected" texture resolutions would be, and thus some other heuristic would have to be used for scaling textures on the fly, as there is not that much to be gained by scaling down the smaller textures. voidhawk

OK, so before being flamed to death, let me state right up front that I love all those mods as much as any other mod slut - and I have 542M worth of files in my bmp folder to prove it! But...I have to wonder, do we really need all mods to be of 512x256 resolution? For instance, the recent set of (very nice looking) bunker textures, and the older sets of Jeep and Kubelwagen textures all use this size for their "main" textures. But think about that - at a typical screen resolution of 1024x768, the object in question would have to fill more than half the screen before pixellation would become noticable. How often do you get that close to (say) a jeep? What I am proposing (flak jacket on) is that the textures sizes of mods are kept a little more in proportion to the size - and importance - of the object in question. After all, a jeep is only half the size of a tank, so why use the same texture size? (Sorry to keep going on about the jeep; I do like the mod - but I've scaled it down, see below) Even though I'm running what I think is a pretty much up-to-date system as far as CPU and graphics card is concerned, I find myself scaling down such large textures just to keep the frame rate up a bit (I run with FSAA on.) And guess what - for all intents and purposes, the end result is indistinguishable from the original, but uses only one quarter of the memory! On a side note, I wrote a small C program that halves a texture file while correctly maintaining transparancy as part of an effort to provide a "lo-res" copy of my high-res bmp directory for somebody else who is limited to smaller textures sizes on a V3-based system. I found there were a number of files that used values other than ff/00/ff (or fe/00/fe) for transparancy, and thus originally "broke" my halving program. It seems that CM can actually cope with values that are at least a little more off from the nominal values above; check out the holes in the "damaged" Pnz IV skirts (3106.bmp) or around the MG mount of the hi-res jeep (3640.bmp) for some typical values. Question: does anybody know what the actual allowable range is? I could experiment, but I'm so busy as it is... If there is interest I can make my "halving" C program available either here (it is small) or via some other mechanism; it operates on ppm files so some extra work is required to convert from bmp into ppm and then back again; I do all this on Linux. As a second side note, in order to possibly quantify the effect of texture sizes on performance, does anybody know of a utility that shows how much of the texture memory of a graphics card is actually being used, and/or how much is being swapped in and out over the bus? CMMOS could even be used to select between lo and hi-res texture sets...we'd need a naming convention for that though..."_lr", "_hr"? Such a selection mechanism might work well for objects that have a limited number of textures, such that the size of a CMMOS package would not become too big if it included both lo and hi res textures...just a though. I'll hide under my desk now. :eek: voidhawk

Gyrene, Turns out we are both right - the tops of the tracks can look either shiny or dark, depending on how the light falls on them - the difference can sometimes be seen even in the same photo for parallel tracks. The link below (found at random on the web) has many pictures showing ballast and track under various lighting conditions; all heavily used track. Note how dark the ballast is most of the time - and this is all well-maintained track. http://www.newble.co.uk/nl/railthumbs.html I look forward to seeing the new track set! voidhawk