Warzone 2100 Forums

MaNGusT wrote:So why the f.. we need to remove some pixels from their edges?

IIRC they're still drawn as tiles, and so can still get seams.

.

Sorry MaNgusT, I misunderstood & thought there was another issue with decals on top of the pixel buffer being too big. (I c now with Cybersphinx's post that a smaller buffer still may not yield the desired seamless results.)

If your working on your own maps, making cliff out of feature models is fun. Doing the same for the legacy maps of others.... well... if you have the right temperament it could be fun I guess.

.

The reason we need lots of extra pixels around the border is to make the mipmapping seamless. If we do mipmapping on the borders, there's nothing to interpolate from, which will cause inconsistencies resulting in visible seams.
That said, on non-tiling decals, like the crater, this wouldn't be needed, but on my cliffs, it certainly is.

Jorzi wrote:The reason we need lots of extra pixels around the border is to make the mipmapping seamless. If we do mipmapping on the borders, there's nothing to interpolate from, which will cause inconsistencies resulting in visible seams.
That said, on non-tiling decals, like the crater, this wouldn't be needed, but on my cliffs, it certainly is.

Mip-mapping the cliff decals would solve the seam issue..?

I made tertile mip-maps for the 2.x series so I can relate to what your saying.

.

Rman Virgil wrote:

Jorzi wrote:The reason we need lots of extra pixels around the border is to make the mipmapping seamless. If we do mipmapping on the borders, there's nothing to interpolate from, which will cause inconsistencies resulting in visible seams.
That said, on non-tiling decals, like the crater, this wouldn't be needed, but on my cliffs, it certainly is.

Mip-mapping the cliff decals would solve the seam issue..?

I made tertile mip-maps for the 2.x series so I can relate to what your saying.

.

No, doing mips is one thing that causes the seams, since, as Jorzi said, there is nothing to interpolate from on the borders...
If all textures were 1:1 with resolution (and no zoom), then we wouldn't have seams.
It is the outer pixels, filtering type and mips that cause seams when they aren't a perfect match.

.

Ok... then... what can be done, if anything, to make cliff decals seamless..?

.

Rman Virgil wrote:.

Ok... then... what can be done, if anything, to make cliff decals seamless..?

.

They are seamless right now...(code wise)
It is just that the 128x128 tiles lose the outer borders, so the actual (visible) tile size is 126x126.
http://www.sjbaker.org/steve/omniv/tiling_textures.html explains it a bit better.

The tiles themselves need to be seamless and repeatable, so they will work if they are rotated or flipped, so when you do a flood fill in a paint program, it looks like one big seamless texture.

We could just try not cutting off anything and see how that looks, might work for the decals. If not, we need to change the decal loading a bit, from loading them all into a texture without space between them, to keeping some space and repeating the tiles' outer pixel rows around it, so no other colours are mixed in.

Rman Virgil wrote:.

Ok... then... what can be done, if anything, to make cliff decals seamless..?

.

vexed wrote: They are seamless right now...(code wise)
It is just that the 128x128 tiles lose the outer borders, so the actual (visible) tile size is 126x126.
http://www.sjbaker.org/steve/omniv/tiling_textures.html explains it a bit better.

The tiles themselves need to be seamless and repeatable, so they will work if they are rotated or flipped, so when you do a flood fill in a paint program, it looks like one big seamless texture.

I c. Thanks.

I was starting to feel vexed, like I'd fallen into the rabbit hole right after Alice.
.

you be ok rman follow the yellow brick road

cybersphinx wrote:We could just try not cutting off anything and see how that looks, might work for the decals. If not, we need to change the decal loading a bit, from loading them all into a texture without space between them, to keeping some space and repeating the tiles' outer pixel rows around it, so no other colours are mixed in.

If you have 1 tile, sitting all by itself, then you won't have issues. Once you start stitching them all together, like it was done in 2.X, then you will.
As for fixing this on loading, it would be the same thing, would it not ? You take a 64x64 image, shrink it down to 62x62, then paste it back over the 64x64 after you re-center it.
Or doing it via shaders on the fly would be another way, but not for 3.1.

Berg wrote:you be ok rman follow the yellow brick road

If only I could. I'm stuck here in the Rocky Mountains without a hurricane in sight to whisk me off to the mighty Oz.

l wonder... there are some munchkins down the hill from my crib...

.

What I did in blender:
-Create plane
-Reset uv:s (makes a square uv map the size of the image)
-Scale uv map to ~0.85
-Make an image texture with bounding box ("generated") coordinates.
-create a new blank 128x128 image to bake to.
-in the bake panel, select "textures". Set border to 12 pixels or higher.

Now you can just load an image into the texture, bake, save, repeat.
It turns all your arbitrary resolution images into 128x128 tiles with a border.

Btw, this is just a small example of blender's advanced remapping capabilities. It can essentially remap any uv layout to any other uv layout.

Arizona cliff tiles are now rotationally seamless. Some work could still be done on reducing the tile effect (there are two straight and two bend tiles and right now both are the same) but It's already pretty nice, the underlying texture gives the cliffs variety.

OMG THATS AMAZING. I don't even care about black lines digging into the ground when i look at it.

One last thing. There are two horizontal cliff tiles (46 and 71), which are currently the same in your .wz file. Probably it is worth it to make them different (but still similar). Cause there isn't much difference, but it should add to the variety of long orthogonal cliffs (not sure if the FlaME's cliff brush places both of them, but still ...)