FreeSpace Releases > Asset Releases
Skybox improvement - get your seamless generic skybox model here!
Herra Tohtori:
--- Quote from: Bobboau on February 02, 2010, 01:45:31 pm ---clamping is supported by the graphics abstraction but theye is no way to tell it to use it in the model file.
--- End quote ---
Does that mean it can or cannot be done at the moment?
Can the skybox rendering be changed so that it does support it, if it doesn't do it at the moment?
chief1983:
Isn't this what the FRED clamping flag was added for? Per WCS' request?
Herra Tohtori:
Oh well. This method can still be used if for some reason use of older builds that don't have this texture clamp feature enabled is for some reason required.
Like the Blue Planet: Age of Aquarius re-release which will be 3.6.10 compatible
And at any rate, it's sort of good that this information came out now rather than before re-making the skyboxes into new format.
The headline of this post might as well stay as it is, considering this is the first time I have heard of this new feature it is likely the first time many others hear of it as well. I'll edit the first post to include this information.
chief1983:
The Mantis issue for their request was #1914
Herra Tohtori:
The plot thickens:
--- Quote ---22:46 <@Zacam-Work> *sighs* Force clamp still requires a GUP that can apply that to cubemaps whichi isn't a lot of them.
22:47 <@Zacam-Work> And it's not bogus, but I will look into the fred flag anyway.
22:51 <@Zacam-Work> I think what the flag is doing is forcing an iterative clamping for the seam edge for skyboxes rather than relying on the dynamic
instancing that is only available in DX10 class cardse. Key item to note there is: Dynamic. This doesn't preclude the ability to
statically do a seam edge clamp prior to hadning it off and appying it in the model, and in fact I think it's scaling the textures for
rendering in exactly the same way you're doing it manually.
22:56 <@Zacam-Work> Also, are the faces textures being mip-mapped, and how does it hold up to changing quality levels in-game?
22:57 <@Zacam-Work> Because I can almost guarantee that at lower detail levels, the same edge seam problem may still exist (but maybe not, if it's not fused
sides....hmmm.)
22:58 <@Zacam-Work> What the flag does, _I think_ is it renders the seams for all mipmap levels and all faces into one FBO, then does a series of
glCopyTexSubImage2D() from the FBO to correct the texture.
22:59 <@Zacam-Work> "BTW, mipmaping on cubemaps will not work correctly on the seams because there is no filtering across faces. So if you are doing dynamic
env mapping (rendering into a cubemap) then you will manually have to correct the seams. Or if you are doing static environment mapping,
you might want to manually generate your cubemap mipmaps using some preprocessing tool which puts in a correction for the seams like the
program
22:59 <@Zacam-Work> CubeMapGen, and then completely bypass GLU or automatic mipmap generation and load all the preprocessed mipmaps manually.."
22:59 <@Zacam-Work> Per post in the nvDevZone.
23:03 <@Zacam-Work> Oh, and its backed on the AMD Developer Zone as well, so it's not unique to NV cards.
23:03 <@Zacam-Work> "Despite the fact that cube maps are defined on the spherical domain, standard cubemap mipchain generation techniques perform filtering
independently on each cube face. The main problem with this approach is that no information is propagated across edges, thus creating
undesirable discontinuities along the cube face edges. A limitation of nearly all cube mapping hardware which makes the seam problem
substantially
23:03 <@Zacam-Work> worse is the fact that the bilinear texel filtering is not able to fetch across cube faces thus producing a hard seam artifact in
addition to introducing aliasing artifacts. These two compounding problems limit the usefulness of cubemapping."
23:03 <@Zacam-Work> So no, the problem is _not_ bogus.
23:06 <@HerraTohtori> oh... so the cubemap would still have the seams and therefore envmapping?
23:08 <@Zacam-Work> Correct.
23:09 <@HerraTohtori> well isn't that a barrel of laughs
23:09 <@Zacam-Work> It's just, with your method, you are manually correcting the issue by map displacement almost like a postprocessing effect to deflect
the issue. Which is actually really god damn clever and I'd prefer to see that used than the FRED flag which relies on more
computational horsepower for the same result.
23:10 <@HerraTohtori> WCSaga doesn't exactly hae much envmapping going on either
23:10 <@HerraTohtori> so they will likely have no problem using the flag
--- End quote ---
So basically we have here two methods with different pros and cons. Using the flag allows to keep the textures at full resolution without re-scaling and other texture adjustments associated to the other method, but it requires a GPU that supports the process and it will still have the seams in the environmental mapping.
The other method with the adjusted cube will work without the flag on all FS2 builds that support skyboxes, will work correctly with environmental mapping, but is significantly less convenient and ideally requires the skybox textures to be rendered at 2040^2 resolution originally rather than re-scaled from the 2048^2 textures.
In short: Convenience vs. Quality.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version