Torgo 3000

A change of direction... sort of

torgo3000 — Mon, 13 Apr 2009 23:41:00 GMT

Well folks, I'm still employed at MS (or rather re-employed at MS after having been canned with the rest of the group). And I'm working on an as-yet-unannounced project. So as long as the muzzle is still on, I'll try to cover some FSX stuff and some general technical art stuff. I don't know how often I'll be posting (it's not like it can be any less frequent than it has been in the past ; P ) but I will try to get some useful information out there about making art for FSX or making art for games in general. I've been doing a lot of shader writing recently, which I am really excited about (expecially now that the years of legacy code and requirements for supporting backwards-compatibility restrictions have been lifted). It's been very freeing to be able to write a shader that does something incredibly ridiculous like use 5 separate world space cube-map lookups (diffuse w/ alpha, normal, specular, reflection and refraction). Whether a shader like that would actually ever be used in production is totally beside the point. It's just nice to see something really cool in the viewport, because there's always a way to optimize and make something almost as cool for half the performance cost.

I will say one thing. Performance is about priority number one from day one on the new project. I definitely learned my lessons from FSX. Creating a flexible content-driven shader system when there is already mountains of legacy content not necessarily authored specifically for that system, and no time to go back and touch every single asset is a BAD idea. If you're in games and you are carrying forward legacy content and you decide to change your shader or draw system, make absolutely sure you can either touch manually or at least do some kind of scripting pass on every piece of content. Better yet, design a schema-based extensible shader system right from the start that can handle creating new values with defaults.

Maybe my next post will be a performance post-mortem on the Flight Simulator engine and content system. If you've got topics you'd like to get info on, feel free to post in the comments, I'll try to cover them. And when I can talk about what I'm working on now, I'll let you know.

A really great look at performance in FSX...

torgo3000 — Tue, 18 Nov 2008 23:35:00 GMT

Lotus has a really great post about aircraft performance in FSX. I highly reccomend reading the whole post. It's a bit technical, but does put into practical terms a lot of the ideas about how to create performant aircraft (especially for multiplayer). Draw calls are not always the single performance killer and reducing draw calls is not a silver bullet for creating objects that perform well in the engine. I talk a little about this in my "When is a draw call not a draw call" post. Lotus does a really great job of showing practical numbers from existing addon aircraft.

The reason for some of his findings has to do with what is being updated and sent to the GPU from the CPU. If each of the draw calls in an aircraft is close to 65,000 vertices, then each draw call is sending almost an entirely full vertex buffer update to the card every frame. While it is still only a single draw call, it is a huge amount of data being sent across the pipe. So 35 draw calls with 1000 vertices each does not equal 35 draw calls with 60,000 vertices each. And if you are using poor UV and smoothing techniques, then it is very easy to get a 25,000 polygon model close to that limit for each draw call.

Another comparison I'd love to see is the animation hierarchy in the aircraft. An aircraft can be skinned and have 15 draw calls, but have 10 parallel animation hierarchies that are each 20 levels deep. The amount of data needing to be updated during each frame becomes gigantic (something on the order of 2100 matrix transforms per frame). If that same aircraft were animated with a flat hierarchy (not always easy or even possible to do) it would have about 200 transform matrix updates each frame.

All in all, it's a great post and a very informative read. Excellent work, Lotus!

Jetway IK tutorial

torgo3000 — Mon, 09 Jun 2008 20:48:00 GMT

I captured a tutorial about creating a Jetway using our IK system and Gmax over a year ago. Due to software weirdness and a general lack of time, I was unable to render the video out. However, thanks to Nick Whittome (a genius at getting me to do stuff and a prodigy at helping me out when I can't get it done on my own), the video has been rendered and is now posted at the FSDeveloper website. You can grab the video directly from this link. Extra special thanks to Nick and Arno for getting me to do this and providing a place for it to live. It's a little improvised, so if you can sit through some "Ums" and "Uhs", there's decent content in there.

I also see that Nick has posted requests for future videos. So hopefully I can get through some others over the coming months / years.

New Acceleration Pack missions.

torgo3000 — Fri, 30 May 2008 01:54:00 GMT

We just released three new multiplayer racing missions for Acceleration on FSInsider. I haven't tried them out yet, but I hear they're a lot of fun. Plus, you can't beat the price!

SDK MaxScript tools.

torgo3000 — Mon, 19 May 2008 21:49:00 GMT

There has been some confusion about what tools will work with which version of 3ds Max and I hope to set the record straight today (for those who might be using our SDK and 3ds Max). In general, the SDK tools that were released for 3ds Max for FSX and FSX Acceleration (FSX SP2 SDK) were created and tested on 3ds Max 9 32-bit on 32-bit XP. Since then, most of us have switched over to 64-bit Vista and are running 32-bit 3ds Max 9 on that platform. All of the above configurations are supported. Unfortunately, at this time, no 64-bit versions of 3ds Max are supported. Additionally, 3ds Max 2009 is not supported at all (neither 32-bit nor 64-bit). 3ds Max 2008 32-bit (on XP and Vista) should be supported, but extensive testing has not been performed yet.

Here are the supported setups:

32-bit XP with 32-bit 3ds Max 9
32-bit Vista with 32-bit 3ds Max 9
64-bit Vista with 32-bit 3ds Max 9
32-bit XP with 32-bit 3ds Max 2008 (Supported, but not fully tested)
32-bit Vista with 32-bit 3ds Max 2008 (Supported, but not fully tested)
64-bit Vista with 32-bit 3ds Max 2008 (Supported, but not fully tested)

The next SDK we ship will support whatever the most recent version of 3ds Max is at that time (we will likely try to support a version or two back as well, but at this point no promises are being made). Addtionally, we are still working on the alternative solution to Gmax.

Having said all of that, I know that the MaxScript tools shipped with FSX SP2 were a little buggy. My bad (though I will say that the fact that I was the sole designer, developer and tester on the MaxScript tool suite pretty much guaranteed a certain amount of failure ;) ) I am making a real effort this time around to make all of the tools work as well out of house as they do in house. We also have more resources dedicated to guaranteeing a better user experience for developers. As far as MaxScript tools are concerned, my philosophy is if we can use it in house, then you should be able to use it equally well wherever you are.

Cool new things...

torgo3000 — Wed, 19 Mar 2008 21:22:00 GMT

I must say, I am really excited about where we are heading as a team in terms of tools and content creation pipeline. I think we've finally gotten on track. And by "on track", I mean we're actually on the rails. We may still be sitting in the station, but at least we aren't wandering around in the weeds trying to figure out where the track actually is.

I can't promise or disclose too much, but I will say that there are some really cool things happening in the studio right now that we hope to make available to 3rd party developers as well as SDK users. In terms of Digital Content Creation tools, I am making a serious effort to try to expose all of our in house tools to 3rd party content creators. Ideally, you should be able to use a tool out of house exactly how we use it in house. We haven't made that effort much previously, but we are definitely focused on it now. ESP really helps to be a driving factor in terms of tools and pipeline. For 3rd party developers on our entertainment products, I think you're going to see some serious improvements in our SDK thanks in large part to the development of ESP.

As for the "Gmax replacement issue", I can't say much about that right now. It's definitely on our mind and something we are striving very hard to make happen. I'll try to keep you updated as much as I can here. Also, be sure to go to the FSinsider developer's corner as we are updating that more regularly. Additionally, the FSDeveloper site is a great place to gather and share information.

Let's blow up the exporter real good!

torgo3000 — Fri, 25 Jan 2008 00:39:00 GMT

I first came across our vertex limit issue when trying to debug the export of the trike model. For some reason when we tried to export the Aircreation, it would continously throw up errors about exceeding the max vertex limit. Huh? We'd never run into this problem before. Why were we suddenly seeing this?

Well, in our quest to up the ante in terms of visual quality, we ended up creating a model that exceeded the 65,000 vertex limit for a single draw call. "But it's only got 27,000 polygons and 15,000 vertices!" we thought to ourselves. What we didn't realize at the time was that a) Non-perfect UV mapping and smoothing can convert single vertices in 3ds Max or Gmax into many vertices on the graphics card and b) in the quest to reduce draw calls, we had actually run into one big draw call. Too big, in fact.

So lets look at issue a). At first blush, the polygon and vertex count should not be an issue at all. One of our vertex buffers can hold roughly 65,000 vertices. The trike should easily fit into one of those. However, as we started to look at the UV mapping and smoothing, we realized that we were indeed exceeding the limit after processing. Everywhere there is a seam in the UV map, those vertices get doubled on the graphics card. If it is the corner of a seam, they get tripled or more. The way this particular model was UVed, it had very unique seams around most of the geometry. This resulted in a whole bunch of the vertices being doubled or tripled. So now our vertex count was around 30,000. Additionally, every vertex that is on the edge of two smoothing groups also has to get doubled, tripled if it is one the edge of 3 smoothing groups. And not all of the UV seams lined up with smoothing seams. Suddenly our vertex counts were upwards of 40,000 to 50,000. Oh, and we also had a bug where objects with normal maps were passing double the vertex counts. Oops, now we had exceeded the 65,000 vertex buffer.

Which brings us to issue b). In our quest to reduce draw calls we had created a single texture sheet for the Aircreation. So now the entire model was being fitted into a single vertex buffer, which it couldn't fit into.

So how did we solve the problem? Well, once we animated some parts, that broke up the draw calls. Also, once we applied some different materials with different parameters, that also broke up the draw calls. So if you're trying to export a model with 100,000 polygons and you are running into the vertex limit, first of all, shame on you. ; ) But I know, it's fun to push the limits, so after getting over the initial shame, if you want to load huge models into Flightsim, you'll have to make sure that they are broken up into consumable chunks. So even if you want the same texture and material, you may have to create a second material and change specular power to be 56 instead of 55 (or something minimal like that) and apply it to half of your gigantic model. Then it will export as two draw calls and fill two vertex buffers.

So now you ask "Why didn't you automatically break up huge objects along vertex buffer seams so we don't have to do this hack?" Well, unfortunately it was one of those things we just didn't get to. And I'm sure you'd rather have a new sim engine or graphics feature than an exporter feature that has a simple work-around, right?

Hmmm... er, what?

torgo3000 — Fri, 25 Jan 2008 00:32:00 GMT

There seems to be a consensus amongst people I know (based on highly scientific poll results of course) that 2007 was one of the most strange, stressful and just plain bizarre years on record. Maybe it's just that all my friends are hitting their mid-thirties and freaking out, I don't know. At any rate, after a much needed hibernation on top of a not-so-much needed year of chaos, disorder and growth, I think I've finally got the cobwebs out of my brain and am ready to start blogging and being active again. So consider this the first shot across the bow (and no, it probably won't be a machine gun shot, more like a muzzle-loader, but at least it's a shot). I'll follow this up with a post about our exporter and how you can blow it up real good.

Performance Art 4: Always use a texture and bones ain't free.

torgo3000 — Mon, 17 Sep 2007 21:15:00 GMT

For this issue of the ever-continuing "Performance Art" series, I'll talk a little about flat-shaded or colored polygons and the use (or overuse) of bones in a model.

Always use a texture:

In the past, when the memory on graphics cards was very small, we tried to save texture space by flat-shading or assigning a single color to groups of polygons. This provided color information to parts of a model that didn't need the detail of a texture and saved memory in the process. However, with the advent of pixel shaders and graphics cards with a gig of memory on them, this is actually a performance killer now. The reason for this is simple, every unique color is a new constant switch. And every constant switch is a new draw call. So those 100 flat shaded objects in our models that we thought would save texture space are now actually causing 100 new draw calls. Sure, they're cheap draw calls, but they are draw calls none the less. So how do we fix this problem? Simple. Save a small space in the texture sheet to have 4x4 blocks of solid color. Anything that needs to reference that color, simply take all the UVs for those parts and shrink them way down to fit in the center of that 4x4 block (with room on the edges to compensate for mips). Voila, it's still a single draw call and you get the benefit of saving texture space since you're only using the equivalent of a 64x64 texture sheet for a full 256 colors. That can easily be fit in the gaps of a standard 1024x1024 texture sheet.

Bones Ain't Free (especially not ones in a big 'ol hierarchy)

Bones are a wonderful thing. They allow us to do animation on the vertex level without having to store transforms for each vertex in a mesh (anyone want to try storing matrix transforms for 1000 vertices? Okay, I know, you can do it in a texture, but that's out of scope for this discussion and still not free!) They also allow us to combine disparate animated parts in a model into a single draw call. However, there is a cost to having bones in a model. The hierarchy must be traversed recursively for each update for each frame. If you have a single node or possibly two in the hierarchy (like is the case for most of our autoskinning), then this is relatively cheap. Update parent node, update child node with parent's transforms, update child node with child's transforms, draw. 3 transforms and a draw. Well adding a single node to the chain drastically increases the complexity of the updates: Update parent node, update child1 node with parent's transforms, update child2 node with parent's transforms, update child1 with child1's transforms, update child2 with child1's transforms, update child2 with child2's transforms, draw. It's a geometric progression that goes from 3 updates for 2 bones to 6 for 3 to 12 for 4 to 24 for 5. And that's every frame. I've seen some third party add-ons that have literally hundreds of bones, many with hierarchies 3 to 6 bones deep (and sometimes more). That's great for saving draw calls, but not so great for performance overall. That would be the equivalent of making an aircraft that has every single Half-Life 2 character you might see onscreen at once as the wings. And that's only one instance of that aircraft. Imagine multi-player...

Hopefully this helps. Keep your hierarchies simple and make sure to always have a texture. We let out a lot of rope with this version of Flight Simulator. As you watch us swinging from it, please listen to what we've got to say, that way only one of us has to hang.

First preview of Acceleration

torgo3000 — Thu, 12 Jul 2007 20:33:00 GMT

Gamespot put up our E3 preview video for the Acceleration expansion pack for FSX. You can watch it or download it.

Enjoy!