The Sky is the Limit
Working with skies has been a favorite subject for me since I first started working with custom content. Skies are very costly, impressive, misunderstood, and mostly cosmetic.
It has always been an interest of mine to make skies more relevant, as I've seen in other games, for navigation (seeing distant landmarks), for telling time, or for detecting or anticipating weather.
A lot of these ideas sound impossible, but I think any of them can be acquired through careful work.
A stormy high resolution day sky override, as seen on the Arelith Fixed Level server
The well-known "Grassy: Clear" skybox available in Bioware's Neverwinter Nights: Shown in a 3d render in Blender.
What's Wrong with the Bioware Skies?
There are a lot of issues with the default Bioware skyboxes.
- Sky textures are large uncompressed
.tgafiles. Not only are they the largest.tga's, but they are also the largest textures in the core game assets. Additionally, since skies have a fixed size (You never get closer to a sky, hopefully), they should always be using their largest resolution. I wonder if that's why they were never converted to mipmapped.ddstextures in the first place, but without theMipmap 0command, I've come to believe the game tries to rescale them in places anyway. - Bioware skyboxes are centered 5-sided cubes (no bottom). This means that the whole of the distance is filled in with texture in every direction (except down). This sounds like a good thing at first, but more than half of those directions are off limits. The default camera cannot face straight up to view the "lid" of the skyboxes, nor can it see the lower half of the sides of the cube, since the ground is in the way. Even if the ground was replaced with "pit" tiles, the black "pit" objects still block the view. Even if those pit objects were made transparent, a small "skirt" is attached to the inside of the skyboxes, called "
skyfade.mdl". This model is fog color-inheriting, and goes as far down as the sides of the cube do. This means the skyboxes do a lot of extra drawing that no one ends up appreciating. Furthermore, this also means that since most of the texture is delegated to places that cannot ever be seen, that the part of the texture that is seen is of low quality and resolution, hindering the benefit. - Skybox textures do not map continuously. Since two sides of the cube make up each top and bottom halves of the texture, the continuous image starts on one half of an edge and continues onto the other half of the other edge. Meanwhile, the game's texture mapping draws pixels from the opposite edge (same half) onto the end of any face when rounding issues require extra pixels. Since those pixels come from the opposite side of the sky (180°), there is a sudden change in color that causes "seams" to appear on the 2 corners of skies that wrap to the other top/bottom half of the texture.
- Skybox models are placed by the game engine at a fixed location, the bottom left corner of every area. The further one travels from this corner, the closer to the Northeast corner of the skybox model one becomes. This causes distortion, when the faces are viewed at an angle, and in severe cases, can outpace the render limit for the skybox model.
- Bioware skybox textures come with limited spherical projection. While this provides some good perspective distortion of image material in the center and the edges of each cube face, it is not enough to prevent "sharp corners" in the texture at the cube edges, and is not remedied by the "ballooned" shape of the skybox cubes Bioware created by rounding out the sides of each face.
- Skyboxes are not exempt from expensive shaders in 1.74, and taking such a large texture and processing it with distance based depth of field and Screen Space Ambient Occlusion is costly for the rendering engine, leaving less room for other high quality assets for what is still a low quality effect (for the above reasons).
What has made skyboxes better?
I'm not the only person to work on skyboxes, of course, and a lot of the issues above have been avoided, corrected, or negated by efforts amongst the community since the skybox feature was introduced in 2003's Hordes of the Underdark.
- Cubes have been replaced with lots of shapes, including domes, semispheres, and cylinders. These shapes usually do not come with "lids", to the regret of camera-hak users.
- Textures have been replaced with higher resolution textures. Since the viewing range from horizon to top of screen with the Bioware textures as mapped by default is often only a few hundred pixels, using new shapes focusing on "above the horizon" texturing, with higher resolution textures, has often provided much denser pixel quality for skies.
- Many skies have been converted to
.ddsallowing even higher resolutions to be possible with much faster processing and much smaller file size. - Some "alternative skies" have been introduced to provide non-sky backdrops for scenes, such as cavern interiors and forests.
In attempt to address some of the issues with default skyboxes (beyond lack of variety), some of these skyboxes have unfortunately worsened some of the other issues. The higher resolutions often impacted the game more heavily, and instances of extra geometry either distorted textures more, or proved to be more difficult to make than the default box shapes. Additionally, a lot of these textures were "lifted" from other sources on the internet, which has been accepted by much of the community, but frowned upon by others.
A skybox model from the Prisoners of the Mist PW server, made by Soren / Zarathustra217: Shown in a 3d render in Blender
Personal Work
High resolution source panorama, downloaded from https://shinesmiley.files.wordpress.com/ around April 2017 for work on custom skybox
End result of first skybox attempt, as seen in-game in the Arelith Fixed Level Server
Close-up of color banding issues stemming from original image and poor in-game resolution
First Attempts
Skyboxes were one of the first things I worked with in NWN. A lot of my inspiration for finding content to make comes from looking around in the game and noticing ugly colors, noticeable pixelation, or poor performance. The skyboxes had all of these things for me.
Copy / Paste
In the beginning, my approach was to replace the textures, they seemed like the biggest culprit, and being new to the game's assets, I hadn't yet noticed a lot of the issues detailed above. The first "re-skin" I made was with a texture I found of a phone panorama taken on top of a mountain. There were several things I liked about this image: the lack of a clearly defined circular sun, the crisp color contrast, the depth of the blue sky, and even the shape of the clouds. I used some filters on the image to make it look a little more "hand-painted", and threw it into the game with pleasant results.
However, there were of course problems. I still didn't have the resolution I wanted, the pixels were a bit blurry, and in the emptiest sections of the sky I noticed a lot of greens and purples that didn't enhance the color blending, but detract from it.
Meanwhile, Bioware's 1024x1024 texture stack wasn't nearly capable of showing this texture, so I raised the resolution to 2048, and then eventually to 4096x4096, 16x the original size of the skybox textures that were already slowing down most computers. It was around this time I set out to figure out what .dds was, how it worked, and if it was worth using for skyboxes. After my research, I switched formats, and found the results much more playable.
Night Time
Feeling a little guilty about having stolen an entire photograph, I set out to make the night sky have more original elements. The sky was made busier to cover the color banding, and source images were only taken in small samples and heavily modified. Contrary to the day sky, and in accordance with the Bioware sky, I wanted to make the moon both locatable and well defined. Since no one would see the texture below the horizon, however, I used the original sky as a template and worked on top of it.
With both a day and a night texture for the skyboxes, I passed out some copies to willing testers, who either loved everything about them without constructive input, or were able to point out the various glaring issues with my maiden voyage work.
Unhappy with either, admittedly, and less interested in finishing with dusk/dawn textures to round out the set, I shelved the work for a few months.
It seemed with the skybox textures fixed to the model so that half of the detail was below the horizon, it wouldn't be possible to get the resolutions I wanted for skyboxes with the level of detail found in the other games objects.
Night sky painted over day-sky texture, with copy pasted "milkyway" textures, stars, moon (made out of photo of Mercury), shuffled around to be properly continuous.
Night sky as seen in-game in the Arelith Fixed Level Server
Viewing of test texture on Bioware Skybox models, showing issues with viewable texture percentage, and issues with lining up corner textures
Designing the 8 panel octagon cylinder, one panel at a time
The final 8 panel sky-ring, one panel selected (in orange)
Model Student
I didn't quite find what I wanted in the community created shapes. Some of them had good coverage and pixel concentration, but they were too pinched or stretched from the curves in the geometry. Others seemed easy to map a texture too, but spread too high and low, putting wasted texture pixels outside of viewing angles, and wasting resolution.
By comparing my gameplay resolution to how of the game view was taken up by the sky with the test texture, I decided I could come up with a good system to fill in sky-space with high resolution imagery and keep them as flat as possible.
I started with an octagon cylinder, aimed at making 8 individual textures, separated each of the 8 sides from each other, and divided each side into 16 sections. Then I used proportional editing to rescale the upper vertices more than the lower vertices, to curve the octagon in, and used proportional scaling again to puff out each panel's interior vertices to equally distribute them into a rounded shape more like a 32-gon than an octagon.
The ring came out pretty well, for a first project, and I was comfortable that it had a good equal distance curve from the center (like part of a sphere), and covered enough sky to go both below the horizon and above the max camera angle. All that was needed at that point was exporting the 8 individual continuous textures to fill each of the panels.
This time I started with night, and while I first imported the night sky I had made above, the new format (8 panels, starting at 2048 x 2048 each) did allow me much more resolution than the finished product of my original night sky (one 4096x4096 texture at its best, with ground/sky/ground/sky in any vertical line, 1024 total height of the sky), so I decided to start fresh.
The sky I ended up making was mostly featureless, to test the performance of the model and the resolution. I was half hoping the game wouldn't try to draw panels not currently in the view frame, which seemed to be the way the game worked for players.
Often times people with lower performing machines would experience a severe framerate drop when looking sideways enough to see any part of a skybox (if skyboxes were on). However, after testing, It didn't seem like my plan of having the game only drawing the half of the sky you could see worked, but I finished the separated system anyways.
I started with a very dark blue background, then randomly generated small random dots of white and bright blue, faded them slightly, generated more, faded them and blurred them slightly, and then generated a third pass.
I did the same using a "clouds" generator filter, to achieve a mix of galactic clouds and atmospheric clouds. I took some creative control of different cloud colors, nothing too elaborate, and sliced up my final 16384 x 2048 texture into it's 8 individual .tga squares, and threw them and the new skybox .mdl file into the /override folder, and launched the game.
One of the eight panels used for the new 16384x2048 sky-ring
New night sky override as seen in the Arelith Cordor PW server
Glass Ceilings
Here's how that went
- The quality was superb. 2048px tall is more than the resolution of the game, so there was absolutely no blurring or pixelation at any section of the sky I was looking at.
- Between the camera pointing at the ground, and pointing at the sky, my framerate dropped from about 40 frames per second to 2.5! That's not good.
- I could see each individual panel, unfortunately. The seams I had noticed in the default skies, and in my first pass at HD skies was still there, despite the brand new model. But now there was 8 of them!
I double checked the texture mapping tverts in the .mdl ascii, all looked precise. The seams were an annoyance, but still not as grievous of an issue as the unplayable framerate, granted I had not compressed them to .dds yet. After doing so, I noticed dramatic increase in my performance (frames per second ~ 22) but, still something that would be extremely limiting come combat time. It's somewhat to be expected that a switch from 1024x1024 to 16384 x 2048 would slow down the game a bit, but I was determined to find a workable solution.
So, after thinking about it for a while, I turned off the filtering. I had recently discovered that the game allows the use of .txi files to outline extra properties of included textures of the same name. This allows you to control how the game presents them. This is how animations are accomplished, and by adding a new command to a .txi for each of the 8 textures, I was able to turn off the part of the game that tries to fill in the space between texture pixels with smooth color transition. After all, if the skies were already 2048 tall, and you couldn't see them from top to bottom at any single viewing angle, I didn't need the game to fill in intermediate colors, I already had more pixels than would fit on my monitor!
The .txi commands for each sky texture in the 8 panel model
It turned out that for a texture of this size, filling in the color between all of those... 33,554,432 pixels was quite a costly default background process for the game to tackle, and turning the feature off for just these textures brought the framerate back up to normal playing levels. For my eyes, at least, there was no noticeable drop in quality of the resolution, though it did seem that the stars seemed to "twinkle" while I was moving around in the game, as the pixels slid around between different pixels on my monitor. It could be the case that this occurred with the filtering on, but with a framerate of two, I wasn't able to observe it, and I kind of liked the twinkling.
Seams Legit
Having accomplished one impossible task, I switched targets to rid the skies of the "seams" between the panels. Since the edges met perfectly, I didn't understand where the color was coming from.
The colors in the seams seemed to be random, and were neither one solid color, like one would expect the "behind the sky" color to be, or something having to do with either of the adjacent panels. Eventually I remembered something from my earlier work with reverse engineering the .dds format, when I noticed a texture "wrapping around" in the game.
So, it appears that there is a small margin of error on the eventual placement of texture pixels. Depending on the viewing angle, perhaps which tverts end up on which screenspace pixel influences which number of colored pixels from the texture file get grabbed to fill in any given [triangular] surface.
Now, on the edge of each of my panels, when more pixels were needed, the game's behavior defaults to grabbing pixels from other other side of the texture. This means that at the right edge of one of the panels, sometimes, there would be a little sliver of the beginning of the left side, where the panel begins to repeat the texture.
Luckily, .txi to the rescue again, I discovered (with a lot of searching, I think of the Knights of the Old Republic modding community forums, at this point), that there was a property called "clamp", that under-no-circumstances allows a surface to "repeat" a texture after going "off the edge" of a texture. Adding the command to the .txi immediately, and finally (perhaps for the first time in NWN history?) provided me with an in game sky texture with no seams what-so-ever. I did a test case with the much more obvious seams in my original, lighter, night sky texture, and the seams were completely gone.
Seam visible caused by texture-repetition at the end of a face/texture
Seam removed using the clamp 3 command in each texture's .txi file
Head in the Clouds
A functioning wonderful looking night sky was nice, but even for one skybox there is also dawn, dusk, and day skyboxes as well. Using random noise to generate skies would not work as well for daytime as it did for clear night skies.
Meanwhile, the new high resolution format quite nearly roped me off from borrowing any more assets from the internet, It was not going to be the case that I would be able to find any pictures of skies in large enough resolution to really handle the new model I had made, so the case became that moving forward, my work would have to be some kind of original.
While some of my work ends up turning out in ways that I enjoy, I don't consider myself to be an artist. I have neither the training, nor the experience for the work, and perhaps not the right personality type either.
It may be that my ability to find issues with the art systems, and exploit system strengths to publish quality work could qualify me as a technical artist, perhaps, but even outside of being new to working on content for NWN, I was also new to spending this much time in a graphic editing program.
But, the bed was made, and if I wanted to move forward, I'd have to lie in it, so I opened a blank 16384 x 2048 image in Gimp, put on some blue gradients, and attempted to draw clouds, in the sky, with a mouse.
One of the first of many hand drawn cloud-like-objects
Working with the full 16384x2048 image in GIMP
The finished eight panel blue sky, cloudy half, on a deserted island on the Arelith PW server, with decorative mirrors
It was uncomfortable to say the least, the mouse certainly felt clumsy, and every color I picked looked like the wrong color as soon as it ended up on the screen. Working on a file of that size was certainly slow-going as well, and filters and adjustments could take a few minutes each, just to find out what the end result looked like. Pressing on, I was determined to get a sample at least in the game and view it from the player perspective, to judge it's flaws on the big screen.
Remarkably, it turned out pretty well. I suppose the tremendous resolution really helped soften what appeared as childish contours and clumsy imitation. Despite things ending up a little stormier than I'd intended, and the fact that I'd only made half the sky something other than "blue", I was able to bundle this up in a package with the night sky, and torment some friends with the task of download and install for the purposes of review.