Hard Light Productions Forums
FreeSpace Releases => Asset Releases => Topic started by: Herra Tohtori on February 02, 2010, 04:55:01 am
-
Some of you may already be familiar with the limitation of cube-shaped skyboxen; the ugly seams visible between the cube faces. The technical issue behind the problem is a rather deep one and suffice to say, perfect solution is not available without DirectX 10 level of rendering engine if I recall correctly*. However, things can be done to get over this issue, and today, after an IRC discussion on the subject, blowfish put together a model that uses a bit different mapping than the typical face=texture style that would seem logical and most straightforward to use. As a result, skyboxes with no seams can now be used with a generic skybox model, with a negligible texture resolution sacrifice.
This model can be, if desired, put inside the mediaVP starfield skysphere, and with alpha blended textures pretty much limitless amount of options is now available. Things like being in atmosphere, or having rings of a planet reach behind you, are now possible without seams and with supreme quality.
The mapping scheme used is as follows: When using texture resolution of 2048^2, the actual part of the texture mapped to the side of the cube is now 2040^2. The remaining edge of the texture space is used to border the texture with the corresponding edges from the textures next to it, which will negate the issue that caused the seam edge issue to begin with.
Here is a sample image of how to edit the textures to get the correct results in-game:
(http://img136.imageshack.us/img136/2707/frontsample.png)
This is a 1024^2 texture, so the area used by the actual texture is 1020^2 and the two pixel border between is filled with adjacent sides' textures, as you can see from here. The darkened areas are shown here just for clarity.
In-game screenshots just for the hell of it (this skybox isn't especially high quality, since I just put it together for the purpose of testing the seamless skybox model):
(http://img697.imageshack.us/img697/319/skybox1.png)
(http://img683.imageshack.us/img683/159/skybox2.png)
(http://img41.imageshack.us/img41/935/skybox3.png)
DOWNLOADS HERE
Here is a simple version to get the skybox and a batch of test maps:
generic-skybox-redist.7z (http://www.mediafire.com/?oyzwyxdwgum)
And here is a more complete version that contains .xcf files (native GIMP format, PSD can be provided if requested) and the source 1024^2 textures for the sample skybox:
generic-skybox-dev.7z (http://www.mediafire.com/?mnlmez0gd3t)
Credits:
Model: blowfish
Maps: Hipshot @ www.zfight.com, edited by Herra Tohtori, source image available at http://www.zfight.com/misc/images/textures/envmaps/stormydays_large.jpg (http://www.zfight.com/misc/images/textures/envmaps/stormydays_large.jpg)
Enjoy your new seamless skyboxen, everyone!
EDIT:
* As per discussion later in the thread, this turns out to be bogus partially incorrect. There is apparently a new feature that will be in 3.6.12 that will allow the use of standard six-side skybox cubes without the seam issues, by setting the skybox rendering to clamp the textures via a FRED flag. However, there are other issues associated to this method - mainly environmental mapping still suffering from the seams and dependancy on a graphics card that can actually do the required stuff.
The technique mentioned in this post is still applicable if you want to avoid envmapping issues or when using an older build that doesn't support the force clamp flag.
-
:yes:
(this skybox isn't especially high quality, since I just put it together for the purpose of testing the seamless skybox model)
:wtf: yeah, right
-
:wtf: yeah, right
QFT.
Awesome thing, even cooler skyboxes coming yeah!
-
Oh come on, I totally ripped the textures from the first skybox I could find via Google that had passable quality for testing purposes... that's not the main point here. :lol:
-
Oh my ****ing god, that's pretty...
Imma make a wallpaper out of this.
-
:yes2: :D :yes:
Awesome herra, awesome.
Totally going to be using this (and yes, that includes that 'skybox that isn't especially high quality' :lol: )
-
:eek2:
I want to fly the Loki in the atmosphere now...
-
Hm. Looks like the bar for background quality has been raised.
:yes: Excellent work.
-
yet another magic rabbit pulled out of the hat well done Herra Tohtori, blowfish and anyone else involved
-
Blasted mediafire incompatibility with opera mini. . ....
-
<skyboxes>
:yes: :nod:
Blasted mediafire incompatibility with opera mini. . ....
Try Google Chrome (http://www.google.com/chrome) ?
-
i would have done it by clamping the textures, but this works.
the downside is any maps currently in existance would need to be downsampled for this to work, unless of course you have the original scene to render from. if said maps are in a compressed format and you dont have the original uncompressed version, you will probibly loose substantial quality. i probibly wouldnt loose anything since most of the skyboxes im using i rendered myself.
on the other hand this kinda has some good points, since you could standardize the whole skybox interface. and the alpha blending is a good touch. thought i wouldnt mind having -clamp textures as an interim till we have a materials system. a system where we only have to specify a texture set, and not have to worry about editing a model, would be even better.
-
i would have done it by clamping the textures, but this works.
-
i would have done it by clamping the textures, but this works.
the downside is any maps currently in existance would need to be downsampled for this to work, unless of course you have the original scene to render from. if said maps are in a compressed format and you dont have the original uncompressed version, you will probibly loose substantial quality. i probibly wouldnt loose anything since most of the skyboxes im using i rendered myself.
on the other hand this kinda has some good points, since you could standardize the whole skybox interface. and the alpha blending is a good touch.
If you have an improvement in mind, please share.
How would this texture clamping be done? In the model/mapping or in the game engine while rendering the skybox? If the texture clamping can be set up easily, why has no one done it before? Does FS2_Open support it? I definitely agree with the downside of having to edit the textures like this (especialyl the re-scaling part, which can mess up some things rather easily compared to rendering them to the required resolution to begin with), but I was led to believe that there is no simple way to get around the seam issue, based on the threads about it in the past.
Alpha blending isn't anything specific to this model really, it's just something that can be done if someone for example wants to put content within the mediaVP's starfield but doesn't want to render that into the sides of the cubes.
-
clamping is supported by the graphics abstraction but theye is no way to tell it to use it in the model file.
-
clamping is supported by the graphics abstraction but theye is no way to tell it to use it in the model file.
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?
-
Isn't this what the FRED clamping flag was added for? Per WCS' request?
-
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.
-
The Mantis issue for their request was #1914 (http://scp.indiegames.us/mantis/view.php?id=1914)
-
The plot thickens:
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
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.
-
And also, the skybox method will hold up even under an engine over haul, and I can't say with 100% certainty that the FRED flag will, much less what will happen with a cross-platform FRED project.
-
Hehe, no, that isn't very high quality at all ( :eek2:) *wonders if the 158th will pick up on this. . . . .
-
I really need to learn how to do that nice :D
-
you could probibly automate ht's meathod with a skybox generator, which would cross-reference the textures and generate the borders automatically. actually i have a lua based tga parser somewhere which could probibly do this. so you feed it its 1020 textures and it would save a copy with the borders in-place. tga is a very easy format to code with, even in lua.
-
you could probibly automate ht's meathod with a skybox generator, which would cross-reference the textures and generate the borders automatically. actually i have a lua based tga parser somewhere which could probibly do this. so you feed it its 1020 textures and it would save a copy with the borders in-place. tga is a very easy format to code with, even in lua.
Preferably 2040² textures. My observations suggest that 8192 pixels of horizontal resolution is sufficient to offer unscaled background at typical FS2 fields of view, so in many cases it is the optimal resolution.
Larger, 4090² textures can be used with one mip map to offer high quality backgrounds for narrower than default fields of view. Without a mip map they tend to cause shimmering with wide field of view.
An automated texture parser would be welcome as it would reduce the time of handling the textures significantly, but I would prefer if people knew how to manually do it before using automated methods.
-
Try Google Chrome (http://www.google.com/chrome) ?
On my Sony Ericsson W995? Not gonna happen :P
Don't worry. I can get this any time I want. At home.
-
you could probibly automate ht's meathod with a skybox generator, which would cross-reference the textures and generate the borders automatically. actually i have a lua based tga parser somewhere which could probibly do this. so you feed it its 1020 textures and it would save a copy with the borders in-place. tga is a very easy format to code with, even in lua.
Preferably 2040² textures. My observations suggest that 8192 pixels of horizontal resolution is sufficient to offer unscaled background at typical FS2 fields of view, so in many cases it is the optimal resolution.
Larger, 4090² textures can be used with one mip map to offer high quality backgrounds for narrower than default fields of view. Without a mip map they tend to cause shimmering with wide field of view.
An automated texture parser would be welcome as it would reduce the time of handling the textures significantly, but I would prefer if people knew how to manually do it before using automated methods.
i was thinking something along the lines of a stand alone utility to automatically insert the borders from the other 4 adjacent maps you just give it 6 2040^2 textures(really the size doesnt matter, it can be easily coded to take any size), then enlarge the textures and insert the proper pixels from the other maps. if i did it it would probibly use the command line lua interpreter from lua.org, and the commands and scripts would run from a batch file, could probibly also include a command line tga to dxt converter utility so that the maps could be converted to dds and dumped right in the game maps dir and would work.
-
Isn't it possible to do this with the cube model itself without having to specially modify the skybox textures themselves?
Can you map the adjacent textures using the model itself?
I know it's hard to imagine - here's a diagram I came up with to help explain. Basically using the UV mapping, the adjacent textures are mapped to the plane outside of where it intersects the other ones.
So it would do what is accomplished in the texture editing, but with the model itself using UV editing. Each face of the model hear would end up looking like a modified skybox texture if it were alone. The planes intersect where each texture crosses over into the new one.
Would this have the same problem or not? The player wouldn't see outside of the box anyways.
EDIT: Whoops, looks like I left out a top face. Oh well, it still conveys the point.
[attachment deleted by admin]
-
Isn't it possible to do this with the cube model itself without having to specially modify the skybox textures themselves?
Can you map the adjacent textures using the model itself?
I know it's hard to imagine - here's a diagram I came up with to help explain. Basically using the UV mapping, the adjacent textures are mapped to the plane outside of where it intersects the other ones.
So it would do what is accomplished in the texture editing, but with the model itself using UV editing. Each face of the model hear would end up looking like a modified skybox texture if it were alone. The planes intersect where each texture crosses over into the new one.
Would this have the same problem or not? The player wouldn't see outside of the box anyways.
EDIT: Whoops, looks like I left out a top face. Oh well, it still conveys the point.
That's what I tried first on model level. Having six planes with each having dimensions of 4.096 units, then moving them inward so that each plane was at distance 2.040 from the center.
It didn't work, the engine rendered each of the faces since transparency on skyboxes requires object hierarchy being set up correctly, and since the parts of the planes "out of the box" were part of the same level of hierarchy as the "visible" parts of the faces, it rendered the parts that were supposed to be hidden, and results were even more hideous than just having the seams.
I guess it would be possible to just use a black border, but I suspect that would result in similar seam issues as the original problem with cube shaped skyboxen.
I then presented my research results in IRC, asked for a way to cut away the parts of the planes that were outside the cube, and was informed that it could be done by adjusting the mapping. blowfish then provided me the model posted in the beginning of the thread. Essentially, this is one way of explaining how the model mapping works, except the parts of the maps that are outside the cube are simply not rendered.
Not only that but you would still have to modify the textures exactly the same way that is used in the model posted in the OP... unless I understood something completely wrong from your explanation.
-
i kinda fixed corners in my older skyboxes by moving the uv space inward exactly 1 texel width. uv coords are (16 bit?) floating point with 0,0 being one corner of the texture and 1,1 being the other corner (of course they can be more or less than that which is how tiling is done). now finding the width and height of each texel depends on the image resolution. i think 1/texture_width, 1/texture_height will give you the height and width of a texel in uv coords. a 512^2 texture is going to have a texel width and height of about 0.0019531. so instead of having each corner of a square polygon be at:
0'0
0'1
1'0
1'1
you would have them set to:
0.0019531, 0.0019531
0.0019531, 0.9980469
0.9980469, 0.0019531
0.9980469, 0.9980469
take care to avoid rounding errors, 16 bit floating point only gives you about 6 or 7 digits of accuracy with some margin for error. mind you these numbers are for 512^2 skybox textures, which is abit low res for freespace. even 1024^s are kinda block. i also cant remember if it worked or not.
-
That's what I tried first on model level. Having six planes with each having dimensions of 4.096 units, then moving them inward so that each plane was at distance 2.040 from the center.
It didn't work, the engine rendered each of the faces since transparency on skyboxes requires object hierarchy being set up correctly, and since the parts of the planes "out of the box" were part of the same level of hierarchy as the "visible" parts of the faces, it rendered the parts that were supposed to be hidden, and results were even more hideous than just having the seams.
I guess it would be possible to just use a black border, but I suspect that would result in similar seam issues as the original problem with cube shaped skyboxen.
I then presented my research results in IRC, asked for a way to cut away the parts of the planes that were outside the cube, and was informed that it could be done by adjusting the mapping. blowfish then provided me the model posted in the beginning of the thread. Essentially, this is one way of explaining how the model mapping works, except the parts of the maps that are outside the cube are simply not rendered.
Not only that but you would still have to modify the textures exactly the same way that is used in the model posted in the OP... unless I understood something completely wrong from your explanation.
What I meant was, for the areas outside the view to use the textures directly from the adjacent face (thus each face would be mapped twice) instead of a modified texture that has it added to it.
-
Hey Herra, I finally tried it out and I must say it's very nice and "atmospheric" if you will. :yes:
I have a question, that's probably going to be very newbish though: Can anybody take the skybox you provided and map our own textures to it? Will that work, or will we need to rebuild the whole thing in each case?
-
Hey Herra, I finally tried it out and I must say it's very nice and "atmospheric" if you will. :yes:
I have a question, that's probably going to be very newbish though: Can anybody take the skybox you provided and map our own textures to it? Will that work, or will we need to rebuild the whole thing in each case?
The model should be useable for any kind of skyboxes, just change the textures. Changing the texture names in PCS2 is almost a trivial task. The model is out there for download for a reason. I should probably upload it to FSMods if it isn't there already...
-
Tried to follow the tutorial and I got this image:
(http://i1178.photobucket.com/albums/x380/Brandon_Rehayem/png.png)
I must be doing something wrong. I took six 2048^2 textures, resized them to 2040^2 and increased the canvas size to 2048^2 to get that white boundary. If I understand the tutorial correctly, the seemless uv mapping is supposed to account for this somehow, or perhaps i'm just lost. Please help!
Disclaimer: I don't pretend to know anything about skyboxes or image formatting or any of that sort!!!
-
Tried to follow the tutorial and I got this image:
(http://i1178.photobucket.com/albums/x380/Brandon_Rehayem/png.png)
I must be doing something wrong. I took six 2048^2 textures, resized them to 2040^2 and increased the canvas size to 2048^2 to get that white boundary. If I understand the tutorial correctly, the seemless uv mapping is supposed to account for this somehow, or perhaps i'm just lost. Please help!
Disclaimer: I don't pretend to know anything about skyboxes or image formatting or any of that sort!!!
Underlined the problem here.
The trick to making this work is to surround each 2040^2 area with the adjacent texture edges. That way, the "gaps" between the textures are covered in the mapping, and the seams will disappear.
(http://img136.imageshack.us/img136/2707/frontsample.png)
If you observe this sample image, you can see that there are four textures surrounding the center one, and the texture area is outlined with the darkened area. You can also see the white small squares in each corner, where the white background shines through.
If it's still unclear, ask further specifics in irc sometime.
-
That took quite a bit of careful pixel perfect placement, but I got it to work perfectly. Thanks.
-
As mentioned above, it takes quite a bit of pixel-perfect placement to make this work. And those who get to make a fair few of these, know how time-consuming the job can be. So I made a GIMP script that does it for you.
Installation
1. Unzip the script into C:\Documents and Settings\<username>\.gimp-<version>\scripts
2. In GIMP, click Filters > Script-Fu > Refresh scripts
3. The script will now show up as "Envmap to skybox" in the Filters > Map menu.
Required input
- Place your faces in the following way (it's the Blender envmap layout).
(http://upload.wikimedia.org/wikibooks/en/f/ff/Blender_env_order.png)
- Recommended input resolutions are 6120x4080 (for 2048^2 maps) or 12240x8160 (for 4096^2 maps)
- Merge all your layers into one (Ctrl-M)
- Make sure your picture size fits your layer (Image > Fit Canvas to Layers)
- Your image should be in RGB mode (Image > Mode > RGB)
What will happen
The script will ask you where and under what filename you want to save the faces. They're saved automatically as PNG, DON'T give the filename an extension!
The saved images will merge seamlessly when used with the skybox in OP.
MediaFire download: version 1.3, January 2016 (3kB) (http://www.mediafire.com/download/azjnda749soiss4/env-to-sky_13.zip)
-
I know the first thing I'm doing when I get home. :-D
-
This script works quite nicely.
(http://img849.imageshack.us/img849/9758/eaglenebula0020.png)
(http://img90.imageshack.us/img90/2366/eaglenebula0016.png)
:)
-
I DEMAND the downloadlink for this skybox!
-
Eagle-Nebula.7z (http://www.mediafire.com/?z56c6xs5783cb17)
-
Where do you get these background :O
-
Thanks Herra!
-
Where do you get these background :O
HST (http://heritage.stsci.edu/gallery/galindex.html) aka Hubble Space Telescope. :p
From that gallery, you pick the "Full-Resolution images" option which will, in this case, take you to Hubblesite.org (http://hubblesite.org/newscenter/archive/releases/2005/12/image/b/) which has mega huge pictures (http://hubblesite.org/newscenter/archive/releases/2005/12/image/b/warn/) for most of the stuff. In this case, source image was a 3857 x 7804 TIFF file.
There are a lot bigger pictures available, such as Eta Carinae Nebula (http://hubblesite.org/newscenter/archive/releases/2007/16/image/a/warn/) which has a 29566 x 14321 TIFF file available...
Once I find a suitable source image it's just a matter of editing it in GIMP to produce a spherical texture, which I then use in Blender to produce six-sided skybox texture renders.
-
This is just f***ing amazing! Thank you, Master!
-
wow, amazing stuff!
edit: and thanks for the script, it's truly a life jacket.
-
Glad to see it being put to good use :)
-
As mentioned above, it takes quite a bit of pixel-perfect placement to make this work. And those who get to make a fair few of these, know how time-consuming the job can be. So I made a GIMP script that does it for you.
Installation
1. Unzip the script into C:\Documents and Settings\<username>\.gimp-<version>\scripts
2. In GIMP, click Filters > Script-Fu > Refresh scripts
3. The script will now show up as "Envmap to skybox" in the Filters > Map menu.
Required input
- Place your faces in the following way (it's the Blender envmap layout).
(http://upload.wikimedia.org/wikibooks/en/f/ff/Blender_env_order.png)
- Recommended input resolutions are 6120x4080 (for 2048^2 maps) or 12240x8160 (for 4096^2 maps)
- Merge all your layers into one (Ctrl-M)
- Make sure your picture size fits your layer (Image > Fit Canvas to Layers)
- Your image should be in RGB mode (Image > Mode > RGB)
What will happen
The script will ask you where and under what filename you want to save the faces. They're saved automatically as PNG, DON'T give the filename an extension!
The saved images will merge seamlessly when used with the skybox in OP.
MediaFire download: version 1.2, Oct. 21 2011 (3kB) (http://www.mediafire.com/?uobtufri0v4lbq1)
you are the awesome man of the second!!! aaaaah forget it, of the minute even!
-
This is awesome. I've been able to use it already. But there's one problem.... if you wanted your generic seamless skybox to have a submodel as a part of it, since Geometry import apparently does not carry over textures in PCS2, you'd be unable to add them. Could you post the original max or blender file you made?
-
Wut.
Just export the skybox as a .dae and use that...
-
Last time I tried that, it broke the UV map. How do I avoid that if I only have access to blender?
-
A properly installed and upgrade PCS2 and Blender will not break UV maps for that process.. I do it very often.
-
Ok, so I think I found my error. Turns out everything was properly installed, but I never added a texture onto the model after import. Rookie mistake. :banghead:
Sorry for the trouble guys.
-
So... It has come to my attention (thanks Herra!) that the seamless-skybox script no longer worked on newer versions of the GIMP. Turns out one of the functions that the script used has been deprecated etc. This should be fixed in version 1.3 of the script, hopefully enabling easy seamless skyboxes for many years to come!
Release post repeated below for convenience:
As mentioned above, it takes quite a bit of pixel-perfect placement to make this work. And those who get to make a fair few of these, know how time-consuming the job can be. So I made a GIMP script that does it for you.
Installation
1. Unzip the script into C:\Documents and Settings\<username>\.gimp-<version>\scripts
2. In GIMP, click Filters > Script-Fu > Refresh scripts
3. The script will now show up as "Envmap to skybox" in the Filters > Map menu.
Required input
- Place your faces in the following way (it's the Blender envmap layout).
(http://upload.wikimedia.org/wikibooks/en/f/ff/Blender_env_order.png)
- Recommended input resolutions are 6120x4080 (for 2048^2 maps) or 12240x8160 (for 4096^2 maps)
- Merge all your layers into one (Ctrl-M)
- Make sure your picture size fits your layer (Image > Fit Canvas to Layers)
- Your image should be in RGB mode (Image > Mode > RGB)
What will happen
The script will ask you where and under what filename you want to save the faces. They're saved automatically as PNG, DON'T give the filename an extension!
The saved images will merge seamlessly when used with the skybox in OP.
MediaFire download: version 1.3, January 2016 (3kB) (http://www.mediafire.com/download/azjnda749soiss4/env-to-sky_13.zip)
-
I needed to reacquire the envmap to skybox script, and noticed the image in the post quoted below didn't work (something in Wikimedia's linking had changed). Fixing for the sake of documentation.
As mentioned above, it takes quite a bit of pixel-perfect placement to make this work. And those who get to make a fair few of these, know how time-consuming the job can be. So I made a GIMP script that does it for you.
Installation
1. Unzip the script into C:\Documents and Settings\<username>\.gimp-<version>\scripts
2. In GIMP, click Filters > Script-Fu > Refresh scripts
3. The script will now show up as "Envmap to skybox" in the Filters > Map menu.
Required input
- Place your faces in the following way (it's the Blender envmap layout).
(https://upload.wikimedia.org/wikipedia/commons/f/ff/Blender_env_order.png)
- Recommended input resolutions are 6120x4080 (for 2048^2 maps) or 12240x8160 (for 4096^2 maps)
- Merge all your layers into one (Ctrl-M)
- Make sure your picture size fits your layer (Image > Fit Canvas to Layers)
- Your image should be in RGB mode (Image > Mode > RGB)
What will happen
The script will ask you where and under what filename you want to save the faces. They're saved automatically as PNG, DON'T give the filename an extension!
The saved images will merge seamlessly when used with the skybox in OP.
MediaFire download: version 1.3, January 2016 (3kB) (http://www.mediafire.com/download/azjnda749soiss4/env-to-sky_13.zip)