View Single Post
Old 15-04-21, 20:17   #20588
Lwmte
Archaeologist
 
Lwmte's Avatar
 
Join Date: Aug 2010
Posts: 1,460
Default

Quote:
Originally Posted by Mulf View Post
I'm probably going to regret this , but I have to ask: In what sense is cutting off half a pixel from a perfectly seamless texture a 'correction'? Why did they programme it like this? (Assuming it was intentional, and not a bug they never got round to correcting.)
I remember I have described it somewhere long ago, but it won't hurt to do it one more time

The biggest problem of all TR engines when it comes to texturing is they use 256x256 texture pages (also known as texture atlases) to store all textures. In practice it means that each 256x256 texture page may contain completely different texture pieces of different kind, such as Lara skin parts, room textures, enemy textures, inventory item textures, and so on.

Since originally TRs were made for systems such as Saturn and PSX, which had no bilinear filtering (this kind of filtering which makes your textures not appear pixelated by "blurring" them), it caused no any problem - every pixel border was strictly defined and no artifacts were visible in game. Now, when it comes to PC, a problem appears - modern GPUs can't apply bilinear filtering to just every piece of a texture page separately, it "blurs" whole texture page at once - which inevitably causes "border bleeding" problem, where every adjacent pixel of two different texture pieces on a single page bleeds into each other by 0.5 pixel margin. Core Design had no better idea in mind but to hardcode "texture crop" by 0.5px from every side to mask this issue. I don't know why they have gone by this route - either they were lazy to implement padding, or they were afraid that introducing padding may result in increased memory requirements (remember that TRs were released in 90s, when most of PCs had around 32 megabytes of RAM or even less). Of course this "texture crop" caused another problem instead - seams between initially "seamless" textures.

Tomb Editor has a solution for this problem - it automatically generates padding for every texture piece, so it doesn't bleed into each other. Basically it's the same routine that GeckoKid et al used in old days, but it is done automatically, and also it expands all existing textures such as Lara skin etc to original size, fixing all other potential problems (like infamous cropped Lara lips and nose textures in original skin).

Another consequence of ineffective texture management in TRs is all engines, from TR1 to TR5, completely lack mipmapping - that's why high-res textures will look noisy in the distance. Core just couldn't implement mipmapping, because if they did, border bleeding problem would resurface with even bigger artifacts, because every mip level blurs every texture page even more, so 0.5px crop won't suffice. Tomb Editor also takes care of this problem and sets default padding for textures at 8px, meaning that if there will ever be a patch for tomb4 which will add mipmap support, at least 3 mip levels may be created without visible artifacts. That's why I don't recommend reducing padding value in level settings for tomb4 (for TR1-3, sadly, you must do that sometimes, because those engines have strict limits on texture page count).

P.S.: There is also small seamless texturing tutorial, if you need one.

Last edited by Lwmte; 15-04-21 at 20:31.
Lwmte is offline   Reply With Quote