MTM2.com

I did some testing recently and discovered that 256x256 terrain textures don't align seamlessly in the game. It's probably a bad idea to use 256x256's for terrain because it'll cause considerable chugging, but I wanted to find out what was going on. So, after some time, I found that the game treats 256x256's with an 8 pixel overlap. A traxx paste using 256x256 does not work properly. To succeed you'd have to go back to the winterkill torture exercises, theorize a Slice240 and manually swap eight pixel edges. Ground boxes do not treat 256x256 the same as terrain. I have not tried to figure that out, and don't plan on it in the near future.

And there you have it. I post for the sake of noting the info. I don't really anticipate anybody confirming this any time soon.

It's funny seeing this, as I've been wanting to ask about it here for years, "what would the pixel overlap be for 256x256 textures?". Every time I thought about it I would try to think mathematically, but maths make my brain hurt. I never tried to approach the solution by making a test texture until seeing this posting (I didn't have any pressing needs when thinking about it before).

You already gave the answer of course (240/8), but I confirmed it.


<img src=/~trackville/pics/256mtm2.gif>

^ I created a texture with a series of one pixel lines, starting with white, as depicted on the left, a shot from mtm2 is on the right.


<img src=http://mtm2.com/~trackville/pics/256gb.gif>

^ The same texture on a groundbox shows clear to the edge, confirming that "ground boxes do not treat 256x256 the same as terrain". Yet I'm almost certain GBs 'wrap' 64x64 textures.


<img src=/~trackville/pics/256wake.jpg>

^ Here I swapped my 64x64 cobblestone texture (60x60 core) with a 256x256 texture (240x240 core), to see how it would look as far as seamlessness goes. Looks good, 240/8 works. My source texture was 200x200, so it resized up better than it did down.

Yes, ground boxes are definitely different. I remember asking about the overlap before too but then and now I don't recall 64x64 seams on them.

So, the thing that remains is, what happens to the 1-7 pixels? Can that stripe be ignored? Do we really need overlap or can we discard the 'slack'?

Whoa Wint. That looks awsome. It's like.... we're not playing MTM2 but a game with a more recent graphics engine

------------------
"In my restless dreams, I see that town, Silent Hill..." - Mary, Silent Hill 2

> what happens to the 1-7 pixels?

I think they end up on a computer screen somewhere in Europe.


> Do we really need overlap or can we discard the 'slack'?

You can hide secret text messages there.


> That looks awsome.

Gotta love photo-textures.

> what happens to the 1-7 pixels?

I think they end up on a computer screen somewhere in Europe.


I can confirm that WK, they end up at my PC ;-))

Is this a conjecture, or did someone (Winterkill & Phin, can you hear me?) test game performance of a track made with 256x256 textures?

For a modern 3Dcard this should not be a problem: 512 textures just use 32 megs. But the graphics engine within MTM2 may not have been designed for such amounts of memory.

While we're on the 256 subject: did anybody experiment with backdrops made of 16 256x256 textures?

it hink someone said that when you hsave antialiasing on and some different types of graphics that they bleed in. he had green where the overlap was and it usually didnt show any green but then with certain graphics it did show some faint green between textures.

yea here it is: no one seems to have taken notice other than i:
a note on overlap with anitaliasing
http://forum.mtm2.com/viewtopic.php?t=2319

> Is this a conjecture

Yes and no. Yes, because I don't think anybody has made a track entirely with 256x256 terrain textures. No, because tracks made using excessive numbers of 256x256 model textures have poor performance. Consider the undeniable beta - if you saw it. Also, stock tracks run with custom trucks using excessive 256x256 textures have a similar effect. I'm sure we can dig up samples if you need them.

> For a modern 3Dcard this should not be a problem

First, yes, your math is correct (256*256*512=32768). As far as I can tell, the system demands made by games like evo come almost entirely from high volume large textures. And yes it's true that mtm2 is not as efficient as it could be if it were made today. I think the problem is not such much the memory, but the processing required to render them. If CH can put together a slice240 maybe we'll be able to try this out. I tried a section of just eight textures and it took me forever to get done. Imagine that by 512.

> backdrops made of 16 256x256 textures?

Yes. They can be made to look stunning. But balance is the key. If you pump all those textures into the backdrop, then it would be wise to prune back in other areas.

> no one seems to have taken notice other than i

A while back it was discovered that a geforce 3 has a unique problem with antialiasing. So, yes, it's true that different cards can give different rendering results. Until I get a new card, there's not really much I can add to that particular discussion. I saw it, but keep my trap shut until I can speak with more authority ;-)



Hope this helps.

Do you have such a 256-textured backdrop at hand?
My idea is to test its impact on an existing track. Or maybe you had the same idea before and could explain into more detail what you mean by "balance is the key" ?

basically if u got 10+ 256 texture to make up a backdrop then u better take care of the terrain models. not alot at all. and make as many 64 textures for the track as u can.

I made some tests with 256 textures and these are the current findings:
1) It is only worthwhile to use 256 textures on squares you actually drive over. This, because squares you only see in the distance (>4 squares away) will never use more than 60 pixels on screen, hence the higher texture resolution will not only be useless but will actually decrease visual quality because of Moiré effects. ( this might perhaps be useful to simulate wind effects on fields or water)
2) On a hi-spec machine no lag was observed: I consistently got over 50fps.

For practical purposes, a slice 240 would indeed be nice.
Does anybody have the source code of slice-60?
Or at least a reference to the structure of bmp files?

bmp file formats can be foru8nd all over the net. I am a bit farmiliar as i needed it for RAW>bmp and BMP>Raw conversions in c-pod.

a slice 240 however is not somthing i'd liek to spend my time on. wont get used much.