Tom had a good question that others have asked me too: why not ignore missing scenery resources? Why does X-Plane act so cranky?
Ignorance Is Bliss
We have tried the other approach: ignore missing art assets. ENV based scenery in version 7 did not require custom objects to actually be available – missing objects were ignored.
When I was working on the ENV reader for version 8 (the ENV code needed to be retrofit into the new rendering engine) I found to my surprise that virtually every ENV-based custom scenery pack I looked at was missing at least a few of the OBJs that the ENV referenced! I don’t know how this happened – it seems that in the process of working on scenery, authors started to “lose” objects and simply never noticed.
Quality Control
When we developed DSF we had a chance at a clean slate: there were no DSFs in existence so we could set the rules for art assets any way we wanted. So we picked the harshest rule possible: any missing art asset was illegal and would cause X-Plane to refuse to load the scenery package, with no way to ignore the error. Why be this rude?
- Missing artwork failures are 100% reproducible – you don’t have to try your package more than once to see the problem. If you are missing an art asset, you will have the failure every single time you run.
- The error is found on load – you don’t have to fly over the art asset to discover that it is missing.
- Therefore if an author tests a scenery package even once, even in the most trivial way, he or she will discover the missing art asset.
- Once the error is fixed, it is fixed forever, so a scenery pack that passes this quality control measure in development will be just fine “in the wild”.
- This rule has been in place since 8.0 beta 1 for DSFs, so there are no legacy DSF files that would have this problem.
Libraries
There is one special case worth mentioning: a scenery pack might reference an art asset in another scenery pack, and that other scenery pack might not be installed. This is why the library file format allows for “export_backup”. (Read more here and here.) Export_backup is your scenery pack’s way of sayingg “only use this art asset if you can’t find it somewhere else. It lets you provide emergency art-work in the event the other library is not installed.
What should you use as an emergency backup art asset? It could be anything – a big floating question mark, an empty object, a poor approximation of the desired art asset. But my main point is that responsibility for location of art assets lies with the author of a pack – so if you make a scenery pack, be sure to provide backups for any libraries you use.
(If you use OpenSceneryX, the library comes with a “developer pack” – read more here. Basically they already built a “backup” library that you can put in your scenery pack to avoid nasty messages from X-plane when OSX isn’t installed.)
No posts for two weeks…sorry, I’ve been head’s down with next-gen tech. It’s a little bit too early to blog about this stuff.
I was able to fix a few MeshTool bugs, but I have more problem reports, so I might be able to do a MeshTool beta 3 in a few days if things go smoothly.
940 is final – there might be a 941 maintenance release – we’ll know in a few weeks.
Yesterday I blogged about Order Independent Transparency (OIT). That robot is very shiny, but what does this fix in X-Plane itself? Here are two pictures that show the problem in an X-Plane context.
This is the Cirrus jet in X-Plane 9.22.
Pretty, eh? But…look through the right two windows – look at the passenger door on the other side. Note that through the middle window the passenger door is visible. Through the right window, the entire passenger door is gone!
This is the same shot from X-Plane 940, where the problem has been corrected.
The bug you see here is incorrect draw order. In X-Plane 922, the right door (which contains the right-most near window) is drawn before the left door – hence its translucent part destroys the door.
Max fixed this by changing the draw order of the model – the new cirrus draws the inside view of both doors before the outside view of either doors; because the geometry is one-sided he can draw the ‘inside’ first and outside ‘second’.
These two
blog posts explain translucency in a lot more detail.
What X-Plane has now is “order dependent” transparency – if translucent surfaces are not drawn from far to near, you get artifacts like the missing door.
What OIT promises (and that robot demonstrates) is the ability to have translucent geometry and not have the objects behind the translucent parts disappear.
Order independent transparency (OIT): first, the shiny robot.
So first, what’s so special about this? Well, if you’ve ever worked with a lot of translucency in X-Plane, you know that it doesn’t work very well – you invariably get some surfaces that disappear at some camera angles.
The problem is that current GL rendering requires translucent surfaces to be drawn from farthest to nearest, and who is far and who is near changes as the camera changes. There are lots of tricks for trying to get the draw order mostly right, but in the end it’s somewhere between a huge pain in the ass and impossible.
What’s cool about the robot data is that the graphics card is drawing the transparency even if it is not drawn from back to front, which means the app can just shovel piles of translucent triangles into the card and let the hardware sort it out (literally).
X-Plane is currently riddled with transparency-order bugs, and the only thing we can do is burn a pile of CPU and add a ton of complexity to solve some of them partly. That proposition doesn’t make me happy.
So I am keeping an eye on hardware-accelerated OIT – it’s a case where a GPU feature would make it easier for modelers to create great looking content.
This feature is not in the WED developer preview (because I just coded it) but: WED 1.1 will feature “click-to-split” for edges. With WED 1.1 you can option-click the edge of a polygon or line feature (but not a must-be-straight entity like a runway) to insert and drag a split point.
This will hopefully be a lot easier than the current, convoluted, WED 1.0 technique of selecting the two surrounding vertices and picking “split”, then repositioning the vertex.
Hackers: this features is not yet checked into the tree, so … building from source won’t help you. It’ll be available some time in the next week.
I realize as I write this that I am going to get some comments mocking the fact that X-Plane 940 is on RC, um…13. I don’t decide the milestones for X-Plane, nor do I decide the version numbers. If you want to discuss why X-Plane is 940 (and not 930 or 950) and why it goes beta and RC when it does, email Austin. What follows is all about the scenery tools, not X-Plane.
With that out of the way: I have released a WorldEditor 1.1 developer preview. So I wanted to explain in a little bit more detail what the difference is between a developer preview and a beta. Here is an approximation of the standard definitions of “milestones” – they are what I use for WED.
- Development: not all features are coded, no guarantees about bugs.
- Alpha: all features are coded, no bug is so severe that you can’t at least try a feature. (For example, if WED crashed on startup, it would not be alpha, because you could not test saving files.)
- Beta: all requirements of alpha, also no bugs that cause program crash or data loss.
- Release: no open bugs.
This all applies to known bugs. Beta software may crash and cause data loss – it’s just that we wouldn’t have put it out as beta knowing that this happened.
WED 1.1 is still in phase (1) – development, and the build I posted is a developer preview – a cut of whatever code I had laying around. So: I can’t promise it isn’t going to trash your data or crash! Be even more cautious with the developer preview than you would with a normal beta. You don’t want to run a five hour session without saving your work, and you want to be backing up your work often – the “save” command might trash your entire project.
Why do a developer preview if it’s still so buggy? Some users who know how to compile WED from its source code are already using WED 1.1 and they seem to be enjoying it. So far it appears not to be lethally broken. Given that and the fact that most of the uncoded WED 1.1 features are usability and edge-cases, it seemed like the developer preview could be useful for getting earlier feedback.
One last note: the manual is not updated at all, nor is there any documentation on the new features. Let me be clear: no tech support or help is provided what-so-ever. Do not email me, or X-Plane tech support with “how do I use WED 1.1” questions. If you cannot figure out how to use WED 1.1 on your own, don’t use the developer preview.
We’ve made some progress in transitioning XSquawkBox to be under Wade’s primary management – read more here.
First, I want to thank the X-Plane users who have gone through piles and piles of regression tests to isolate some of the peskier bugs. Often a bug only occurs on hardware that we don’t have in-house, so this detailed reporting is a huge help in shipping a program that has to run on a huge number of configurations.
Sometimes a user will offer to work around a bug by changing an add-on, or just dropping the add-on. But…I have learned the hard way: never ignore a bug you don’t understand.
First, the bug might run much deeper than the reported use. Perhaps the bug is actually affecting dozens of other add-ons.
If we don’t understand the bug, how can we say “this is so unimportant that it can be ignored”?
Now some bugs, once diagnosed, may prove to be not worth fixing. But…until the bug is fully understood, we have to take the time to dig in. We can’t just give up because the bug seems unimportant.
This is off topic, and I try to keep the off-topic political crap on this blog to a minimum. But I do want to put a plug in for Freecycle.
Freecycle is basically a series of locally based mailing lists for the free exchange of things you would have thrown out. My wife and I use it every time we move – we get packing materials from other people who have just moved, and then give them back to our new local group when we are done. We also freecycle all of “that old junk” that we realize we shouldn’t move with us to the next location.
If you are ever in a situation where you need to throw out items that are potentially useful but just not worth the cost of carrying anymore, please consider Freecycle – it strikes me as a reasonably reliable way to keep items out of landfills. (Especially hard-to-recycle mixed-material items like electronics.)
One note of caution: freecycle is just a group of people exchanging “stuff” in their spare time – typically it could be 2-3 days before someone can pick up your donated item. So…if you have a lot of stuff to give away, start early. I made this mistake in DC and wasn’t able to give away all of the items because people couldn’t pick them up soon enough.
Laminar Research has closed its Washington, DC satellite office and opened a new office outside Boston. Okay – that is completely cheeky – LR employees all work at home, and I have moved from the DC area to the Boston area.
This has put me a little bit behind schedule with, well, everything. I have four or so interesting example plugins almost ready to be published, WED is ready for some kind of developer preview, and I have some X-Plane 940 bug reports to go through. I hope to get the back-log cleared out this week. But first priority: unpacking the computers (and figuring out how to get an internet drop into the new home office).
