3D skyboxes are a powerful tool for bringing your map's out-of-bounds areas to life without tanking performance, but dealing with them can be a frustrating and time-consuming chore. Often it's not even the initial creation of the 3D skybox that proves the biggest headache in the long run, but the drudgery of maintaining and refining it over the entire course of a map's development; for instance: Polishing up some ugly skybox terrain that you only just noticed after scaling everything down? Great, have fun trying to make precise vertex adjustments to your now-microscopic power 3 displacements floating around nebulously in a random box outside the map with no way to visualize how it'll look from said map until compiling and loading it up. Expanding your map's boundaries to accommodate a new flank route? Sure, just remember to keep track of exactly how many units you're infringing on skybox territory in each direction on each respective axis so you can make the corresponding skybox adjustments at 1/16th scale to unfaltering precision. Made more than a couple significant layout changes in a row without dutifully updating the skybox after each one, as above? Looks like you’re out of luck! Either rebuild from scratch or make some Frankenstein attempt to remake only the parts that changed while salvaging as much of the rest as possible, which might just be an even greater headache. But fear not, intrepid Source veterans! There is now a remedy for (almost) all of your skybox-borne maladies, and it’s the 3D skybox automation tool AutoSky! AutoSky is a tool that will take care of all the monotonous aspects of 3D skybox creation for you, allowing you to do all your skybox detailing at full scale without ever having to mess with the 3D skybox yourself. Indeed, by leveraging AutoSky to its fullest extent in tandem with strategic visgrouping, you can eliminate your need to ever step foot in the 3D skybox ever again. Let’s get started! If you’ve never made a 3D skybox before or just need a refresher, you should check out some of the documentation on the subject and try making a 3D skybox manually to start. The goal of AutoSky is not to fully abstract away the process of making 3D skyboxes to the extent that you’ll no longer have to know how they actually work, but to streamline the process such that you won’t have to endure the nitty-gritty details anymore once you fully understand them. Step 1: Download First, get AutoSky here. To get the most out of it, I highly recommend that you also install the AutoSky Prop Pack, a collection of various rescaled stock TF2 models designed to integrate with AutoSky’s model replacement feature. Great, so AutoSky’s installed — but in order to do anything with it, we need an actual map to work with! So from here on out, I’ll be demonstrating how to use AutoSky in a case study format, starting from the beginning of our 3D skybox’s creation onward. Step 2: Getting Our [Bonus] Ducks in a Row So, we’ve been working on our map for a while now and we’re ready to start its 3D skybox. For clarity’s sake, I’ll be using a fairly basic scene to demonstrate: Note that the security fence props in this map overlap directly with our skybox brushes. For ease of illustration throughout this guide, these fence props will always represent the boundary between our playable map and the 3D skybox. Your map will probably be a bit more complex, but what matters is that it’s fully sealed with skybox brushes that clearly define where the 3D skybox should begin and end. Make sure your map meets this standard before proceeding. Next, I recommend that you select the entire map, create a new visgroup named “Main Map” (or something to that effect): And add the entire map to that visgroup: Do Alt + Enter to open this menu for all selected objects at once. The reason for this will be apparent in just a minute. In the meantime, we’re ready to start... Step 3: Detailing the Skybox! The title says it all! Go bananas with your skybox, detailing in full scale around the map as demonstrated here; and feel free to use props, since AutoSky will automatically replace them with their skybox equivalents*. You’ll probably want to hide Hammer’s default “Sky” visgroup so you can see both your playable map + the outer detailing you’re adding at the same time. I’ve gone ahead and added some skybox detailing around our sample map below: *Just make sure that the props you use do have skybox equivalents! If you’ve installed the AutoSky Prop Pack, you’ll have more options in this regard (have a look at your props_autosky folder in the model browser). If you’re using any props without a sybox equivalent either in stock TF2 or the AutoSky Prop Pack, you’ll have to make skybox equivalents yourself and add them to AutoSky’s model replacement list manually (more on this later). Selected = area we started with, unselected = skybox detailing Note that in my skybox detailing, I’ve included some of the normal scale skycards and 16x boulder props from the AutoSky Prop Pack. In the case of the skycards, they’ll be replaced with their stock skybox versions upon scaling down, while the 16x boulders will be replaced with their stock 1x models. That’s right — no more blindly aligning these models in the 3D skybox itself and praying they’ll look fine in-game! Align them exactly as you want them here, and they’ll look exactly like that in the in-game skybox projection. Also, as always when working with to-be-scaled skybox detailing, don’t include any brushes smaller than 16 units on any axis; such brushes will turn into microbrushes when transposed to the 3D skybox, which will cause problems for Hammer and Source. Great, we’re almost ready to let AutoSky do its magic! We just have to specify for it which parts of the map should end up in the skybox. And what better Hammer-integrated organizational tool to do that with than… Step 4: Visgroups! Actually, just a visgroup. First, select all the skybox detailing you did in the last step*, then make a new visgroup named “AutoSky”: *This can be done easily if you hide the “Main Map” visgroup I recommended you make in Step 2, then doing Edit -> Select All, thereby selecting only the stuff you made in Step 3. You can get rid of this visgroup after this section. The “AutoSky” name must be matched exactly, since AutoSky only operates on items in that visgroup*. *AutoSky does look at your env_fog_controller, regardless of its visgroup, if “copy fog settings to sky_camera” is enabled. Now add your entire selection to the “AutoSky” visgroup: From now on I might refer to the contents of the AutoSky visgroup as either the AutoSky visgroup itself, or just “skybox detailing”. Even though the AutoSky visgroup is technically just a template for AutoSky to scale down and put in the actual skybox, it’s often more intuitive to think about it this second way. And that’s it from you! Time to fire up AutoSky and let it do the rest. (Be sure to save your VMF now.) Step 5: AutoSky! Open AutoSky and go to the Options tab. These settings are pretty self-explanatory, but you can find more information here. This guide aims to demonstrate the most optimal possible usage of AutoSky, so we’ll be using the following configuration: With these settings we won’t have to lay a finger on the actual 3D skybox ourselves! The 3D skybox will even be inserted right into our map, no copy/pasting required. But wait a second! We’ve checked the box for model replacement, but don’t we have to specify which models we want replaced under that “Model replacement index” button? So long as all the props in your skybox detailing have a 1/16x equivalent either in stock TF2 or the AutoSky Prop Pack, then no! All such props are already included in AutoSky’s default replacement index: If in your skybox detailing you’re using any props that aren’t in this list, however — that is, any stock props with skybox variants you had to make yourself, or any custom props — be sure to add them by clicking on “Add custom replacements”. Now go to the Files tab and enter the path to your VMF, as well as the path of the VMF you want to output as, in the corresponding fields: Note: Being in beta, AutoSky currently won’t let you overwrite your input VMF. The next easiest option, then, would be to iterate your map’s WIP version number in the output name, as shown above; so the next time I run AutoSky after this, my_map_b4_wip1 would become my_map_b4_wip2, and so on. If you’re like me, you already do this every few days of working on a map anyway since you don’t trust Hammer’s autosave. Perfect! Now press “Generate” and feel the anguish of years of skybox-meddling misery melt off your back. Step 6: Behold, the Skybox (for Old Times’ Sake) If you’ve done everything right up to this point, you should be able to skip this step — after all, our goal is to never have to step foot in the 3D skybox directly again. But if you’re feeling nostalgic, we can check AutoSky’s work by navigating to ~192 units below the lowest point of our output map (below the map origin): Note that the skybox’s walls comprise the smallest cube that contains all its contents and snaps cleanly to a 64x64 grid. (If you have any excessively long/wide props they might end up clipping through the walls, but it shouldn’t cause any problems since the origins will always be contained). Also note that AutoSky created a new visgroup in our map called “3D Skybox (AutoSky)” to contain the skybox. It should also be obvious here if you forgot to specify skybox counterparts for any custom props in your AutoSky visgroup (or if there were no existing skybox counterparts for you to specify), since they’ll be left as full size props. Since we only used stock TF2 models with stock skybox versions (as well as some of AutoSky’s 16x models), our skybox is all set. But just for good measure, let’s load up our map in-game to see the final product. Thanks to our strategic visgrouping, getting our map ready to compile is as simple as disabling our AutoSky visgroup and re-enabling Hammer’s “Sky” visgroup. We’ll call this configuration Compile Mode from this point on: The inverse configuration (AutoSky enabled, Sky disabled) — that is, the one we’re transitioning out of — will be called Skybox Editing Mode. Now let’s compare the in-game results of (1) the map before generating the skybox, AutoSky visgroup surrounding it in full scale, and (2) the map with the 3D skybox we just generated, its AutoSky visgroup hidden: Aside from less shadowing overall (as is always the case in 3D skyboxes), our skybox projection matches perfectly! Step 7: AutoSky Now and Forevermore Congratulations; you’ve successfully created a 3D skybox using AutoSky! Now, it may seem that there was a fair bit of manual effort to get to this point, but if you compare against the most straightforward and intuitive method for manual 3D skybox creation, you’ll see that the only extra work you actually had to do here was add your skybox detailing to a specific visgroup; AutoSky took care of all the scaling down, sky_camera positioning, fog value copying, model replacing, and wall building for you, and even made sure to put the skybox in a discrete, though easily accessible location in your map for you (if you ever need to access it yourself in the first place). But if you’re still not convinced, long-term use of AutoSky throughout a map’s development is where the real efficiency/precision boon comes into play. Say, for instance, we want to add a new prop to our skybox. Let’s first change from Compile Mode to Skybox Editing Mode, and bask in the intuitiveness of being able to see our entire level + skybox detailing from Hammer at any moment without having to load it up in-game, just by toggling two visgroups: Again, Skybox Editing Mode => AutoSky visgroup enabled, Hammer’s “Sky” visgroup disabled. Ahh, the serenity! But back to business. I’ll find a satisfactory location somewhere amidst my AutoSky visgroup detailing to add the prop: Let’s use a models/props_trainyard/train_signal001.mdl, which we know has a stock skybox equivalent. Then add it to the AutoSky visgroup (remember to do this for any new items you add to your skybox detailing): And that’s it! At this point, you could save your VMF and run AutoSky as in Step 5 to update the 3D skybox*. Practically speaking, however, you don’t need to run AutoSky after every miniscule change to your skybox detailing; just run it any time you’re about to compile and have made significant changes to your skybox detailing, so that your changes will show up in-game. *As we’ve discussed, when AutoSky outputs the source VMF with the skybox copied in, the skybox is added to a visgroup named “3D Skybox (AutoSky)”, overwriting anything already in that visgroup. Hence, you don’t need to worry about deleting the 3D skybox manually every time you want to regenerate it with AutoSky. For this reason, however, don’t put anything into the “3D Skybox (AutoSky)” visgroup yourself unless you’re directly modifying the 3D skybox (which you shouldn’t be, ideally) and are OK with it being overwritten the next time you run AutoSky. But OK, that was a really simple change; it wouldn’t have been that hard to go to the 3D skybox yourself and throw in a simple train signal prop, though there might have been some trial-and-error in getting it to look exactly as you wanted in-game. So let’s try something more complex. Say we want to build a new area off the north boundary of our map: Top down view. Selected brushes (red) = AutoSky visgroup/skybox detailing, area marked in blue = playable map itself, area marked in green = area we want to extend the playable map by. As we can see, the latter area overlaps with our AutoSky visgroup. Well, we could just make our addition and have a jolly old time trying to guesstimate where and how much exactly to compensate for the changes in the 3D skybox directly, indulging in all the the manifold benefits of microscopic skybox editing, such as not being able to sew with displacements in the playable map and not being able to see how our changes will look until compiling. Or, we can take advantage of the fact that AutoSky allows us to treat our entire level + its skybox as one contiguous landmass, making all our changes at full scale with perfect precision as if everything were part of the playable map, and letting AutoSky do the grunt work for us. Let’s go for the latter option, shall we? Good choice! So as we can see in the last picture, the new addition we’re planning is going to infringe on our current skybox detailing by a significant margin, so we’ll need to scale back said detailing accordingly. But first let’s just worry about making the new route itself; that way, we can make a more informed judgement on how to adjust the skybox detailing to fit it afterwards. My recommended strategy for this is to go into Skybox Editing Mode and hide any brushes/props (using the “h” hotkey) that are occupying the space we want to expand into (marked in green): top: before hiding the stuff already there bottom: after hiding the stuff already there In the now empty space, let’s build our new addition: For our purposes, I’ve just built a little cliff perch/ledge area. And with the addition built, we can unhide the items that were already there (Hammer’s “u” hotkey): Clearly we have a little work to do in merging in our addition with the old detailing. First, we’ll adjust the props that were there to accommodate for the addition: And now we’ll scale back any skybox displacements that our addition is infringing upon, making sure that the playable map’s displacements stay completely separate from, yet fully sewed to, those of the skybox: top: before fixing skybox displacements bottom: after fixing skybox displacements If you look closely in picture 1, you’ll see that our skybox displacements (selected) are clipping into/underneath the cliff area we just added (marked in green). In picture 2 I’ve trimmed back these displacements so that they form a seamless boundary with the playable map once more. You’ll probably have to split some skybox displacements into smaller chunks (as I did) to accomplish this. So our addition is complete and everything blends seamlessly together again; but our 2D skybox brushes still use the old map boundaries. To fix that, we’ll go back into Compile Mode: And edit the skybox brushes to include our new addition: And we’re done! No guessing, no approximating, no trial and error, and no dealing with the 3D skybox; just full scale editing as you would anywhere else in your map. Now go ahead and run AutoSky, or if you’re planning to make any other skybox changes, just run it before your next compile. So long as you keep your AutoSky visgroup intact from this point on, making changes to your skybox will be just like editing the actual map! Conclusion So, you should now be acquainted with all the ways you can use AutoSky to optimize your 3D skybox design/management workflow, from creating a skybox for the first time to keeping it updated throughout development. The case study we looked at was pretty basic, admittedly, but it should paint a pretty clear picture of how you can apply this strategy to more realistically-sized projects. As a disclaimer, I know I’ve made a big deal of “leveraging the maximum efficiency possible” out of AutoSky and “never setting foot in the skybox again” throughout this guide, but that’s just my emphatic attempt to make your life as easy as possible. If you’d prefer a more manual approach, you can tell AutoSky to export the skybox in an isolated VMF, not replace models with their skybox equivalents, and/or not copy your fog_controller’s settings to the sky_camera. Or maybe you just like the manual aspects of 3D skyboxes, in which case you can not use AutoSky at all! The world is your oyster. Also keep in mind that AutoSky is in beta as of the writing of this guide, so there will probably be some nifty new features and bugfixes to come. Anyways, thanks for reading! Please leave any questions/suggestions about the guide or AutoSky in general below, and try to direct any issues you find with AutoSky here.