Tweet
Re: Système anti-ice des avions
heu
from ben spunik (ça crains MBR...After attention NE PAS SE PRECIPITER SUR LA 9.30......)
Accidental Contracts
In a previous post I ranted about the hidden cost of adding new third-party-accessible features to X-Plane - that cost being the cost of supporting the APIs way into the future so that third party content doesn't break.
Even trickier are accidental contracts - that is, unintentional behaviors that the sim exposes that third parties take advantage of. This can be particularly tricky for us because we might not even realize that the behaviors are happening.
In 921 we allowed the HUD to be visible in the 3-d cockpit for planes that use our "default" 3-d cockpit, like the 777. Ignoring that this was a truly silly feature to do, one of the side effects of the code change was that EFIS glass instruments now render correctly over transparent parts of the panel texture on some hardware. Javier immediately jumpedon this to build a 3-d HUD.
These EFIS glass instruments appearing in that region was totally unintentional, and this is about the last way I wanted to implement 3-d HUDs, but now that it's in there, I have to ask: do I want to break Javier's airplane, which a lot of users will like? Probably not!
Another accidental contract is the draw order of the cockpit objects. Basically due to a coincidence of how the code is structured, the external cockpit object is drawn before attached objects, but the internal cockpit object is drawn after. There is no good reason for this, but now that authors build airplanes based on this, we have to preserve it because changing draw order can break translucent geometry.
X-Plane is full of this kind of thing - and all of these hidden conventions make it tricky to restructure subsections of the code.
Al Bedo Makes an Omlette
Sometimes you have to break a few eggs to make an omlette. Or at least, you have to consider whether breaking them is acceptable. Often I hit cases where the cost of supporting a legacy feature is somewhat painful.
One way to decide what to do is to change the feature early in beta, see who squawks, and then change it back if necessary. There are two I am looking at for 930.
Glass Instruments
It turns out that glass instruments fade to black, not to transparency. This is a little bit weird, because that means they will leave black footprints if they are on top of a non-black background. My guess is that most people use them on black screens and thus did not notice.
If people really need fade-to-black glass instruments, I'll just create a new lighting type (glass-transparent), but if everyone can live with fading to transparent, it's certainly the more useful case and probably what most people always wanted.
Separate Specular Hilights
For as long as I've been involved, X-Plane's specular hilights are modulated by the object or airplane texture color. In other words, if you paint your airplane red, you get red hilights, and if you paint it black, you get no hilights at all.
This is not a very good way to do things for a few reasons:
* Under this scheme, you can't make a shiny black object.
* Someday we will add gloss maps - but the glossy part of the gloss map will be defeated by the black texture.
So for 930, I am looking at not modulating specular hilights by texture. (This is called "separate specular hilights" in OpenGL lingo.) My guess is that they will look enough better in almost every case that people would rather have it this way.
Should specular hilights be white for a black object? Yes! A specular hilight is a simulated intense reflection from a very far away, very bright object (the sun). So it should take its color from the sun, not the object itself. To this end, I have also (finally) set the specular hilights to take on the daylight sun color, so that they get fainter and yellowish at dusk. This makes dusk and dawn look a little bit less strange.
(Nerd note: Technically, for the day texture to be an albedo texture, it shouldn't affect specular hilights.)
heu
from ben spunik (ça crains MBR...After attention NE PAS SE PRECIPITER SUR LA 9.30......)
Accidental Contracts
In a previous post I ranted about the hidden cost of adding new third-party-accessible features to X-Plane - that cost being the cost of supporting the APIs way into the future so that third party content doesn't break.
Even trickier are accidental contracts - that is, unintentional behaviors that the sim exposes that third parties take advantage of. This can be particularly tricky for us because we might not even realize that the behaviors are happening.
In 921 we allowed the HUD to be visible in the 3-d cockpit for planes that use our "default" 3-d cockpit, like the 777. Ignoring that this was a truly silly feature to do, one of the side effects of the code change was that EFIS glass instruments now render correctly over transparent parts of the panel texture on some hardware. Javier immediately jumpedon this to build a 3-d HUD.
These EFIS glass instruments appearing in that region was totally unintentional, and this is about the last way I wanted to implement 3-d HUDs, but now that it's in there, I have to ask: do I want to break Javier's airplane, which a lot of users will like? Probably not!
Another accidental contract is the draw order of the cockpit objects. Basically due to a coincidence of how the code is structured, the external cockpit object is drawn before attached objects, but the internal cockpit object is drawn after. There is no good reason for this, but now that authors build airplanes based on this, we have to preserve it because changing draw order can break translucent geometry.
X-Plane is full of this kind of thing - and all of these hidden conventions make it tricky to restructure subsections of the code.
Al Bedo Makes an Omlette
Sometimes you have to break a few eggs to make an omlette. Or at least, you have to consider whether breaking them is acceptable. Often I hit cases where the cost of supporting a legacy feature is somewhat painful.
One way to decide what to do is to change the feature early in beta, see who squawks, and then change it back if necessary. There are two I am looking at for 930.
Glass Instruments
It turns out that glass instruments fade to black, not to transparency. This is a little bit weird, because that means they will leave black footprints if they are on top of a non-black background. My guess is that most people use them on black screens and thus did not notice.
If people really need fade-to-black glass instruments, I'll just create a new lighting type (glass-transparent), but if everyone can live with fading to transparent, it's certainly the more useful case and probably what most people always wanted.
Separate Specular Hilights
For as long as I've been involved, X-Plane's specular hilights are modulated by the object or airplane texture color. In other words, if you paint your airplane red, you get red hilights, and if you paint it black, you get no hilights at all.
This is not a very good way to do things for a few reasons:
* Under this scheme, you can't make a shiny black object.
* Someday we will add gloss maps - but the glossy part of the gloss map will be defeated by the black texture.
So for 930, I am looking at not modulating specular hilights by texture. (This is called "separate specular hilights" in OpenGL lingo.) My guess is that they will look enough better in almost every case that people would rather have it this way.
Should specular hilights be white for a black object? Yes! A specular hilight is a simulated intense reflection from a very far away, very bright object (the sun). So it should take its color from the sun, not the object itself. To this end, I have also (finally) set the specular hilights to take on the daylight sun color, so that they get fainter and yellowish at dusk. This makes dusk and dawn look a little bit less strange.
(Nerd note: Technically, for the day texture to be an albedo texture, it shouldn't affect specular hilights.)
, fermeture de l'aéroport de Marseille (pas par une sardine mais par la neige).
Commentaire