City 17: Episode One MOTY Update | Day Two news

Like previously mentioned in our day 1 update we've spent a great deal of time this year going back and revamping areas thanks to some of the headroom we've managed to squeeze open.

This sort of larger goal we've had with City17 is improving the visual quality as best we can. Taking advantage of what the Orange box version of Source shipped with, and more or less exploiting that to our needs and wants. The majority of those shipped features and enhancements has mainly contributed straight to either performance, lighting and shadowing, and shaders galore. One of the more mysterious pushes we've been working on lately is a combination of not only hardware advances in the past years since Orange Box shipped in 2007, but something the OB engine version also shipped with: Slightly better model rendering performance.

That budget isn't going into new weapons, or higher poly npcs, but straight into the world where we feel it really belongs. It’s a change we've made we’re really happy with. In terms of how much it’s pushed City17 EP1 away from the flatness of the standard City17 art aesthetics, while maintaining a level of performance we’re also happy with. Performance had been a pretty big issue a lot of fans worried about. We commonly saw "How will it run" pop up in every update. Today we wanted to show fans what we're doing about that issue. We've learned some neat tricks along the road on developing City17, and as well, wanted to share some of them to other modders out there.

We’d like to think of it as a total conversion approach, without fully going total conversion. We've taken on the task of replacing a decent amount of stock content so we not only can we achieve cheaper rendering costs, but richer environments overall.

Some of those additons are creating completely modeled out building geometry:

One of the biggest things we’ve learned is that window models get expensive fast. For us that’s double the quick because we’re already rendering god rays. God rays redraw the world to understand whats opaque, and whats translucent. Sadly we can’t selectively draw certain parts of the world. If the sun is visible, so are our sun rays, and that means the world is being drawn a second time. You can consider it like doubling the cost of a single window model. In a type of example, its current triangle cost goes up from 20 to 40 instantly.

Thats not even the end of it yet. We also have projectedtextures, which are more commonly know as the flashlight. These entities cast real-time shadows, by (you guessed it) redrawing the scene again based on their casting distance. So this isn’t as expensive as rays, but it does double the cost of what is within it’s casting range. Generally that's around 25x25x25 feet in front the player. So now we’re drawing the world twice now and then, AND that's STILL not even it yet. The player can turn on his own flashlight at any given time, re-rendering that same scene again.

What was once 40 triangles can now be considered 120. On average there are about 30 windows visible on a building’s face. Each one is decorated with a window prop. That’s generally about 400-600 triangles just on one single building face. This is added on top of the other scenery we’re already rendering, including NPCs.

One of the greatest advantages of having windows as models is that we no longer are constrained to the repetitiveness building textures provide. We’re still limited in terms of how many variables of windows we can have visually. We’d like to keep them light on overall texture memory.

Before, we would have to place walls, and cut them up every 128 units vertically if we wanted to have a different set of windows per each story of the building. This was still fairly cheap, but the largest cost went over to brush rendering. We still use a slight variation of the previous method to change the borders and trimming now and then, but because we can place windows anywhere we no longer have to worry about using the textures we did before. Now we can use versions of the building textures that are windowless and save on texture memory. Secondly because we can now place windows anywhere we don’t have to worry about splitting up brushes. Brush cost goes down and the cost transitions over to the GPU rather than the CPU which is always going to be faster for this kind of a job. We fade out all the window models at certain distances, so that keeps rendering overall fairly cheap.

The triangle count is still fairly high per building face. City17 is all about the debris and destruction though. Where one triangle count is high; it’s likely it’s way higher somewhere else. Higher than it honestly needs to be. 600 triangles per building face seems like a lot, that's also 600 more per building than what valve maps shipped with. We’re still reaching a higher cost than general, but here's where that got better; Part of the “replacing stock content” goal came in the form of this little guy:

He’s 1411 triangles. Yes. 1411. We often had at least 6-12 of these guys rendering at once, much like valve did. But we had a few problems with this model:

• It was really expensive for it’s size. It’s a debris pile with a radius of 256x256x32.
• Because of its height it didn’t cover a large area and often we had sections that where beyond 512 units in length that would require multiple instances of this single model, resulting in a decent triangle count in that scene.

So we didn’t remodel it, and we still use it for variety now and then, but we sure did replace it:

That pile is a single model but it’s tons cheaper than the previous model. How cheap? 578 triangles, yes that's right 578. Not only do they cover a wider area, but they are less than half the cost of the previous model mentioned. We can have two of these newer models in place of the older ones; end up having way more detail and still less cost than before. These ended up being so cheap we opened up a huge headroom in the overall budget we had, allowing us to afford more detail overall while still being able to afford sun rays and flashlights in the scene.

An added plus with these new models is that we are directly baking high poly detail to the geometry, as well as computing AO onto the texture sheets. Valve debris models had no normal maps or AO sheets.

Another half of improving the overall visual quality has been mostly textures and added effects. This also includes new particle effects, and particle systems for general world atmosphere. We've also gone as far as to record entirely new sound effects.

One area we aren't hitting a budget limit is general texture memory for both world geometry and special effects (shaders excluded). We actually have a huge headroom there. During the Summer we've been art passing more of our older areas, bringing them up to a single overall consistency both visually and performance wise. Some of the areas to get a major asset overhaul has been the subway tunnels early on in the game.

Before

After

Before

After

The majority of our geometry in most maps are made via displacements. We've started doing this because not only are displacement faces cheaper to render, but also allow us to paint directly onto them, versus using decals and overlays like we had in the past. While we won't get as much variation as decals and overlays gave us (of course we still use them) we save pretty big here because we suddenly aren't rendering a ton of overlays per frame just to have some dirt stains on the ground.

Particles and Particle Systems

New textures and effects also include revamped particle sheets, such as better fire systems (fans hated it before, we listened):

Smoke Shader

Other fog and smoke effects consist of new shaders or particle systems. Previously we created entire particle systems simulating atmospheric smoke effects, or for "fake fog". That method got expensive pretty quick, because not only were we doing extra particle rendering for some basic systems, but we also made overdraw an issue to concern about.

Instead, we created a shader that procedurally simulates smoke movement handled and instanced entirely by the GPU. The shader works by taking two textures, reading the green channel of those textures, and using them to offset and warp the uv of a diffuse. We apply this effect onto two diffuse textures, scroll the two, then apply a mask for transluceney over the entire effect. Because of 4 effects scrolling and being affected by alpha, the effect is always unique.

The effect became so useful we ended up using this shader for a ton of effects. The warping section of the shader is currently used in a few shaders we'll show off tomorrow, but a few for instance are ffects such as:

• Simulating water pushing around objects resting on the waters surface, such as leaves
• Dripping or leaking water along a surface
• Liquids in general
• Smoke plumes
• Combine Field effects
• And a ton more

The warp aspect completely replaces most of Valves stock scrolling effects. The cool thing about this shader is it's really really cheap. We're doing all the heavy computing on the GPU, and only using the CPU to render whatever surface the shader is applied onto (in this case the objects Polygon's. We also stay relatively cheap on texture memory because we are only using the green channel of the warp textures to effect the uv of the Diffuse. Overall this effect costs as little as rendering a scrolling texture.

Thats all for today! Stay tuned for another update tomorrow! Follow us on Twitter for updates on what's going on in development, as well as our blog for City 17 and other development news from us. If you'd like to get in contact with us, be sure to email us at mrtwovideocards@gmail.com.