Plugin-Based Prop Discs

I was discussing plugin-controlled prop discs with a third party developer. The developer wanted to know if custom prop disc control would end up inside Plane-Maker. It may end up doing so, but I don't think this would be nearly as useful as it would seem. What follows is my explanation to him of why this is.


Let me draw an analogy: when it comes to systems modeling, using a plugin is to Plane-Maker as using Blender is to using Plane-Maker.

Users who cannot use Blender are frustrated because they cannot make something as nice as those who are building planes out of OBJs. Sometimes they ask for more features in Plane-Maker, like: more stations! This new editing mode! Make the UI better!

But...you tell me: will Plane-Maker's UI ever be as flexible and powerful as Blender? And if it ever did get to be that good, would that have turned out to be a good use of LR's time, when Blender is already available?

The motivation for OBJ-based airplane geometry via third party tools is that what users want to do cannot be easily generalized into a few simple cases. Every plane is different, so a truly flexible platform is needed.

The prop disc (and other systems modeling problems) are the same way. In developing the prop disc graphics, I spoke with a number of third party developers who had already tried to push prop discs as far as they could go, were using plugins, were drawing themselves, as well as 25 other crazy hacks. I also spoke to our internal art team. And what I found was: no one had any consensus on how the prop disc system should work. Everyone wanted to tune a very specific set of behaviors to their peculiar art assets.

That's what drove me to put it into a plugin. When we need an equation or a strategy we reach the point where we need more flexibility than Plane-Maker can exhibit. A plugin can encapsulate a strategy or technique in a way that Plane-Maker radio buttons cannot.

Consider what would happen if custom prop disc parameters were built into Plane-Maker. Everyone would have to wait until Austin implemented the prop disc algorithm they wanted. How would this be bad? Let me count the ways?

1. How many algorithms do you think Austin has time to code? Not more than he has fingers on his right hand. Only the five lucky third party developers who get their algorithm coded will be happy with this.
2. Austin code exactly what you want? Don't get your hopes up.
3. , what you asked for wasn't what you wanted? We can't change the behavior now, that would break compatibility!
4. oh...your email got eaten by a spam filter? Too bad...no custom prop disc for you!
5. Sorry, we don't have a release vehicle lined up for the next 3 months. You'll have to wait.

This problem is already happening across pretty much every aspect of systems modeling: airplane have unique, quirky systems which are usually useful for exactly one plane. It is not even remotely sustainable for X-Plane to code these things one at a time with a set of check-boxes. We might as well have a pop-up menu for every airplane ever invented, and simulate every single airplane inside the sim itself. Imagine the development costs...if a single high quality MSFS add-on sells for $30-$50...

Think of the prop disc via plugins situation (and the strobe lights are the same way) as an experiment in generic instruments for systems. By transitioning to a generic abstaction for instruments we've let a lot more users do exactly what they want with a small, high performance piece of code. The original instrument strategy (one of everything) reached a point where we simply couldn't meet user needs in a cost-effective manner.

Additive Lighting Does Not Require Alpha

In X-Plane there are two fundamental ways that a texture can be painted "over" a background image:

1. Blending, whereby the alpha channel of the new top layer decides how much we see the top layer vs. the background.
2. Additive Lighting, whereby the new texture makes the background lighter.

Blending is more common. For example, if you build an OBJ, the object appears "in front of" the terrain via blending. With blending, you put the color of your new layer in the RGB channels and use the alpha channel to indicate opacity. 1.0 alpha = 100% opaque, 0.0 alpha = 0% opaque, and alpha in between will create a blend. If you omit an alpha channel, X-Plane will treat the entire layer as 100% opaque.

When a layer is applied using additive lighting, the resulting color is the sum of the background plus the new color, clamped to the maximum brightness we can show on screen. Additive lighting is good for simulating effects that really "add light". Some examples of additive lighting in X-Plane:

• All lighting billboards are drawn additively.
• Instrument overlays are additive if you pick the appropriate mode in Plane-Maker. (The option is labeled "glass" for generics, since most glass instruments work by adding light to a nearly black screen.)
• The emissive (_lit) texture of an object is added to the albedo (daytime) texture using additive lighting.

Now just a little bit of math. In RGB color terms, black = 0,0,0 and white = 1,1,1. So if we add a pure black texture to a background additively we get:

new_r = old_r + overlay = old_r + 0 = old_r
new_g = old_g + overlay = old_g + 0 = old_g
new_b = old_b + overlay = old_b + 0 = old_b

In other words,when using additive light, adding "black" does nothing, preserving the background.

And this brings me to my main point: any time you have additive lighting you don't need an alpha channel. You can simply make your additive lighting texture black for the parts you want to be "transparent".

This is why I generally recommend that emissive _LIT textures for objects not have an alpha channel. In fact, for "back-lit" and "additive" instruments (these are instruments that use a second emissive _LIT texture) Plane-Maker will indicate a warning if the texture has an alpha channel. If you have a texture that is applied additively, you don't need alpha.

At this point you might be wondering: Ben, if additive lighting doesn't require alpha, and all lighting billboards are drawn additively, why the heck is there an alpha channel for custom lights?

The short answer is: there probably doesn't need to be one; the original setup for lighting billboards inherited a number of idioms from older versions of X-Plane, going back to versions where lighting billboards were not additive* (and thus alpha was necessary).

The long answer is: the alpha channel is often as a general "intensity" control to turn the light up and down in amplitude, while the RGB channels are often re-interpreted in strange ways. So while RGBA color is not necessary from a graphics standpoint, it is handy that there are four color channels in the custom lights because that gives us one more parameter to play with when designing really compicated lights (like VASIs).

* Note that lighting billboards that aren't additive don't look very good...hence Austin switched to additive billboards.

Why Does X-Plane Require TEXTURE_LIT?

Back in olden times (read: X-Plane 6) X-Plane would look for file names with special extensions to enable special features. For example, in many cases appending the suffix _LIT to your texture name specified that you wanted a second emissive texture attached to your scenery.*

Then I showed up and started replacing the "find by extension" scheme with specific commands in configuration files to induce special behavior. On pretty much all of the modern text file formats, you need to use TEXTURE_LIT to specify your emissive texture, and once you use this command, you can use any suffix you want.

Why the change? I had three reasons:

1. Features by file naming convention is ugly. That's just an aesthetic decision by me, and most users find file extensions simpler, so if this was the only reason, I'd be a bit of a jerk.

2. File naming conventions don't grow over time. With file naming conventions, additional features would mean truly crazy conventions. Consider terrain files, where any terrain can be loaded with wrapped or clamped edges. (Wrapped edges are appropriate for repeating tiles of "land class" and clamped edges are appropriate for orthophotos.) We would end up with my_texture, my_texture_LIT, my_texture_wrapped, my_texture_wrapped_LIT, etc. What about the scale of the texture? What if we implement seasons? my_texture_2000_2000_wrapped_summer_LIT.png it is.*

   By putting features in text files, we leave room for future expansion, and we have a lot more room to attach data to an image or control shading.

3. Probably most important: going to disk and loading lots of images is slow, so X-Plane loads images in the background while you fly. But checking the disk to see if my_texture_LIT exists is a disk operation too, and it is potentially one that we have to do immediately to understand our art assets. By having information about art assets in the text files and not file naming conventions, we can read one text file, rather than searching for all possible combinations of file extensions.

With X-Plane 9 we're starting to see enough complexity in shading configurations and options that file names would be a non-starter. Consider some of the new features in version 9: normal maps and paged orthophotos. X-Plane 10 will introduce even more rendering and shading capabilities. These configuration options are better kept in a text file than a file name.

* Actually, Sergio and Austin were heading in that direction. Note that the names of the old ENV land classes were in the form CropCool0_000.dds. What are all the numbers? I don't know, but Sergio had a plan to use them to select lots of different textures. This scheme was never implemented.

DSF Will Be Extended, Not Replaced

Austin attended the French X-Plane Congress last weekend; in response to some questions I have received, I want to clarify what is planned for DSF and X-Plane 10.

X-Plane 10 will extend DSF scenery capabilities by providing a number of new art asset types, as well as extensions to existing art asset file formats. We will not be changing the DSF file format or breaking compatibility with existing DSF scenery. If your DSF scenery works with version 9, I expect that it will work with version 10 as is.

(In fact, it looks like we do not even need to add new DSF extensions; DSF was designed to be a generic container for geometry data and properties, so we can usually extend X-Plane's scenery system by simply defining new art asset classes and properties.)

An example will illustrate what I mean by extending the art assets, not DSF.

In X-Plane 9, you create a forest (whether in a base mesh or overlay DSF) by creating a DSF polygon referencing a .for (forest) art asset. X-Plane will render this by filling the area inside the polygon with lots of trees.

In X-Plane 10, you will be able to optionally tell X-Plane to put the trees only on the edge of the polygon, rather than filling the entire inside. (This feature will be controlled by using values on the polygon parameter that are larger than 255, at least I think.) This will mean that you can use .for files and DSF polygon not only to create forest areas, but also to create rows of trees along the edges of roads or fields. A row of trees made by a .for file and DSF polygon will render much faster than a large number of individual OBJ-based trees.

This kind of art asset extension is similar to what we have already seen; X-Plane 850 introduced three new art asset types (.str object strings, .lin line paint, and .pol draped polygons) that all produced new rendering tricks using DSF polygons. These art assets were added to provide high performance rendering of airport surface areas. The new art assets didn't require any change to DSF because the representation of the position of these art assets is something DSF has always done: simple polygons.

DSF won't last forever, but at least for X-Plane 10 it looks like we can do a third full cycle of the sim using DSF as our base container format for scenery position data.

Where Has All My VRAM Gone?

In the past I have suggested that there is a limit to the value of additional VRAM when buying a graphics card. When I posted this, Nicholas from the org emailed me to point out that with third party add-ons VRAM was a lot more important.

At the time I wasn't really convinced, but I've finally come around; it takes a while for the trend to get back to me. (I just don't have time to look at everyone's add-ons the way I used to 4 or 5 years ago.) It seems clear that airplane authors (and to some extent scenery authors) are using VRAM pretty aggressively. If you want to use third party add-ons and you care about texture res and texture sharpness, spring for some VRAM. It doesn't cost as much as it used to, and authors are starting to use it.

What Lives in VRAM

Bear in mind that in any discussion of how your video card operates, anything I post is informed speculation. The driver provides an abstraction (OpenGL) of what the hardware does, and a lot of the bookkeeping isn't visible to X-Plane at all. So what I am describing is typical of past video drivers that we have had insight to in the past, but it's not universal, and it's not at all guaranteed. (X-plane can't demand any of this behavior of the video driver.)

In order of how "stuck" in VRAM things are we have:

• Video memory used for on-screen rendering. Depending on rendering settings you can lose anywhere from 12 to 24 MB of VRAM per million pixels on screen. So if you're running at 1920 x 1200, you might be using 50 MB of VRAM just for the screen. If you use FSAA, you're going to chew up VRAM even more aggressively. (Costs vary depending on the scheme; you might lose 4-16 MB x the FSAA level per million pixels on screen, depending on your GPU and driver.)
  
• Off-screen rendering for things like the water reflections, the panels, the cloud shadows, the airplane shadow, etc. These don't have to be in VRAM all of the time, but they have to be in VRAM almost all of the time. Because they are created by the GPU, the driver tries hard not to move these out of VRAM. You might lose 6 to 16 MB of VRAM for these, depending on the airplane you use and settings. (Given 4 1024x1024 panel regions, the panel will chew up 32 MB!)
• Textures end up in VRAM, but only when they are used. The key here is "working set". Only texures that are drawn need to be in VRAM, so over time stuff that isn't on screen will be removed from VRAM. This is why when you see "600 MB of texture memory" in the rendering settings, there is no need to panic. The working set is usually much smaller.
• OBJ geometry actually lives in VRAM too, sometimes. Again this is a working set issue; objects that aren't drawn don't get cached there.
• Textures from airplanes and scenery packages that are not loaded don't ever end up VRAM or even system memory; we only load what we need. Paged orthophotos have their resolution reduced while you fly, which makes their VRAM footprint quite small, even when drawn.

There are a few things authors and users are doing now that use up a lot of VRAM.

• Monitors have gotten bigger; the VRAM used for the screen itself can never be swapped out, so the advent of the 1920x1200 LCD has taken its toll.

• Since the panel texture is drawn off-screen, the panel texture is in an expensive category of VRAM use. Authors can limit the cost of this by using a single 1024x1024 panel region texture, if possible.

• There is a hidden cost here: we pack together instrument textures into "atlases" to help with performance. The problem is that we pack for fit. Some of your instruments may be hidden but loaded into VRAM anyway because they sit in the same atlas texture as other instruments that are drawn. Thus you may be paying for the VRAM used by your entire panel even if a lot of it is hidden.

• Because a lot of this VRAM is going to airplanes, reducing texture resolution doesn't have as much impact as it used to; X-Plane tries to keep the user's plane's resolution as high as possible since it is viewed up close. The panel cannot have its resolution reduced at all.

But It Works Sometimes

I think what drives users crazy about VRAM exhaustion is that X-Plane will sometimes run smoothly, and then fail later. And sometimes really strange things, like moving X-Plane to the background, then the foreground, or changing liveries or rendering settings in a trivial way, will change performance.

I have discussed this a bit in past posts. But the key here is "working set":

• In any one frame, we can access everything that is permanently in VRAM, plus as much data as we can put through the PCIe bus from the CPU to the GPU.
• We only need to access data in the working set (what is on screen).
• Some of VRAM is permanently used (e.g. memory for the screen itself).
• We lose PCIe bandwidth to both drawing from main memory (terrain is in your system memory and must go over the PCIe bus per frame) and from bandwidth spent juggling textures.

So the actual maximum throughput will have a lot to do with whether the video driver makes good decision about what lives in VRAM and what does not.

But how does the video card know what should be in VRAM? The answer is that it has to guess. It looks at frames going by and tries to use heuristics (that is computer-science geek speak for "carefully formulated wild guesses") to decide what goes in VRAM and what does not. When the heuristics happen to make good decision, your video card kicks ass. And when it does not, your framerate tanks.

The only way to guarantee good framerate is to use so little VRAM that everything that needs to be in VRAM can be in VRAM, without depending on the video driver to make lucky guesses with its juggling.

And this helps us understand why strange things like livery reloads and backgrounding the sim can affect framerate (for better or worse). These operations seriously reshuffle VRAM - either by deleting textures and loading new ones, or by forcing everything out of VRAM so the video driver must try to repack video RAM all over again.

Unfortunately as a user this means that there's not much you can do about this as a user. The main things would be: reduce screen size or FSAA or texture resolution, use fewer add-ons, or get more VRAM. Those peak bursts of framerate you see, they're not going to be sustainable .

REXPlane

REX is here for X-Plane. That's really exciting to me because REX is a very successful add-on to FS X, and it's been understandably difficult for us to convince companies that have a functioning and profitable business model on FS X to jump over to X-Plane, which requires building new capabilities in-house, starting at the bottom of the learning curve, and developing new processes. I hope these guys have a ton of success. Heck, I'd buy the product just because REXPlane is such an awesome name!

What surprises me is that we haven't seen more ports of airport scenery. These packages can be partly converted mechanically using Jonathan Harris' FS2XPlane tools, and in the case of an airport, the potential for recycling is huge - that is, the largest part of the development process is modeling, creating textures, and connecting the two. Since X-Plane can use these art assets with minimal mods, it seems like a very viable type of port.

Water Reflections Use the CPU

A slightly surprising note about X-Plane's rendering settings: increased detail in the water reflections mostly increases load on the CPU! Here's what is going on.

X-Plane's water reflections are a two-step process:

1. A (simplified) version of the world is drawn into a texture .
2. That texture is used (and perturbed) to draw the surface of the water.

The water reflection detail setting affects a number of this: the size of the texture used to draw the world, the level of simplification of the world drawn into the texture, and I think some details about the shader used to draw the water surface itself.

Of these factors, the biggest impact on frame-rate is almost always simplification of the world as drawn into the water texture. At its most detailed ("complete" reflections) that rendering is almost identical to the main sim rendering, and thus reflective water should cut your framerate in half!

In particular, the big hit of drawing the world a second time is that it means drawing objects a second time. Thus the higher the reflection setting, the more objects are being drawn. In a scenario where objects are already the main drag on frame-rate, using complete water reflections will make this even worse.

There are two things to conclude from this:

1. A bigger, faster CPU won't let you turn up the water reflection detail. Most decent GPUs handle the shader-side just fine. It's the objects that are the problem.
2. You shouldn't turn up the water reflection all the way unless you're taking screenshots. It just doesn't add much visual improvement for the fps hit.*

* This is one of those cases where I ask myself: why did I let the setting go up this high?

Draping

I'm trying to post weird in-development screenshots as I get them because, well, sometimes they are entertaining, in a nerdy sort of way.

This is experimental test code for road draping.

The idea will be to let X-Plane "drape" the road over the base mesh, so that an overlay can contain customized roads that work with any base mesh.

The Wonderfully Filthy

From one of the podcasts I listen to I just discovered Edward Burtynsky. He takes these amazing photographs of industrial landscapes - really scary post-apocalyptic images of oil refineries, chopped up cargo ships, etc. Take a few minutes to look through some of the images.

One of the side effects of working on X-Plane scenery for the last few years is that it has made me look a lot more closely at the world. Once you try to recreate the world on a computer (and watch your digital creation fall way, way short) you realize how much intricacy and detail every-day phenomena have.

So when I saw Burtynsky's photos I immediately thought "he sees the complexity and beauty* and sadness of industrial landscapes the same way we do!"

* Beauty? I am not suggesting that the SOCAR oil fields are beautiful, a particularly good idea, or something I want more of. But I think that there can be a poetry in the image - perhaps a poetry of despair.

You Only Have to buy Apollo Once

With the latest updates to X-Plane for iPad, you can now purchase the Apollo lunar lander game inside X-Plane.

A quick note: if you lose your preferences (and thus X-Plane thinks you have not already bought Apollo) you will not be charged a second time if you click "buy it" again. When you go to repurchase Apollo, X-Plane will notice that you already have bought the upgrade and will simply re-enable the update.

Hopefully in our next patch we will make it clear in the UI that there is no double-purchase. The upgrade to Apollo is a "persistent" in-app purchase - once you buy it, you own it forever, as you would expect. (And because the iTunes store has a copy of your receipt, you don't lose it even if your iPad or computer's hard drive gets wiped out.)

Also, the latest update should fix crashes on iPads that were running for a while. X-Plane was very close to the memory limit so iPads that had been running for a while wouldn't have enough free RAM for the sim. The new patch is a little bit leaner to work around this problem.

Why Is My Airplane Slow?

Sometimes I get reports of a slow airplane, and I do a quick audit for performance problems. The trick to spotting performance problems is to divide and conquer: turn off various aspects of the airplane to see which aspect is really causing performance problems, then optimize that aspect.

Here are some of the specific tricks I do:

• Change views; the panel will be drawn differently in the 2-d view, 3-d cockpit view, external view (when close or far - zoom out and the panel won't be updated) vs. 2-d no HUD.

  If the 2-d view is slow but forward-no-HUD is not, your panel is expensive. If the 3-d view is slow but 2-d is not, one of your panels may be more expensive than the other (copy them in Plane-Maker from one to the other to see) or it could be that the preparation of the cockpit texture is slow.

• Remove 3-d objects from your plane to test the cost of OBJs. Turn down X-Plane's texture res or shrink your textures to see if texture memory is at issue. (Some airplane textures are not affected by the texture res settings, so you may have to manually shrink them.)

• Be sure to play with X-Plane's rendering settings; the GPU-specific options don't always cost "the same". For example, per pixel lighting is more expensive when there is more translucency on screen. If your airplane has a lot of overlapping surfaces or translucency this otherwise manageable setting might become too slow.

• If you use panel regions, try switching to regular ATTR_cockpit. Panel regions provide superior lighting effects but can take more CPU time when you have a lot of instruments.

The key is to divide the many possible causes of performance problems to isolate one thing that can be optimized.

Zen and the Art of OBJ 2: Performance

In my previous post I tried to break an OBJ down into a few basic sections:

• Global properties of the OBJ.
• Raw Mesh Data
• Commands, which in turn set per-batch state and then draw the batches.

The performance cost of an OBJ feature often has a lot to do with where in the OBJ the command shows up, e.g. is it global or per batch.

Global properties tend to affect OBJ performance on a one-time basis. For example, if you use cockpit regions, you pay a fairly large penalty for having the panel texture be set up even if you only apply that panel texture to a single texture. Sure enough, COCKPIT_REGION is in the global properties section of an OBJ.

Per-batch properties affect the OBJ in two ways:

• Every command you see in the commands section is going to involve some CPU intervention. A very long commands section is more work for an OBJ.
• Every time there are attributes between TRIS commands, it defines a new "batch" - that is, a separate instruction to the graphics card to draw a new and distinct setup. Think of this as shutting down the factory to reconfigure the assembly line.

Generally batch count is more important than total commands. In other words, in evaluating this:

TRIS 0 300
ATTR_light_level 0 1 some_dataref
ATTR_no_blend 0.5
TRIS 300 12

the fact that there are two attributes is less interesting than the fact that there are two batches (the two TRIS commands run with different state). Even if you got rid of the no-blend attribute, you'd still have two batches because of the light-level change.

The most powerful aspect of the OBJ format is bulk data handling - that is, you have to add a huge number of triangles before the number of triangles becomes a performance problem.

For this reason, you should never use an attribute to reduce geometry count. A few examples:

• Don't use ATTR_no_cull to reduce triangle count - simply issue the indices of the triangle twice.
• Don't use ATTR_flat_shade to reduce vertex count - simply use more vertices with correct per-vertex normals to simulate flat shading.
• Prefer texturing to materials whenever possible.

Finally a note on weighting: for airplanes, where the total number of objects is low (a few dozen) global object properties often matter most. For example, on an airplane, choosing to use huge panel regions, or huge textures can make a big difference in performance. By comparison, batches aren't that expensive unless you do something really crazy.

By comparison, for scenery, batches matter more; X-Plane will share the global properties of objects across hundreds or thousands of objects, but each batch hurts framerate. So when making autogen-style scenery, batches are most important.

Zen and the Art of OBJ 1: The Anatomy of an OBJ

A number of people are working on an update to Jonathan's Blender X-Plane export scripts; this post is aimed at shedding some light on some of the recent changes to the OBJ format. X-Plane 9 introduced a number of new OBJ features (manipulators, invisible geometry and camera collisions, dataref-driven control of emissive texturing, normal maps, and a number of new light billboard options). If you simply read the new OBJ commands in the order they were added to the format, it's just a soup of funny names. But there is some logic to how the OBJ format is extended.

The World's Simplest OBJ

Here is a very simple OBJ file, broken up by my annotations. First we have the header and global section:

A
800
OBJ

TEXTURE great_image.dds
POINT_COUNTS 24 0 0 36

the global section describes properties universal to the entire OBJ. For example, what textures will be used to draw the object?

We picked up a few new global properties in the version 9 run:

• Normal maps are declared globally for the entire OBJ.
• The metrics of any panel regions to be used are declared globally.

We may pick up new global attributes in the future; if we do, they will be properties that apply to the entire obj.

Next comes the data section:

VT 0.449997 0.300003 0.860001 1.000000 0.000000 0.000000 0.000000 0.000000
VT 0.449997 0.300003 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000
VT 0.449997 -0.509995 0.860001 1.000000 0.000000 0.000000 1.000000 0.000000
...
IDX10 0 1 2 3 2 1 4 5 6 7
...
IDX 21

I have removed a lot of the data section, because there's not much to be said about it. The data section contains the raw data for the meshes in your OBJ, and it hasn't changed since the OBJ 8 format was introduced.

The third and final section is the most interesting one: the commands section.

ATTR_LOD 0 3000
ATTR_hard asphalt
TRIS 0 36

The commands section describes how the data is used in the form of serial instructions to X-Plane. Most changes to the OBJ format have come in the form of new commands. We can categorize our commands into a few buckets:

• Drawing commands create "stuff". There aren't very many drawing commands, and new ones don't appear very frequently. TRIS and LINES are the main commands, but the smoke commands also fall into this category, as do the light billboard commands. The new light billboard command LIGHT_PARAM is the only new drawing command for version 9, and it probably warrants its own blog post.
• Attribute commands change how stuff is drawn - they effectively define properties for drawing on all triangles that can be modified. We picked up a number of new attributes: manipulators (controlling how the mouse works), light level control, solid camera, draw disabling, deck style hard surfaces, and panel regions. (While you must declare the panel region locations globally, a panel region is enabled for a specific batch.)
• ATTR_LOD is sort of an exception, because it defines the structure of the model (e.g. a model with LOD really contains several separate command lists, of which only one is used).
  

Most new extensions to the OBJ format come in the form of new attributes. Attributes generally apply to a specific mesh within your model, not to the entire model.

Note that attributes can be thought of as "per mesh" or "per batch" properties, because they affect only the batches of mesh (TRIS commands) between the attribute being turned on and turned back off again.

Where Will New Features Appear?

I try to post some of my crazier ideas regarding OBJ on the scenery system RFCs page. Looking at the extensions, we can see how these extensions will all be either global, drawing primitive, attribute, or OBJ structure extensions. (I am not promising that any of these RFCs will be implemented, just showing how the OBJ format grows.)

• Additive LOD. This is a change to the structure of an OBJ, but it doesn't actually change the format, just the legal LOD values.
• Explicit OBJ Height. This is a global property on the OBJ.
• Global Texture Variants would be a global property on the OBJ's textures.
• Global Object Attributes are new global properties - they move some per-batch attributes to be object-wide.
• Draped Object Geometry would be per batch.

In summary, the vast majority of proposed extensions are new per batch or per object properties.

Next: what are the implications on performance of the various sections of an OBJ?