I sometimes get requests for two features:
- The ability to use more than one texture per OBJ.
- The ability to not use a texture per OBJ.
My answer to both is the same: one texture per object forever!
The issue with the first request is simply framerate – see my previous post on the “crayon rule”. X-Plane has to do a certain amount of setup work for each OBJ it draws. Therefore we have two ways to implement multiple textures per object.*
If we want to obey the crayon rule, we would draw the parts of the objects that use the first texture first for all objects, then change textures once and draw the second texture. But this isn’t so good – if you are using polygon offset or translucency or any other feature that requires the object to be drawn in order, those features won’t work. Also we do a certain amount of setup work per object – we now have to do that work twice! This is about the same as doubling the number of objects. Ouch!
Or we can disregard the crayon rule and change textures once per object. That would be performance death . No optimization has more impact on framerate than minimizing texture changes! This is why X-Plane keeps moving from multiple textures to one texture – in both airplanes and objects! We do it for speed!
So that’s why we require one texture. But why not zero textures? Well, there are a few issues with allowing untextured objects:
- The request for an untextured object almost always includes a request to use colors on the object instead. This would actually possibly be slower, not faster. Color information is twelve bytes per vertex, while texture is only eight. Each vertex per object is now 32 bytes, a wonderful power of 2 that happens to be very efficient on certain modern hardware. With color we hit 36 bytes. Ouch! Remove the color (not useful anyway) and we have 24 bytes. (Why not use 4-bytes instead of 12 per color? The hardware works better with color as floating points, not bytes – surprising but validated by performance testing.)
- X-Plane would have to take time off from drawing to turn texturing off and then turn it on again. So unless we’re going to stop texturing for MOST of the sim, this “state change” hurts us.
- The actual process of drawing with a texture is basically free on modern hardware. Either the chip has dedicated hardware to do the texturing that would be idle otherwise or, if it’s a pixel-shader chip, the ability of the card to texture is so far ahead of what X-Plane needs that the issue is moot.
So we don’t allow color-instead-of-texture because it would be slower! Instead simply make a small “color palette” in your object texture and use that part of the texture stretched over your object to make your colors.
We do allow you to tint your object with ATTR_diffuse, but do not do this! The performance of the diffuse attribute is way worse than using a bit of your texture for color. ATTR_diffuse only has one legitimate use – paired with ATTR_emission to allow for the creation of objects that are self-lighting in low-light daytime conditions. I will post about this in a future entry.
* For OpenGL geeks: technically with pixel shaders you could bind multiple textures simultaneously and write a shader to select one, perhaps by mapping ST coordinates from a virtual texture space. So perhaps someday when we require pixel shaders for X-Plane and they are ubiquitous we can re-examine this.
I’m sitting in a lab at Apple with Austin; that screenshot is X-Plane 835 running on a 2 ghz DuoCore Intel Macintosh in a 20-inch iMac, 512 MB of RAM. That’s 25 miles of visibility, insane roads, mega-tons of objects, 30 fps.
One reason why X-Plane runs so fast on the new iMacs is that the graphics card is an ATI X1600 – that’s a big step up for the iMac.
When will the Universal X-Plane be available? I can’t say yet but we are making progress!
Quick note: the region system will go in a later version of X-Plane, not 8.30. It’s coming soon though! I will try to post a spec soon…I am way behind on my documentation.
Anyway, the “Crayon Rule”: the worst thing you can do for frame-rate in X-Plane is change textures.
The name comes from a conversation almost three years ago when Austin explained to Sergio the cost of changing textures like this: drawing in OpenGL is like drawing with a crayon. Changing textures is like going back and getting a different crayon. It’s a lot faster to do all the red in your picture and not have to change between red and blue crayons all the time.
The crayon rule continues to hold true and it’s understandable why:
- The texture you are using to draw is usually in VRAM. But the texture you are changing to could be in physical RAM (and must be transferred to the card), or worse it could have been paged out and must come from disk.
- The drawing pipeline must be stopped and reconfigured with the texture change.
- These things involve the host machine and CPU. Graphics cards are getting faster but CPUs are not – at least not much faster. So while the new graphics cards will be able to draw twice as many triangles, they will not be able to change textures twice as fast. In other words, we’re stuck with the crayon rule for a long time.
The crayon rule is why Austin and I insist on using one texture per object, and always recommend that you use a few large textures rather than many smaller ones. Fewer textures means fewer texture changes.
So the big things you can do as an author to obey the crayon rule are:
- Use fewer large textures instead of many small ones.
- Group your polygons that use the panel texture together – switching to the panel texture is a crayon change.
The crayon rule makes it more difficult to make scenery, but that extra effort has a huge payoff in framerate.
“Scenery load is now twice as fast!” Where do Austin and I come up with these claims? Here’s a little bit of info on on our performance tuning process.
When we work on performance, we always measure a baseline metric and then look at this metric while we work on the code. The test situation must be the same every time, so usually we use a standard plane position (like on a known runway) for framerate, or a known scenery box (for scenery loading).
Here’s the statistics for X-plane scenery load before and after tuning the DSF loader:
Before optimize
DSF load time: 2297036 for file +33-119.dsf
DSF load time: 4614647 for file +33-118.dsf
DSF load time: 4251205 for file +33-117.dsf
DSF load time: 5137940 for file 34-119.dsf
DSF load time: 5038098 for file +34-118.dsf
DSF load time: 3893140 for file +34-117.dsf
After Optimize
DSF load time: 1634270 for file +33-119.dsf
DSF load time: 2156187 for file +33-118.dsf
DSF load time: 1882647 for file +33-117.dsf
DSF load time: 2418666 for file +34-119.dsf
DSF load time: 2318480 for file +34-118.dsf
DSF load time: 1819997 for file +34-117.dsf
These numbers are not normaly visible; a special sim option available to us causes it to print the load time per DSF. The nubmers are in microseconds and shown per DSF.
So on immediate inspection you can see improvements of between 140 and 205%. But to really understand what this means you have to consider all of the fine print:
These stats are with objects and roads turned off – this is with scenery on minimal settings in both cases. With more 3-d stuff turned on, the overall loadtime might be better or worse; these statistics don’t tell us anything about that.
These tests were done on the same 6 DSFs in both cases, but other DSFs might have different improvements. You can see that even in the six DSFs here the amount of improvement varies a lot!
These tests were done on my dual 1.8 ghz G5. This is a fast machine for a Mac (but probably only average compared to modern desktop PCs). The speed-up could vary on other machines that don’t have similar performance characteristics, since scenery loading depends on the speed of the CPU, memory bandwidth, I/O performance, etc.
This is all a long-winded way of saying “your mileage may vary”. When Austin and I post performance numbers, they are calculated in strict test conditions with all variables controlled. But since these statistics represent one datapoint, they are not universal changes, just indicators that our code changes are going in the right direction.
(Could it be that an optimization makes a difference on our machines but not yours? Yes – this is always a risk! We try to run on different machines and we listen to user feedback on performance to catch this case.)
Scenery loading has changed a lot in 8.30. Before 8.30 we loaded 6 scenery tiles (DSFs or ENVs) and completely built them up into memory before we let you fly. We then loaded any new texures while flying. The result is a possible hit on framerate right after a scenery load for textures, and a very long pause while the scenery area gets built.
In 8.30 we now read the full DSF and build the terrain, then start the sim running. We then build the local 3-d “clutter” (objects and roads) while you fly, but we only build up the ones near your plane. As you fly, the ones behind you are destroyed and new ones in front of you are built.
This means a few things:
– Shorter scenery pauses, because we have to do less before we can start the sim.
– Lower framerates right after a load because the sim is doing extra work while you fly to finish the load.
– Lower framerates occaisionally while you fly as a few more roads are built and objects destroyed. This is pretty minimal though because these items come into range gradually.
– Lower memory usage, since only the roads nearby are fully built, not all of them.
This strategy works out particularly well for people with dual-processor or dual-core machines; some of the work to do this “clutter-building” is done on the second CPU while you fly, so the framerate hit is a lot less noticable. Basically we are taking work that was done by the main CPU while you waited and doing it on the second CPU while you fly.
One problem still in 830: when you place the plane, we do not pre-build the roads (but we DO pre-load the textures). If we did not preload the textures, you would be placed in a gray area and see the textures come in. So hopefully in a later beta I will preload the roads if you place the plane using the airport-picking dialog box. This should help provide good framerates as soon as your plane is placed.
I’ve received a few emails requesting recommendations for graphics cards…unfortunately I must admit: I do not know which graphics cards will improve framerate the most. The benefit you get from a new graphics card depends on the other components of your system. Also I haven’t tried every graphics card so I don’t have good hard data.
I will suggest this generic advice though: for nVidia cards try the 6600 or 6800 rather than one of the FX series cards. For any card, make sure it supports DX9 pixel shaders (for nVidia this means a 5000 or 6000 series; for ATI this means 9500 or greater, or an x600 or greater). I would not recommend a card with HyperMemory or TurboCache; these schemes use your system memory as VRAM. The cards are cheaper but the performance won’t be as good as real RAM.
I’ve also received questions about settings for the best framerate. If X-Plane 821 is fogging up with the new scenery, 830 may provide some amount of relief; we’re working on performance optimization. I can’t say how much improvement we’ll get, but I would recommend waiting for 830 before evaluating your hardware for an upgrade.
There is one setting that can really help mid-level systems: the “world detail distance” rendering setting. If you can run with a few objects, try changing it from ‘default’ to ‘low’. This will cause objects to disappear sooner as you fly away from them; because the sim will not draw as many objects in the distance, you may be able to turn up the object density. In otherwords, you can trade off the density of near objects vs the density of far away objects.
(Also beware of textured lights; they really impact framerate heavily.)
Let me commit this to writing: I WILL get new tools (DSF2Text, AC3D Plugin, etc.) out this week!!
The rendering engine has been taking up all my time this week. To give you an idea, I spent part of the weekend and Monday rewriting the way we handle physics interactions between the simulator and the graphics rendering engine…only to find the new code improved framerates by…one frame per second!
When I complained to Austin about this he said, “good, I’ll take every one fp I can get”, and I realized…this is how we make progress forward. If after a week we’ve got a 5 fp boost, that’s definitely a big help to a user who is getting fog now.
(Of course, not all fps are created equal; a frame per second is the reciprical of the time the sim is taking, so a 1 fp improvement when the sim running at 20 fps is a huge victory; a 1 fp boost when the sim is running at 90 fps is negligable.)
