WorldEditor’s “Make Draped Polygons” feature is a stop-gap and a hack, and someday it will be replaced with something better.
I mention this as I debug it because there are feature requests in the bug base to enhance its operation; I think I will replace it with a more fundamentally useful (and less awkward) interface before adding more functionality.
“Make draped polygons” was born out of a hack to WED to allow Sergio to finish his LOWI custom scenery pack before WED 1.1 was even public beta. In other words, it was a crude attempt to get draping into WED before the real UI work was done.
I am resisting the urge to nuke the feature now because there isn’t something to replace it yet. But in the long term, what WED needs is better tools to work with imagery and manage the text files that are needed to create ground imagery around an airport.
This new UI will be after the 1.2 release; for now the goal is to get 1.2 stabilized and finalized.
Posted in Tools
by
Ben Supnik |
WorldEditor 1.2 beta 2 is now available for download here. First, a few notes about WED betas:
- WED 1.2 is in beta – be sure to back up your work, as it has been known to crash.
- The scenery tools are open source – you can view the WED source code here.
- The scenery tools have their own public bug base. So please report all WED bugs here.
Please be careful to report X-Plane bugs to the X-Plane bug reporter page and WED bugs to the scenery tools bug base. Moving bugs to the right place just burns time that could be spent fixing bugs.
What’s New?
Pretty much all of the changes from beta 1 are in the area of exporting scenery.
WorldEditor now has the concept of an export target – the version of X-Plane you want to export. It currently knows about four possible targets:
- X-Plane 9.70 (that is, the final version of X-Plane 9)
- X-Plane 10.00 (that is, any version of X-Plane 10 back to the earliest)
- X-Plane 10.21 (that is, the current latest version of X-Plane 10)
- Robin’s database
Changing the export target can change how export works to optimize for that version of X-Plane; it also programs the “Validate” command to detect possible problems specific to that version. Examples:
- If you set the export target to X-Plane 9.70 and export a DSF overlay with forests in “line” mode, validate will catch the error – line-based forests are new to X-Plane 10.
- If you set the export target to “Global Airport Database” and use your own custom OBJs, validate will catch the error – for sending data to Robin you must use our library objects.
“Export for Global Airports” is now available on the File menu – this exports a single zip file that you can send to Robin. The zip file contains an apt.dat and one .txt file per airport with the DSF overlay data.
The exporter itself has been heavily rewritten (view the git logs to see what a blood bath it was) – this should hopefully fix all crash-on-export bugs, particularly on Windows.
So the hope is that this beta will (1) let people send their airports to Robin and (2) let custom scenery authors work without crashes on export.
Posted in Tools
by
Ben Supnik |
Tom asked a good question in the comment section of a previous post: what is the difference between DSF mesh formats for v9 and v10. Here’s the story:
Mesh: In X-Plane 8 and 9, the terrain mesh is stored as a set of triangles in 3 dimensions; each corner of the triangle has a latitude, longitude, and altitude. The shape of the mesh comes from the location of those triangles and the heights of each corner.
Mesh + DEM: X-Plane 10 can also handle a new extended DSF with raster (array) data. In this mode, the mesh contains triangles (just like it did) but they contain only latitude and longitude. The elevation for the entire DSF tile is stored in a 2-dimensional array of elevations (a raster DEM). When X-Plane 10 loads this format, it reads the height for each triangle out of the array of elevations to “rebuild” the 3-d triangles at load time.
X-Plane 9 supports only the original “mesh” DSFs.
X-Plane 10 supports both the original mesh DSFs and the new Mesh + DEM DSFs.
Therefore, old scenery from v9 loads fine in v10. But you cannot load the new v10 global scenery in v9.*
Why Did You Guys Do This?
Moving elevation data out of the triangles and into a separate raster layer actually makes the DSF smaller.** That’s a nice-to-have, but that’s not why we did it.
DirectX 11 class graphics cards can enhance meshes on the fly, on the GPU via tessellation. We wanted to shift the DSF elevation mesh toward raster data so that we would have the full source raster to feed into the GPU. In this configuration, we can make a low resolution mesh, give the graphics card the full data and say “go to town.”
If the graphics card can ‘enhance’ the mesh quality, this solves a problem we have now: there is no rendering setting for mesh complexity. Right now everyone uses the same meshes, so we have to limit mesh detail to meet the specs of low-end supported computers. With GPU-enhanced terrain, users with more powerful systems can crank up the detail.
We’re not ready to code this yet, but one first step was modifying the DSF format to be ready for tessellation. We did this with the X-Plane 10.0 global scenery, and a nice side effect was smaller DSFs.
What About MeshTool?
MeshTool 2.0 writes DSFs with the classic “mesh” format, and it uses the v9 global terrain definitions to fill in land classes where there are no custom orthophotos.
MeshTool 3.0 will write DSFs with the new mesh+DEM format, and it will use the new v10 terrain definitions.
Therefore, MeshTool 2.0 will make v9 scenery (that can be loaded in v10) and MeshTool 3.0 will make v10-only scenery.
* There are also a million other v10 0nly features that the global scenery requires that v9 does not support. Besides not supporting Mesh + DEM, v9 doesn’t support the new terrain shaders, the new draped road system, or the new autogen!
** The space savings come from two places: first, we don’t need to save terrain normals. Instead we calculate them since we have the full DEM. Second, we use 7-zip compression, and it actually gets better compression ratios on less heavily encoded data. So the raw raster DEM compresses better than the highly encoded triangulation mesh. The triangle mesh encoding format was designed a long time ago for classic pk-zip, not 7-zip.
Here’s a quick round-up on the state of scenery tools, as of 10.21 release candidates…
WED: WorldEditor 1.2 beta 2 is “in the can” and should be posted tonight. I’ll post more about the changes for beta 2 in another post, but beta 2 should fix any major beta bugs that were stopping people from getting work done, and opens up the path to submit airport buildings to Robin for collection in the global database.
MeshTool: I have a few bug fixes for MeshTool 2.0 and will cut a MeshTool 2.1 patch probably in the next week. If you use MeshTool 2.0 and woud like to test the patches now, let me know. The MeshTool 2.x builds will build v9-style DSFs, compatible with X-Plane 9 or 10.
I now have a prototype of MeshTool 3.0, which will produce X-Plane 10-style DSFs (E.g. with X-Plane 10 landclasses/terrain, and the X-Plane 10 DEM-in-DSF style storage). I am working on the XES files authors will need.
Note that having a prototype is a long way from having a stable beta; in particular, X-Plane 10’s new DEM system has never been tested with really huge DEMs – there could be significant bugs before MeshTool 3.x is ready to go.
The script format for MeshTool 2.1 and 3.x are the same, so you can easily create a MeshTool project and cut your scenery twice, once targeting X-Plane 9 and once targeting X-Plane 10.
Blender 2.49: I uploaded my patches to Jonathan’s scripts to GitHub – that “v10scenery” branch actually works for airplanes too and contains:
- Jonathan’s original work and
- Ben Russell’s manipulator exporter and
- Ondrej’s manipulator exporter for 2.49 and
- All of my modifications to support new v10 attributes and other stuff.
The idea is to have a unified Blender 2.49 script that is totally v10 ready and can directly export older projects.
Blender 2.6x: I also submitted a patch or two to Ondrej’s Blender 2.6x scripts, found here. I think that with their current status and those bug fixes, they should be totally usable for aircraft development.
A comment about Blender: I know that some of you have tried to use Blender 2.49 and were absolutely horrified. I have heard plenty of authors absolutely refuse to touch Blender 2.49, and I do not blame you at all.*
Blender 2.6 is different. The UI is completely redone and it is significantly less astonishingly weird. I was able to install Ondrej’s scripts, build an object, animate it, add lights, and export it using the user manual only to install the scripts; everything else I was able to do with a few good guesses about how the program might work. That’s a huge step forward from Blender 2.49 in terms of usability.
So I think Blender 2.6 with X-Plane export has the potential to be a really good intermediate modeling program for authors. It has all of the power tools you need in a 3-d editor (solid UV unwrapping, visual key-frame animation, non-destructive editing), and if you really become an expert, the hard core features are there (e.g. render baking), so you won’t have to change editors later.
The X-Plane integration is really clean too. Unlike Blender 2.49, Blender 2.6 allows plugin scripts to augment the core user interface, which is exactly what Ondrej has done. The result is that custom X-Plane properties are visible directly in the main UI with your editing properties. This makes full editing of X-Plane features straightforward.
So I believe that my next scenery-tools step (besides running out the betas for WED and MeshTool) will be to submit a few more patches for the Blender 2.6 scripts, to bring in direct support for some of the v10 scenery features. I think these changes should be straightforward, as it’s basically “more attributes, more check boxes”.
(I think the 2.6 scripts are not yet ready for major intensive X-Plane 10 scenery development – we need to get a few key v10 attributes in to allow authors to get maximum performance from their scenery packs. These attributes are not important for airplanes.)
* When I first started using Blender 2.49 to support our internal team, I basically had to have Propsman on the phone for a few hours going “click this box, now hit the space bar” and me going “what?!! seriously?! what the @#$@# did that button do!??!” In other words, Blender 2.49 is totally usable…as long as you have an experienced modeler to use it for you!
(I will say this though: once you overcome the Blender 2.49 learning curve, which takes about six months (!) the actual key strokes to use it are super-fast and efficient, which is why I think very experienced 2.49 modelers tend to look at 2.6 and go “who cares”?)
Posted in Tools
by
Ben Supnik |
X-Plane 10.21 rc2 is out; this recut of the release candidate backs out most of my changes to the lights; in hindsight my change was too ambitious/crazy at way too late of a point in the release process. The runway lights will still look better in 4x SSAA, but (like X-Plane 10.20/10.11) they will look dimmer if your monitor is bigger.
We’ll do something more involved with the lights for 10.30 when we have time for a proper beta test, and when Alex is around to look at my changes and tell me I’m an idiot.
Update: We are going to release a new release candidate (10.21 rc2) tonight that puts the light sizing back to normal, while still fixing the SSAA bug. This will have two effects:
- Runway lights won’t be as bright as in the RC. Sorry guys, we will get this fixed, but clearly it’s not something that I should try to change by jamming a code change in at the last minute.
- Airplane lights will look the same as they do in 10.20 and 10.11.
The rest of the original post follows…
I jammed a change into X-Plane 10.21 rc1 that maybe wasn’t such a great idea: in X-Plane 10.21 the light billboards get bigger when your screen resolution gets bigger.
The idea behind this change is that the percentage of lit pixels in the night scene should not get smaller when you go to a bigger monitor – if they do, then the night scene looks dark. In X-Plane 10.20 (and 10.10 and 10.05!) the billboard sizes are fixed in pixels – in a bigger monitor they tend to be tiny little dots, potentially harder to see.
This change makes a mess of aircraft lighting, and almost certainly needs to be changed (again) for an RC2. But the choices aren’t good.
- If we keep the old behavior (light size is constant in pixels) then authors have a lousy choice: make the lights too big in a small window or too small in a big window. There’s no way to get your billboards to look good on a laptop and a 1440p monitor. This is what authors have been living with, and it’s lousy. If you make a plane, you know that your lights only look right if the user has the same screen resolution as you – something you just should not assume.
- If we take the new behavior, what size should the lights be? We have to pick a screen size to use as “official” from 10.20. In rc1, I picked 1024 x 768 – that is, the smallest resolution we support. This choice makes the runway lights look good, but virtually all airplanes are going to have lights that look too huge.
So I am considering one of the following choices:
- Match the 10.21 lights to 1020 at 1080p (or some other intermediate resolution), in the hope that most airplanes will look good on average.
- Revert the change entirely (and keep only the fix for 4x SSAA) and solve this in 10.30. This isn’t good because (per above) authors are again stuck with the airplane only looking good at one resolution. But at least in 10.30 we could do something more clever (e.g. different behaviors for old and new airplanes or who-knows-what-else). Alex is still out of the country, so the thought of punting this until he can look at the results of some of the choices is tempting.
- Apply mixed behavior (e.g. different math for scenery vs. airplanes). With anything “clever” like this, we risk the equations getting complicated, with too much fine print for authoring.
Anyway, I think it’s 95% likely we’ll cut an RC2; I’ll post something when we pick a strategy.
If you haven’t participated in the 10.21 betas, run the updater and click “get betas” to get it. Release notes here; report bugs here.
If you have a custom scenery pack, please try it on this RC! There have been a few changes to the facade engine to fix cases that were clearly broken in 10.20; please check your scenery to make sure these changes didn’t cause some other problem that I didn’t see in my testing.
If you are creating an airplane or scenery pack and you need to create a fully customized spill light (visible in HDR mode only in v10) there are two ways to do it.
First, we have a parameterized light called “full_custom_halo” that takes nine parameters, e.g.
LIGHT_PARAM full_custom_halo 0 20 0 1 0.5 0.5 1 50 0 -1 0 0.5
(Phew!) The first 3 numbers 0,20, are the XYZ position (this light is 20 meters above our object origin). The next four are the RGBA color (100% red, 50% yellow, 50% green, 100% brightness*), so it’s a very light red. RGB colors for spills are in linear space, so you’ll have to experiment to get your colors perfect. The size is 50 meters (a huge light throw), and it points in the direction 0, -1, 0 (straight down). 0.5 is the “semi-width” of the cone – 60 degrees in this case. Basically cosine(cone width * 0.5) gives you this width parameter, or pass 1.0 for an omnidirectional light.
This light is on all the time – use full_custom_halo_night for the night version.
There’s a second option: OBJ files have a custom spill command:
LIGHT_SPILL_CUSTOM 0 20 0 1 0.5 0.5 1 50 0 -1 0 0.5 your/dataref/here
The position and 9 light parameters all have the same meanings, but in this case you get to provide a dataref. The dataref must be a float-array dataref of size 9; when your dataref callback is called, the array is pre-initialized to the 9 params, and you can change them at will. With this dataref, your plugin can change the light parameters in real-time.
Which technique should you use?
- Use LIGHT_SPILL_CUSTOM if you need the dataref to do clever customization.
- Use the PARAM_LIGHT with the nine params if you don’t need the dataref.
For scenery the param-light version may be notably faster when used many times in an object. So if you’re building a light used a lot (a streetlight, a taxiway light, an airport lighting fixture) you really want that param version.
Update: this was not documented at the time, but if you are using datarefs with LIGHT_CUSTOM_SPILL, the dataref format does not match the OBJ8 format. This page now documents the right format for plugin objects!
* The mathematically minded will note that there is no need to have an alpha on lights because they are additive. This is true – just set alpha to 1.0 and use darker colors!
First, 10.21 beta 2 is out – but if you had beta 1, you know that because the sim automatically tells beta testers about newer betas. Release notes here.
The big fix is a fix to crashing on OS X that was affecting the CRJ, other plugins, and anyone who tried to resize the sim’s window. The bug was introduced in an attempt to fix the not-working command key (which in turn broke when we rewrote the UI code for 64-bit). Hopefully we now can have 64-bits, a command key, and a resizing window all at once.
Performance Issues, or Lack Thereof
I have seen several bug reports reporting framerate loss in 10.21, and AlpilotX says he saw the same thing on forums. There is only one known cause of framerate change (and it could be an increase or a decrease): the autogen art mappings were changed in 10.21b1 to use smaller buildings for rural residential areas. With different autogen, we can have different fps.
Fortunately, X-Plane 10.20 and 10.21 can have the application interchanged with the resources of the other version, which makes it possible to test whether a performance problem was introduced via the autogen change or the sim itself.
What I found first is that there is no change in the performance of the sim’s engine from 10.20r3 to 10.21b1 to 10.21b2. Framerates between them were within the 2-3% random variance that you can get with the framerate test, and the pattern was random, not directional (e.g. sometimes 10.21 was faster, sometimes it was slower, indicating that the difference is random noise, not data).
The second thing I found was that there was no meaningful performance loss from the autogen – I saw perhaps a 1% fps loss, which is well within our error margins (or at least, nothing like the “sim is unusable now” reports I received).
Now that doesn’t mean that there isn’t a problem – just that my particular measurements don’t see it. So…
Please do not report new bugs going “but I see a fps loss on my machine”. That doesn’t do me any good.
Instead, let me give you some links: 10.20r3, 10.21b1, 10.21b2. If you see a fps loss, use these links to get the old apps. Use the updater to go down to 10.20 (for old autogen) or up to 10.21b2 (for new autogen), then try all three apps on the same X-Plane!
If you can find a framerate loss in this case, then investigate and report it with rendering settings and a reproducible case (e.g. sit on runway 36L at KSEA, etc.). Try to remove third party add-ons if possible because they make it difficult or impossible for me to reproduce your conditions.
Posted in News
by
Ben Supnik |
Quick note: 10.21 beta 2 should be out today – that’ll fix crashes for Mac users.
WED 1.2 beta 2 — it’ll be at least a few days. I have the submit-to-Robin code working, but I still have a number of export bugs open.
Posted in News
by
Ben Supnik |
