Tag: Goofy Screenshots

Managed Expectations

I’m a bit behind on posting; I’ll try to post an update on scenery tools in the next few days.  In the meantime, another “you see the strangest things when debugging pixel shaders” post.

(My secret plan: to drive down expectations by posting shader bugs.  When you see X-Plane 10 without any wire-frames, giant cyan splotches, or three copies of the airplane, it’ll seem like a whole new sim even without the new features turned on!)

Posted in Development by | 5 Comments

Next-Gen Twin Prop

The Cessna 172SP isn’t the fastest plane, but it would get you there a little quicker if it was a twin prop.

(This is what happens when I leave the AI planes on while randomly testing rendering bugs in the middle of nowhere.  On the bright side, the two planes do shadow each other.)

Posted in Air Traffic Control by | 1 Comment

A Cliff Shader

I have been stingy with pictures of next-gen global scenery for one reason: it’s really hard to get a nice shot of the global scenery that doesn’t show unfinished features. With something like global lighting I can zoom in and show just the new trick, but with global scenery, I can’t take a picture of a new house without showing a city block that looks funky due to a bug and a road that isn’t finished. Posting a working shot of the global scenery where some sub-systems have bugs and artifacts would just freak everyone out.

I figure if it’s obvious that the shot isn’t a production shot, I can get away with posting it though.

A lot of the times when I work on the rendering engine, it is with test textures like this. Our art team does their best to hide the seams between different art assets, so that the scenery looks like one continuous world. The problem for me is that the better they do, the harder it is for me to tell if the underlying shaders are doing what they should do.

So alpilotx sent this test: it’s all of the Innsbruck area painted with a test texture. What’s new and interesting here is that the flat, hill, and cliff areas are all shaded by a single shader that selects between multiple textures (and rotates the textures) based on the underlying mesh.

We are adding the cliff shader to version 10 for a few reasons:

  • Often we can get better cliff and hill definition by processing in the shader than by painting different triangles with different textures; our ability to control the transitions using different .ter files is limited.
  • Using one slope-sensitive shader saves over-draw and triangle count, which makes the DSFs faster and smaller.
  • Some day we may have the GPU distorting mountains on the fly to make them more mountainous. If we do, we need the GPU to also apply the correct textures; if the cliff areas are precomputed then they won’t respond to GPU distortion.
Posted in Development, News, Scenery by | 14 Comments

Tuning the Rasterizer

I’m not sure anyone cares about this kind of thing, but…




These are pictures of a test of the rasterizer. The rasterizer is code in both the DSF creator* and X-Plane that converts polygons into lines or boxes. What good is that? We use it to:

  • Plant trees inside a polygonal forest in a DSF.
  • Process all of the elevation points inside a polygonal water body when making a DSF.

Etc., etc. These were from a performance test rasterizing the Mississippi delta at 1201 x 1201; because the vector data is insanely detailed (something like 2 million line segments I think) it’s a good test of performance. The blue lines represent a line fit, but the white lines are a “box fit” – that is, they ensure that not only are they “inside” the water, but the area above and below them are too.

* Programming geeks can use this code – it’s in PolyRasterUtils.

Posted in Development by | 5 Comments

OSM Tilings

This is two pictures of “tilings” of OpenStreetMap for use in global scenery. I downloaded a OSM new planet extract about a month ago; in the 11 months since I last grabbed it, the data size has grown 56%! The new, larger file required some changes to my extracting code. After much debugging, I was able to see this in QGIS:


The first picture is 1×1 tiles, which are derived from the second picture (10x10s). You’ll see some “ragged” edges. This is because the cutting scheme leaves whole roads of interest in one piece even outside the tiling bounds. Later, more sophisticated code crops the road when the actual DSF is built.

The OSM processing tools are part of the open source scenery tools; I will get my changes checked in to source control over the next few days, although my code is only one of dozens of programs for bulk processing OSM.

Posted in Development by | 2 Comments

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.

Posted in Development, Scenery by | Comments Off on Draping

Need…More…Stripes!

Some of the coolest in-development screen-shots are the bugs. A few weeks ago while working on cloud shaders I managed to create a hybrid of an acid trip and a light-speed trip on Star Wars. Sadly the code has since been modified a thousand times and the effect is gone.

So I’m going to start posting bizarre images as they crop up. Usually they don’t reveal too much about unreleased features.

This came out of some experiments with hills, mountains and UV mapping.

(Clearly what this code needs is a leopard-print texture.)

Posted in Development by | Comments Off on Need…More…Stripes!