[Tolwyn]

As described here and here.

It is an issue I encountered recently in Saga. We introduced skyboxes instead the starfield-skysphere + FRED nebulas. We noticed visible seams between the 6 skybox textures. The reason seems to be the usage of GL_REPEAT in conjunture with small fractional float errors in the texture coordinates. We could correct for this in the shaders by simply simulating GL_CLAMP in them, but that is no solution for the fallback fixed function pipeline rendering.

From my obersvatíon, this is not model related (you can check out the model here)

Since it is unlikely that tiling will be used by anyone for skyboxes, it would make sense to introduce CLAMP to avoid this issue. A test would be needed though if setting to CLAMP will be enough. I don't know if overflow by rounding error can still occur then and what that would look like. Also one has to play great attention ingame when testing. Depending on what skybox is used one might not spot this problem. if only black backrgound and stars are visible one won't see an overflow from black to black. but with planets nebulas or even a landscape skybox this will be visible to some degree or even very obvious depending on the skybox color layout.

[Nuke]

doesnt dds support a 1 pixel alpha zero border for this kind of glitch? otherway to get around this is to simply shtink your uv space a pixel. me personally id make the engine capble of rendering a cubemap without a pof file. it adds a lot of needless complexity to require a model thats gonna be a cube most of the time anyway.

[Tolwyn]

Could you elaborate on this, please?

Modifying the uv space is hardly the solution - we'll probably end up with not fitting texture maps...

Edit:
Ok, I've re-imported the POF (via DAE), just to make sure nothing went wrong during POF conversion.

The vertex positions on the UVW map are:

0,0,0 / 1,1,0 / 0,1,0 / 1,0,0
(W is obviously always 0. Big surprise. )

[Nuke]

well what you do is you want the uv boundries to fall somewhere in the middle of the first row/columb of pixles rather than at the edge of the map. any filtering/blending/whatever that occures will cause the edge of the map to blur into the oppisite edge as it attempts to tile the texture. so tweaking the uv space so that instead of starting at zero and ending at one it starts at (1/resolution)*0.5 and 1-((1/resolution)*0.5), or right in the middle of the first and last pixels. theres also the zero alpha border which the texture assumes that there is a row and columb of null pixels above the first row and next to the first colub, this supposidly prevents the texture from trying to tile. of course i think that's what its for and im not sure if theres an engine level requirement to support that.

[Tolwyn]

I see. I remember reading something on the internet about checking the box that says "Alpha Zero Border". That probably should force the texture to have a one texel wide transparent border, right? Any idea which dds compressor supports this? I doubt that The Compressonator has this option - at least I have not been able to locate it yet.

[KeldorKatarn]

How about just correcting the engine code so the texture does clamping instead of wrapping? This is a rendering problem, not a texture problem.

[KeldorKatarn]

http://scp.indiegames.us/mantis/view.php?id=1914

Added a patch file

[Nuke]

that might work but when the skybox feature was implemented there was some argument about whether it should be a cube or not. this may break skyboxes which make use of tiling. support for the alpha border on the other hand allows modders to just save the texture with the zero alpha border. actually id like to see the engine be capable of using a cubemap without a pof file for a skybox while keeping the model option for anyone who might use it.

anyway i only saw the checkbox in the photoshop plugin, dont know about other dds utils.

[chief1983]

His point though is that it's unlikely that anyone ever will use tiling for a skybox.

[Axem]

Doesn't the current mediavp skybox use tiling? I mean its a sphere, but the sphere is mapped in such a way that a lot of the uv space is repeated so there appears to be very little distortion when you look at it from any point.

But that may have been a previous skysphere, I'm unsure how it works now.

[Nuke]

^ that whas my reasoning there. skybox models are pretty versitile. on the otherhand a dds cubemap need not have a model and could be clamped. fred currently allows us to assign a cubemap for environment mapping, would it not be possible to use that as your background as well? single file cubemaps also have a performance gain since only one map is loaded for the whole box.

[Tolwyn]

But that results in a quality loss. Currently we use 6 2048 maps for a skybox.

[Nuke]

ok, i see your point. but still id like the engine to setup the model automatically, rather than have a different model for each box. what about adding +clamp to the submodel props for now. its sorta the thing that should be included in a materials system, but a submodel prop would be a cheap hack to hold over till such a system is created.

[karajorma]

Having a model is very useful at times though. BtRL didn't use a Skysphere or a Skybox but instead used a sphere with a single flat face we could use to prevent any distortion of the planet.

There may be other mods who want to do something similar.

BTW has anyone looked at the Skybox flags which are available in my branch to see if they fix this problem or can be expanded to solve it?

[chief1983]

...which are available in my branch...

You mean that are probably now in trunk and a new nightly build?

[karajorma]

Nope, they're the only feature not to have been committed to trunk yet as they are still under test. DaBrain finding a rather embarrassing missed newline shows why.

[DaBrain]

His point though is that it's unlikely that anyone ever will use tiling for a skybox.

I'm already using tile mapping in skyboxes. Anybody who breaks this will be my sworn enemy. 

[Tolwyn]

BTW has anyone looked at the Skybox flags which are available in my branch to see if they fix this problem or can be expanded to solve it?

What's that? Did I miss anything?

[karajorma]

Well it was Bobboau and Wanderer who did the real work. I know very little about the graphics side of things, I only stuck a GUI on it.

The idea is to be able to flag which model_render flags the skybox supports. If one exists that can do what you required (or you can add one) then it's pretty easy to make the game support it for any skybox you want without affecting the way the game treats existing skyboxes.

Here's the commit if you can find a coder interested.

[Tolwyn]

I take it, skybox stuff is not included in the latest trunk builds?