500. 1 to write the new lighting code and 499 to work out the gajillion ways that backward compatibility gets broken!
Suffice it to say, there are a number of major bugs with aircraft lighting and drawing in 10.10 beta 6. Beta 7 is now out and attempts to fix most of them, but I fear there may be at least one more round of fixing backward compatibility bugs in airplanes.
If you have an aircraft (built-in, third party, or yours) that looks good in either 10.05r1 or 9.70 and looks borked in 10.10b7, please report a bug, particularly if the panel and panel lighting is not working.
Why is debugging aircraft drawing so difficult? It’s a bit of a perfect storm.
- The code supports a huge number of individual behaviors. A lot of the airplane drawing code was done incrementally, so even supporting ‘What v9 does’ means supporting the presence or absence of a large number of small features in every combination. You may or may not be using regions, may or may not be using translucency, may or may not be using interior lighting, may or may not be using the 3-d texture, may or may not be using generics, may or may not be using ATTR_lit_level, may or may not be using additive instrument lighting, may or may not be using auto-adjust levels, and I haven’t even started on the per-object check boxes and global OBJ attributes! (This list is a combination of flexibility, combining two complicated systems, panels and objects, and the “little at a time” approach which introduces a number of intermediate authoring modes into the airplane SDK.)
- A number of these options are very quirky. Sometimes they have long running bugs, sometimes they’re limited by hardware, and often using two together produces weird behavior.
- Often the quirks are useful. Rather than avoiding quirky weird behavior, lots of planes take advantage of it. Bugs become new features.
- We didn’t do much in X-Plane 9 to flag, warn, or prepare authors for X-Plane 10. While we knew HDR was coming, X-Plane 9 never flagged or squawked about old authoring techniques, so a “works in v9” plane might work because X-Plane 9 supports lots of old weird stuff.
- HDR rendering (with the deferred renderer) is fundamentally different from standard “forward” rendering (what we had in v9) and thus everything above has to be coded twice.
Ironically, the generous backward compatibility of the panel/cockpit authoring system in the past (including the ability to use all of the intermediate use cases of these features) has made backward compatibility worse now by making the problem space much more complex.
Unity For 10.10
As I have posted before, one of my goals is to make X-Plane 10.10 a stable and final authoring platform for v10 planes – that is, fix all of the rendering bugs so that if your plane looks good in v10, it won’t need any more updates or check-boxes changed. 10.05r1 did not meet this criteria because there are problems with airplane rendering in HDR that an author can’t work around – they are bugs in the sim.
As part of that process I am trying to create a single “right” path for authors to use the panel texture in an HDR compatible way. This consists of:
- GLOBAL_cockpit_lit gives you the newest lighting path. When this attribute is present, lighting is the same for regions and no-region panels, the panel texture is fully lit by HDR, and transparency works as well with a panel as it does with a regular texture.*
- With 10.10 the cockpit object has a full set of plane-maker check-boxes for control over shadowing, LOD, glass, lighting, etc., to make it consistent with the attached objects.
- In 10.10 any attached object on an airplane can use ATTR_cockpit or ATTR_cockpit_region as long as the cockpit texture does too. (This means you can mae your panel texture interior for lighting but reuse the cockpit texture in a glass object for a HUD.)
These features provide for all of the authoring techniques I have seen and work with both HDR and non-HDR. Most legacy airplanes can be updated simply by adding GLOBAL_cockpit_lit to the cockpit object and confirming that check-boxes are correct in Plane-Maker.
Logging Problems
With this beta I modified the non-fatal error reporter to handle airplanes. What is the non-fatal error reporter? You know it as:
Error loading the scenery package: /Custom Scenery/my_awesome_scenery/ The scenery may not look correct. Please see the log.txt file for detailed error information.
The idea of this message is that it puts up a single user-readable warning that something has gone wrong, while providing details on every error in the log. Authors can see all of their problems in one load of the sim, and the single dialog box is annoying enough to users that authors can’t ignore the problems.
A few things have changed:
- Airplanes can now participate in these dialog boxes, so we can give you one message that there are several problems with your airplane.
- There is now a “quiet” version of this that logs without the annoying dialog box. This lets us put warnings in that aren’t annoying yet but may become annoying in the future.
- The log output goes through the dev console, part of an effort to unify our logging efforts. You can reopen the log file without quitting or browse the dev console on screen.
I was asked a few weeks ago whether warnings in the log hurt performance, and my unsatisfying answer was “it depends on the warning.” But I can tell you this: any problem in your add-on that causes one of these “non-fatal error” dialog boxes should be fixed! We only use it when (1) there is a definite error in your file and thus it is not parsing properly or (2) you are using a very old technique in X-Plane for which a better replacement has existed for a while and the old technique is going away.
Don’t Overuse Translucency
One last note from the * above; this came up when Tom was working on the Baron, but I see it in third party airplanes too. While you can use translucency with the panel, I do not recommend it for building non-translucent elements.
Example: if you have an annuciator panel with warning lights that can flash then…
- I do recommend that you build the panel in Plane-Maker using panel texture and multiple instruments layered on top of each other. With GLOBAL_cockpit_lit (or regions) you will get correct 3-d and HDR lighting on this panel, and it will color match the rest of your cockpit object perfect.y
- I do not recommend building the annunciators out of clear areas in the panel and layering two polygons in the 3-d object (a back polygon for the back-plate and the panel texture for the front).
Why not overlap 3-d polygons? First, the OBJ format doesn’t provide a good way to overlap near geometry without risking Z errors. Second, and more importantly, you will not get correct lighting by using alpha and multiple layers. The annunciator panel should be affected by 3-d light including the flashlight and shadows from the sun; that won’t work unless you produce a single “baked” annunciator panel in your panel texture. Finally, any time you use alpha in HDR mode, there’s fine print and issues with the lighting, so use it when you really need alpha, not when you can get the job done with a panel texture!
Is the scrolling of 2D panels in small increments (rather than jump up or jump down) a new feature of beta 7? or did I smoke too much weed?
Yeah that’s new – the 2-d panel now continuously scrolls (position anywhere in 2-d) and then save your favorite points to the camera presets.
Loving it! I still use 2-d panels for my own planes, so this is highly welcomed!
Does it strike you as desirable, at some point Ben, to set aside the folly of trying to make X-Plane so backwards compatible? I realize billions of X-Plane users will cry foul, but if your progress is overrun with the past, then you spend more time accommodating the past than you do making the good new stuff work right….and part of that is, of course, the much needed migration to 64 bit. If users want to use an X-Plane 9 aircraft in X-Plane 10, it’s fair that they should convert it to X-Plane 10 standards before using it in X-Plane 10. Why should Laminar hold on so tightly to the past? It’s going to undermine the effort in the long run. Just my two cents. Flame suit on! 😉
No flame suit, it’s a valid question, and we can’t support everything forever. There are trade-offs:
– If we spend too much time making old stuff work, we won’t have enough time to make new cool stuff, and the sim falls behind.
– If we spend no time making old stuff work, the useful lifespan of an airplane will become small, which is a strong dis-incentive to make anything.
Two thoughts on the current transition:
1. HDR is just a tough nut to swallow, because the deferred renderer causes a lot of visual problems with even the _most_ modern content authored for v9. So to completely punt would set the backward compatibility window to be very very short. New content causes almost as much problems as old because the big variable is the change in rendering tech.
2. The real problem with the panel/aircraft system I think is creeping incremental development of non-orthogonal features. The scenery was a lot more carefully road-mapped and has been much cheaper to maintain. Many of the old decisions that cause problems in v10 date back to a time when both Austin and I were working on panels and airplane drawing, with no clear road map.
So my take-away is that the next set of panel work needs to be a single set of coherent changes in one shot that makes sense in a bigger picture road map…otherwise two years from those features debut I’ll be cursing myself all over again.
Thanks, Ben. It sounds now more like you’re trying to get all of the HDR bugs out now, and once that’s done (will it ever be done?) then we’ll hear less about the rendering engine and backward compatibility and more about the growth of XP10 and the sim’s stability? It seems to me that the challenge of enhancing the plausibility of the world is a pretty important thing these days. I know you dislike hearing about other products, but you gots to know that the future is coming at us pretty darn fast. Ever read “Future Shock?” 🙂
Right – I am trying to concentrate force a bit on one set of bugs here…
Non-orthogonal features are the way forward. Orthogonal is a step between textbook and full simulator: learning procedures and cockpit layout. At one point that’s all we had to fly with. That’s no longer the case, and what keeps me interested.
I’m not afraid of change but when a poorly documented change breaks a year and a half of work, it’s the community that misses out. Random example: Laminar models turbulence; we make heads bob, coamings move, wings flex, and even sounds tuned to all that. Change the turbulence model and all the fine tuning goes out the window. That applies to anything: engines, aerodynamic behavior, lighting….
I believe the first rule should be do no harm sans explanation on how to fix what one spent countless hours tweaking. (Not that I’m complaining; XP10 is breathtaking.) Point is, docs — with examples or verbosity aimed at those who use the new features as opposed to those who developed it — are important. The custom props and strobes are brilliant examples of such. Unfortunately not everything can move forward in-step.
On another point, I’m curious about the coercion on power-of-two panels and square, draped orthophotos. Rectangular ones seem to work fine on the latter. Is it purely efficiency or are there other practical reasons? I can: (a) leave it rectangular, (b) cut it into three squares (much more fitting work without a snap to line feature), (c) add empty space to square it and stretch the fit, or even (d) stretch the ortho and squeeze to fit….
You can expect two reports on deferred rendering issues (I believe) soon on b8.
First: I don’t think I mean the same thing as you re “orthogonal”. By orthogonal I mean two features that have no impact on each other. For example, object manipulators and object material attributes are orthogonal because you can use the two and they do not change each other’s operations.
Re: power of 2 panels, it’s an efficiency thing, and it’s only for panels used as a source texture for the 3-d cockpit. In that case, we’re asking you, in your future work going forward, to pick a power of 2 size. Since the 3-d panel texture is usually “packed” anyway (no need for windows) aspect ratio should not be that important. We’ve been encouraging this for a while.
Re: square orthophotos, I have _no_ idea what you’re referring to here; there are no restrictions that I am aware of on draped pol or ter image usage. If something doesn’t work (e.g. “if my draped pol is non-square the sim crashes”) don’t post here, please file a bug, because there is only a power of 2, not an aspect ratio rule.
Some authors DO intentionally use square textures because the largest texture you can have (now 4096 x 4096) is sqaure – the max dim on both sides.
X-Plane is reporting that beta 8 is available? 🙂
“There is now a “quiet” version of this that logs without the annoying dialog box. ”
How is this noticeable? I still get the dialog box every time for various scenery packs. Very annoying, the packs work, despite moddifying them or a location using multiple ones. Rather not see that error each time
First: the new quiet warning is NOT noticeable to you; we are using it only for NEW warnings that we are adding to the sim. If a warning is already “annoying” (meaning it can cause the dialog box to pop up) it is going to stay annoying, and the annoying warning mechanism is going to, by design, remain annoying.
The idea here is that if we have a unified interface in the sim for issuing warnings that _may_ be annoying, we can start adding new warnings now, make them annoying later, and then even later rip out the feature, giving authors a progression (see other posts).
We are _not_ going to make the annoying warning quiet!! It is annoying _by design_. If it is not annoying, authors will simply never bother to fix the warnings, and the warnings would not be annoying if they didn’t need fixing.
Examples of annoying warnings include:
* Totally broken syntax in text files that causes X-Plane to have to simply discard part of the authors work.
* Missing art assets.
* Illegal use of X-Plane commands in text files that causes X-Plane to have to throw the commands out.
E.g. we don’t use the annoying warning without reason!
Ben, I hope you can work this out, as I fear you might be missing a window of opportunity in regards to new developers coming onboard and adding to he world of X-Plane.
It’s great that the sim is constantly evolving, but developers aren’t going to be too keen if the acf’s they produce have to be constantly updated, as it just means extra work.
I know you are working hard to sort out the bugs, but I am just wondering if sometimes unintentionally you make more work for yourself by implementing new ideas which clash with existing code. Now, I am no programmer, far from it (10 print ‘run” lol) but isn’t there a way you can separate components so they don’t clash? Feel free to shoot me down as I am but a mere thicky when it comes to these things, lol
Dom
Dom, you are spot on with “isn’t there a way you can separate components so they don’t clash” – that’s what I mean by two orthogonal features. Two features are orthogonal if the operation of one doesn’t induce fine print on the other.
One of my goals with 10.10 and GLOBAL_cockpit_lit is to create a truly “orthogonal” interface between the 3-d panel and the cockpit object. When you use GLOBAL_cockpit_lit, all of the rules for lighting and texturing work just like they do for normal object textures, which helps orthogonality.
I’m referring to the WED manual:
“The images in the following chart, though, could not be used in X-Plane, due to either their resolution or file format…
NotSquare.png 1024 x 2048″