Tag: inside x-plane

The X-Desktop and iPhone Are Not Zero-Sum Games

On the menu this morning: first a whiny rant, then a nerdy one.

Someone pointed me at this post. Before I go into my geeky diatribe about leveraging code, a quick note: it is true that at this point Austin is working heavily on the iPhone – probably more on the iPhone than the desktop. It is also true (but not mentioned) that Laminar is investing more man power into X-Plane for the desktop now than it ever has in the past. (With the iPhone we’ve grown our workload with a second “front” for products, but we’ve increased staffing a little bit too.)

It is also true that X-Plane 9 free updates have been less frequent. This doesn’t mean there’s less code going into them – it just means that we’re doing 4-5 months of coding and 3 months of beta instead of 2 months of codindg and 1 month of beta. I’m not sure if this is better or why it is happening (each release has to be individually planned for the circumstances) but one observation:

Given how many video cards and drivers are out there and how they react differently to the X-Plane code, I wouldn’t want a beta process less than 2-3 months, because I want to know that it’s had time to run on a wide variety of hardware. If our beta has to be at least 2-3 months, then a 3-month release cycle would have us in beta all the time!

My whiny rant (the short version) is this: Laminar Research isn’t in a position (as a company selling a product) to post all of the details of how our business operates internally. So posts that say “Laminar should do X” (where X is a business decision) drive me a bit nuts, because I can’t post a reasonable reply.

Now here’s my real point: development for the desktop and the iPhone are not a zero sum game. Clearly we leveraged the desktop sim to create the iPhone app. But it goes both ways; work on the iPhone also benefits the desktop.

Here is one example: when beta 8 comes out, Plane-Maker’s “export to object” will a much more complete OBJ, in OBJ8 format, with animations already in place for things like wing controls surfaces!

That’s a feature that people have been asking about for a while – both to make CSL objects* and as a way to save time when moving from a Plane-Maker drawn plane toa custom one. (You would first export an animated OBJ8, then start adding details in a 3-d modeling program. With beta 8, you won’t have to rebuild your control surfaces from scratch.)

But…it’s also a feature that is critical to the iPhone! The iPhone version of X-Plane uses animated OBJ8 files as well; this feature helped us internally to prepare planes for the iPhone version, but it’s also a requested feature from our authors.

So my response to those who say that the iPhone has taken away from X-Plane development is that it is not true – not only because we are developing more heavily for the desktop, but because sometimes iPhone development is for the desktop.

* I do not remember whether the current compiled versions of libXplaneMP use OBJ7 or OBJ8 objects. Since libXplaneMP uses the OBJ code from XPTools, it should be (relatively) straight forward to update libXplaneMP and the clients that use it to use OBJ8 directly. In the meantime, you can use ObjConverter to convert an exported OBJ8 back to OBJ7 for CSL use.

Posted in Development, iPhone, Modeling by | 2 Comments

Object Materials – Some Rough Thoughts

First, we’re not going to get an OBJ materials model in 930.  930 is crammed full of stuff, and I don’t want to add anything more!  I am not sure when we’ll get OBJ materials, or even if this is how it will go down.  But this is what I am thinking:

  • Materials will be controlled on the “batch” level, that is, by using ATTRibutes.  You’ll be able to change materials mid-object.
  • Materials will be grouped into “material classes” – the material class will be mutually exclusive.  So if we have a metal material class and a “plastic” material class, you won’t be able to combine them.
  • There will be some kind of material class that corresponds to the current behavior, and all of the existing attributes will keep working; probably there will be a newer, cleaner way to state in an OBJ what you can already do now.
  • You will set all material class parameters at once.  This simplifies the syntax and assures that we don’t have any strange mix & match combinations.

To this last point, consider that OBJ currently has a number of strange cases where you can set attributes that don’t have any effect.  For example, you can set the shininess while drawing the cockpit texture (which is unlit).  Code like this has historically been buggy, partly because it’s not necessarily obvious to a human reader what the object should do.

I do not yet know how normal and gloss maps fit in.  Normal maps may be useful to multiple material classes; gloss maps are somewhat material class specific (in that if a material class has no concept of gloss, the gloss map is moot).  It is definitely advantageous to pack a normal map and gloss map into a single texture (a la blender).
The main point of material classes is to create the infrastructure for complex extensions to the material system in a clean way.  Adding additional attributes creates an NxN problem – for each new attribute I add, I have to consider how it interacts with every other attribute.  By comparison, a new material class by definition shuts all other material classes off.
Posted in Development, File Formats, Modeling by | 5 Comments

The Dangers of Wandering in the Desert

I have been trying to put documentation on the X-Plane Wiki, and use this blog for announcements and “the inside story”, rather than letting the blog turn into a poor-man’s users manual. An aircraft developer asked me via email whether there was a blog entry on some of the pitfalls of the v9 panel lighting system. There is not, and the lighting system is under-documented. I will be working on improving the documents over the next few weeks, but the point of this blog entry is: “how did we get here?”

I am a huge fan of incremental software improvement. That’s the subject of another blog post (perhaps on another blog), but for now I’ll say this: all changes to the rendering engine since version 8.0 have been incremental ones, and yet if you were to look at the code, you wouldn’t see a series of band-aids taped on top of each other. Each incremental change leaves the rendering code “fully updated”, as if it had been written yesterday. I start each new scenery feature by first reshaping the existing code into the most useful form for what we want to have in the future, and then coding the new feature is relatively simple.

But this strategy has an Achilles heal; if the code being refactored has a public interface (whether it is a file format or programming API), then all of the intermediate steps in the journey become requirements for future products in order to maintain backward compatibility.

This is not a problem as long as the programmer knows where he is going. The danger comes when one of the intermediate steps is actually a step in the wrong direction, and becomes dead weight around a future design.

A Reasonable Progression: OBJ

The OBJ 800 file format has had a reasonable progression* since its birth in version 8. It has gained a number of new features, but each one has generalized and made more powerful previous ideas, such that “legacy behaviors” are not so painful. Some examples:

  • Hard surfaces may now be decks (e.g. you can fly under them) or not, and you can specify what kind of hard surface you have. The original hard surface command was simply “it’s hard” or “it’s not”. But viewed under the lense of the new scenery system, that old hard surface command implicitly implied “the surface is smooth” and “the hard surface is not a deck”. So the new hard surface command is a more general version of the old one, which continues to work under the new system.
  • Animations in version 9 can be key framed; in version 8 you simply specify start and end values. But start and end values are just like having two key frames. So viewed under the lense of the new scenery system, all animations are key framed; older objects always just have two key frames. The new key framed commands are a more powerful, more general version of the old ones.

I can’t say that the relatively pain-free evolution of OBJ files over the last 4 years comes from good design or genius on my part – in truth it’s probably just good luck. But I think one thing has helped me keep the new OBJ extensions relatively sane: most of them are conceived several months before they make it into X-Plane.

I have a scenery system to-do list that will last me at least another four years; most of it is filled with things that Sergio has asked for. This to-do list acts as sort of a road map for future scenery system extensions; for any possible OBJ change, I can look at it relative to the other todo items and ask: “is this extension going to play nicely with things to come?”

(As a side note, this is one of the reasons why there are not light maps in any of the X-Plane modeling formats. Light maps don’t play well with a number of other scenery system extensions. I want to resolve the conflict between these future additions before they go into the sim.)

Wandering In the Desert

By comparison, the evolution of the panel system in version 9 has been more like wandering in the desert than a straight line toward a goal. Repeatedly, I put features into the panel system without a clear roadmap of where we would end up or how they would work together. The result is what you see now when looking over the panel documents: complexity and chaos.

Basically there are several major changes to the panel system that affect each other in strange ways:

  1. A more complex lighting model on the 2-d panel in version 920. (That is, the 3 2-d spot lights, and generic instruments with back-lit, mechanical, or glass lighting.)
  2. A more complex lighting model in the 3-d cockpit in version 930. (That is, 3-d spot lights, ATTR_cocpkit_region and generic instruments with back-lit, mechanical, or glass lighting.)
  3. A separate panel used only to provide texture to the 3-d cockpit. (That is, the 3-d panel.)

The problem is the order that they were invented: first ATTR_cockpit_region, then the 3-d cockpit, then back-lit generic instruments, then 2-d spot lights, and then 3-d spot lights.

The result is two sources of confusion:

  • Some combinations of features simply don’t work together. Since all of the features appear to be independent, I sometimes get bug reports on these. For example, you can’t use the 2-d spot lights on the 3-d panel. This is not a bug, it is by design! I will explain why some of these limits exist in future blog posts.
  • Among the remaining combinations that do work together, there are a lot of choices about how to structure a plane – too many choices!

This second point is a tricky one: X-Plane has to continue to support whatever set of features was available for any given release (864, 900, 920, 930) so that older planes continue to work. But some of those combinations (e.g. the ones that exist in version 900) don’t make a lot of sense for new planes made in 930.

I am open to ideas on how to solve this. I intend to document a “correct formula” for a modern plane, perhaps with tutorials, on the Wiki. I am also considering programming Plane-Maker to flag unusual combinations of features as a warning when saving 930 planes.

Either way, I fear I’ve learned my lesson from the panel system: incremental improvement of code is only a good idea if the programmer knows where he is going! Next time I will use Google Maps. 🙂

* I suppose that whether you think the OBJ 800’s evolution has been reasonable depends on your standards for file formats. OBJ 800 absolutely does show growing pains. I would only say: consider the number of revisions and the change in the hardware platform OBJ 800 feeds when you consider its stretch marks.

Posted in Cockpits, Development, Modeling, Panels by | 7 Comments

Scripting: A Line In the Sand

I thought I had already blogged about this, but I can’t find the old posts, so here goes. The big question: why can’t we have “X” in the OBJ file format or as part of generic instruments?

I get a lot of requests for “more power” in the OBJ or generic instrument system – the ability to play sounds, to do simple math operations on datarefs, more show-hide filters, the ability for a generic instrument to change a dataref in response to another dataref instead of a mouse click.

And invariably I say “No! Go write a plugin!”, which I realize is a fairly rude thing to say to a non-programmer. First, let me explain why I say no, and then what we can do about this.

Keeping Systems Separate

These feature requests fall into two broad categories: “systems programming”, which is really anything that has a side effect (play a sound, change a dataref, apply some logic), and “visualization” (e.g. a user needs more flexibility to better visualize the sim’s state.

I definitely do not want any kind of “systems modeling” code inside OBJs or generic instruments. To give a trivial example: imagine that you could make a generic instrument that would set the generators to on when the landing gear is raised.

What then happens if this generic instrument is off the bottom of the screen when the landing gear is raised? Does the generic instrument get to perform its logic? Both OBJs and generic instruments are fundamentally “visualization” systems – both will short-circuit for performance when they are not visible. If we put systems modeling code into them, then the sim has to evaluate a potentially large number of otherwise unimportant (non-visible) objects and instruments to do system behaviors.

In computer programming, there is the notion of a “model-view-controller” design. The basic idea is to keep the code that changes the model, the model itself, and the code that lets the user see the data model, all separate. Keeping them separate keeps operation consistent – the model does not change its behavior depending on how you look at it, which is very important for consistent simulation.

So for all systems modeling, my answer is always the same: not in viewing code!

Expressions and Visualization

Some requests are simply requests for more visualization complexity – there is only so much you can do with key frames, animation, and a few filters.

I do have to admit that on some level, it is perfectly reasonable to ask for infinite power to visualize data in OBJs and generic instruments.

On the other hand, there would be a real cost to having programming-language complexity in what are otherwise relatively simple-to-use parts of X-Plane (e.g. the simplest model is just an export from ac3d…). My solution for both problems (systems and visualization) is a scripting system, but in the case of visualization, it is about not reinventing the wheel and keeping complexity limited to one place (the scripting system).

Scripting

Plugins have the power to solve all of these problems – they can change almost any aspect of the sim. But they are also very difficult to create; you need to be a programmer who knows a language like C or Pascal, and you need to know how to use the development tool for each platform you want to support. That’s a huge amount of specialized knowledge just to customize a few systems.

Basically we need to have a line in the sand. At some point, when the systems to visualize information (OBJ, generic instruments) are not powerful enough, we need to make programming easier, rather than make modeling and authoring more complex.

What we need is a scripting system. The scripting system would provide a relatively simple text-file syntax to do simple scripting of systems and instruments for airplanes.

Such a scripting system should be implemented as an open source plugin; it should not be built into X-Plane. The advantage of this would be:

  • Anyone could improve or add features to such a scripting system, not just Austin and myself.
  • People could freely customize the scripting system as needed for specific projects.
  • By having the code be part of a plugin and not the sim, backward compatibility would be improved – even if the “official” version of the scripting plugin changed, you could always include an older version with your plane that worked exactly the way you want.

Who should work on this scripting system? I don’t know. Probably not me — I am not very good at making simple systems; see also what a complex disaster the panel and instrument system has become!

When a user requests that I add a feature to the generic instrument system, there is an implicit request – that Austin or I take programming time to do the feature. So for now I can only say that if/when I take time to do some of these feature requests, it will be in the form of a scripting system, not as extensions to the generic instrument and OBJ systems. This will give us better long-term compatibility and extensibility (via an open source plugin) and will keep systems modeling code separate from the visualization system.

Posted in Cockpits, Development, Modeling by | 4 Comments

Unfinished Business

I have recently started leaving pieces of email and notes on the Wiki.  To see this mess, just view Category:Unfinished.

The problem is that often I don’t know what people don’t know but want to know.  So when I get an email question whose answer is not already posted somewhere, I make a wiki page and dump the info.
This stub is in response to some work I did this morning.  In particular, lights in X-Plane often have visibility much larger than the objects they come with.  This used to be true for the cars, but I broke the code in 921 and didn’t notice.  In 921 headlights do persist beyond the car object’s visibility distance, but not by much.  930 will fix this, restoring the “string of lights” look on the roads at night.  
I’ve also tuned the headlights to be visible from a wider viewing angle, to try to make them more noticeable from above.  (In real life, the lights illuminate an area of the pavement, which is visible, but we don’t do this.)
If there is a scenery subject that is poorly or not-at-all documented, shoot me an email and I’ll stub out a Wiki page – it’s a first step to getting comprehensive documentation.
(Note that I have not added pages for tutorial steps like “how do I add a manipulator to my object” because I am doing the tools work for ac3d now … better to write a tutorial for manipulators the easy way with ac3d than to write one on the hard way – editing the OBJ – and changing it later.  That is to say, I am trying to documetn tools, not temporary work-arounds!)
Posted in Development by | 4 Comments

What Happened to X-Plane 910

X-Plane 910 was an update to X-Plane 9 for our professional customers.  But all of the new features that they got in 910, everyone got in 920.  Here’s how it happened:

X-Plane 9 had a very long beta, and the end of that beta was mostly spent with a finished sim and me trying to fix the pixel shaders for five thousand flavors of video card, driver, and operating system.  During this time, Austin started work on new systems modeling features for professional level sims.  We branched the code, with my work going into 900 and his going into 910.
When he finished his systems code and I got the pixel shaders fixed and both were fixed, the two were combined into what became 920.
So that’s how we “lost” the 910 version number – some professional customers have the version number, but everyone got the features.
Posted in Development by | Comments Off on What Happened to X-Plane 910

Failed Ideas and Two-Core Rendering

I’m pretty gun-shy about posting new features to this blog before they are released.  One reason is that a fair number of the things I code never make it into the final X-Plane because they just don’t perform as expected.  But the converse of that is: there should be no problem posting about what failed.

One idea that I believe now will not make it into the sim is dual-core pipelined rendering.  Let me clarify what I mean by that.
As I have blogged before, object throughput is one of the hardest things to improve in X-Plane. That code has been tuned over and over, and it’s getting to be like squeezing water from a rock. That’s where dual-core pipelined rendering comes in.  The idea is pretty simple.  Normally, the way X-Plane draws the frame is this:
for each object
is it on screen?
if it is tell the video driver, hey go draw this OBJ
Now the decision about whether objects are on screen (culling) is actually heavily optimized with a quadtree, so it’s not that expensive.  But still when we look at the loop, one core is spending all of its time both (1) deciding what is visible and (2) telling the video driver go draw the object.
So the idea of the pipelined render is to have one core decide what’s on screen and then send that to another core that talks to the video driver.  Sort of a bucket-brigade for visible objects. The idea would be that instead of each frame taking the sum of the time to cull and draw, each frame should take whichever one is longer, and that’s it.
The problem is: the idea doesn’t actually work very well.  First, the math above is wrong: the time it takes to run is the time of the longer process plus the waiting time.  If you are at the end of a bucket brigade putting out the fire, you waste time waiting until that first bucket goes down the line.  In practice the real problem though is that on the kinds of machines that are powerful enough to be limited only by object count, the culling phase is really fast.  If it takes 1 ms to cull and 19 ms to draw, and we wait for 0.5 ms, the savings of this scheme is only 2.5%.
Now 2.5% is better than nothing, but there’s another problem: this scheme assumes that we have two cores with nothing to do but draw.  This is true sometimes, but if you have a dual-core machine and you just flew over a DSF boundary, or there are heavy forests, or a lot of complex airports, or you have paged-texture orthophoto scenery, then that second core really isn’t free some of the time, and at least some frames will pick up an extra delay: the delay waiting for the second core to finish the last thing it was doing (e.g. building one taxiway, or one forest stand) and be ready to help render.
And we lose do to one more problem: the actual cost of rendering goes up due to the overhead of having to make it work on two cores.  Nothing quite gloms up tight fast inlined code like making it thread-safe.
So in the end I suspect that this idea won’t ever make it into the sim…the combination of little benefit, interference by normal multi-core processing, and slow-down to the code in all cases means it just doesn’t quite perform the way we hoped.
I am still trying to use multiple cores as much as possible.  But I believe that the extra cores are better spent preparing scenery than trying to help with that main render.  (For example, having more cores to recompute the forest meshes more frequently lowers the total forest load on the first CPU, indirectly improving fps.)
Posted in Development by | 1 Comment

Contractual Ranting

Microsoft extended Windows XP sales yet again, more or less.  But rather than rant about how the Vista user experience makes me want to tear my fingernails off or how brain-damaged it is to try to put DRM into drivers, let me instead focus on Windows as an example of the cost of contracts.

I have ranted in the past about how the boundary between X-Plane and a third party, or the plugin system and third parties, or even two third parties, is a contract.  Consider:
  • The named light list forms a contract between X-Plane and objects, e.g. X-Plane guarantees that there will be a named light called “airplane_landing” and that it is a good choice for landing lights.  (This implies that X-Plane won’t change what it looks like to be inappropriate for landing lights, and that third parties won’t use it for inappropriate uses, like airport apron lights.)
  • XPLMGetDataf forms a contract between the plugin SDK and plugins, guaranteeing that there will be a function in the XPLM called “XPLMGetDataf” that takes a dataref and returns its value.  (This implies that Sandy and I won’t rename it or change its arguments or remove it all together, and that plugins won’t pass non-datarefs in as arguments.)
  • Even a paint kit forms a contract – the airplane maker is essentially saying “the tail will be mapped to the upper left of the texture, and I won’t remap my UV” and the livery maker is saying “I will put an image in the upper left corner that looks like a tail.”

By comparison, the clouds are not a contract – there is no way third parties can customize the look of the clouds, so we can change the algorithm by which we create them pretty much at will. We could switch to a volumetric approach for all clouds or even go back to 2-d without worrying about third party interaction.

Okay – that’s a lot of words about contracts…what does that have to do with Vista?  Well…
The Cost of Changing the Contract
Two major aspects of why Vista has been a worse experience for users than Windows XP come directly to the need for Microsoft to change contracts.
  • For years, applications have run on Windows with admin rights.  This is not good – it means that any process can do serious damage to the system if hijacked – and on Windows processes get hijacked on a fairly regular basis!
  • For years, audio and video drivers have run pretty much unprotected.  This was good from a performance perspective, but also caused a lot of BSODs.  On Windows, drivers are third party components and are quite possibly not checked by Microsoft (especially video drivers) so letting them run without protections is risky.

In both cases, the problem is that the old contract is both (1) poorly designed* and (2) being used by a lot of third parties.  What choice did Microsoft have?  Continue to let apps run in admin mode and hijack the whole machine any time the user picked up a virus?  Or change apps to run in user mode and hope that the applications didn’t depend on this guarantee?

(At this point, Raymond might go ballistic and point out that the Windows API doesn’t really promise admin rights and apps should not have been doing all of these naughty behaviors in the first place.  I don’t know what the Win32 API declares…the difference between what a platform declares and what it does is important enough to warrant another post.  Certainly with X-Plane we have to worry a lot about third parties depending on behavior that was unintentional but turned out to be useful.)
Vista has been a difficult transition because it changed a bunch of rules (that needed to be changed).  In the long term, I am sure that both of these decisions are for the better — eventually applications won’t be counting on administrator rights, so we won’t have to fume about UAC (or shut it off), and a hijacked web browser won’t be nearly as dangerous.
On the video driver front, the Vista experience is pretty reasonable now – there has been a lot of improvement since Vista first came out.  I expect applications and UAC to take a lot longer – video drivers get revised quite frequently; applications seem to linger around forever.
I’m Not Signing That
If we end up with a situation like this in X-Plane (the contract is used heavily by third parties and not well designed) we only have two options, and they’re both bad:
  1. Break the contract.  Third party content stops working, users are angry, authors are angry.
  2. Stick with the contract and mitigate as best we can.  Usually this means writing more code (slows down new features), using a less optimal implementation (lowers frame rate), etc.

This is why my first reaction to any file format extension is: “is this going to be a PITA in a year”?  The benefit might be visible now, but the cost could plague us indefinitely.

What You Want, Not Where You Want It
If you would like to request a feature, tell me what you want, not where you want it implemented.  I bring this up because many of the feature requests I get are very specific and describe an implementation, not a goal.  (To draw an analogy, it’s as if I call a general contractor and say “dig a big hole right here” without telling him “it is for a swimming pool”.)
The reason “what not how” is so important is because many of the “how” implementations that people send me involve creating new contracts with third parties.  I am going to try to design the feature with the minimum contractual obligations – that is, to do just what is intended and hopefully not much more.  
But if I can’t tell what you are trying to do, I can only say “I won’t code this implementation – the cost of long term support due to contractual obligations outweighs the usefulness.”  It might be that there is another way to implement the feature that would not put a long term burden on the scenery system or airplane SDK and still provide all of the benefits.
* Poorly designed?  Or perhaps well designed for a previous problem – if the problem changes, the design might not be appropriate.  Or perhaps not even designed at all – sometimes contracts evolve without a lot of central planning.  All of these things have happened in X-Plane.  In the case of Windows, I suspect it’s the previous-problem case — that is, what made sense for much smaller computers where the scope of what could be done was quite limited no longer makes sense for big modern computers that are capable of a more expensive and robust solution…just my speculation.
Posted in Aircraft, Development, File Formats, Scenery by | Comments Off on Contractual Ranting

Moving Features to the GPU

A hidden detail of my previous post on variation and terrain textures: variation for flat textures was implemented using more triangles in the DSF in X-Plane 8, but is implemented in a shader in X-Plane 9.  This means that you don’t get this feature in X-Plane 9 if shaders are off.

My guess is that this is perfectly acceptable to just about every user.
  • If you don’t have shaders, you have something like a GeForce 4 or Radeon 8500, and are fighting for frame-rate.  In this case, not paying the price of layer-based variation is a win.
  • If you have shaders, you’re getting better performance because the shader creates variation more efficiently than the old layering scheme did.

This kind of move of a feature to the GPU can only happen at major versions when we recut the global scenery, because (to utilize the benefit) the DSFs are recut with fewer (now unneeded) layers.  So features aren’t going to mysteriously disappear mid-version.

I do have a goal to move more layering-type features to the GPU for future global scenery renders.  There are a number of good reasons:
  • DSF file size is limited – we have distribution requirements on the number of DVDs we ship.  So DSF file size is better spent on more detailed meshes than on layers.
  • GPU power is increasing faster than anything else, so it’s good to put these effects on the GPU – the GPU is still hungry for more!
  • If a feature is run on the GPU, we can scale it up or down or turn it on or off, for more flexible rendering settings on a wide variety of hardware.  A feature baked into the DSF is there for everyone, no way to turn it off.

My hope for the next render is to (somehow) move the cliff algorithm (which is currently done with 2-4 layers) to the GPU, which would shrink DSFs, improve performance, and probably create nicer looking output.

Posted in Development, File Formats by | Comments Off on Moving Features to the GPU

Auto-Variation and Repetition

In my previous post I discussed variation as a way to hide the artifacts of land use texturing. Now we can talk about this bug.

What are these weird artifacts that show up over the terrain when shaders are on?  Well, they should (and will in 930) look like this:

But what’s going on?  The answer is auto-variation.
In X-Plane 8, variation is created by using multiple layers, each one applying a texture at a different offset.  This technique works on a wide range of hardware, but is inefficient – it causes overdraw (which we know is very bad).  
So in X-Plane 9 I replaced this layer-based variation with a pixel shader algorithm.  This means less information in the DSF (which means smaller DSFs, faster loading and less RAM use), but it also means variation is only visible to those with shaders.  Having the pixel shaders create variation dynamically on the GPU is called “auto-variation” (and is invoked via the AUTO_VARY command in a .ter file).
The artifact above was a bug in the auto-variation shader.  With the code now fixed (the 930 patch will contain the fix), here are some images of how it is supposed to work:

Here we have the texture in question, at two different offsets.


This black and white texture is the “mixing mask” used to select which offset to use.

And this is the final result.

There is a little bit more disruption in the columns of green park.
Posted in Development, File Formats by | 3 Comments