At this point, light levels in our previews are not reflective (no pun intended) of how the sim will really look. The reason is simple: the light model is not fully debugged (who am I kidding -- it's not even remotely debugged) and it only takes one light model bug to completely throw off the light levels. So I think light levels are going to be a case where the sim's lighting looks a bit funny right up until the last bug is swatted - it's just the nature of those kinds of bugs.
To give you an idea of how much change there is in lighting from version 9 to 10, here's a short laundry list of sim changes that affect lighting:
Dynamic Exposure. X-Plane 10 reduces the effect of emissive (_LIT) textures base on the brightness of the sun. In X-Plane 9, emissive textures have the same impact regardless of time of day; thus a lighting effect that looks good at night will look too strong during the day. (In real life, you eyes would adjust for the sun and the artificial light would seem less bright.)
Linear Light Mode. This gets confusing fast, but basically, our eyes perceive light in a non-linear way; we are more sensitive to low light levels than bright light levels. Computer graphics mimick this behavior; the result is that most computer lighting models are physically incorrect in some circumstances. Using the non-linear eye-based behavior has been the norm for while because it was cheaper hardware-wise, but these days it is possible to do physically correct linear lighting. We are adding this wherever we can; the correctness varies with rendering settings since physically correct lighting is more expensive GPU-wise and we don't want to hurt fps for low-end users.
Deferred Rendering. X-Plane 10 has two rendering modes: a forward renderer (which is a lot like X-Plane 9) and a deferred renderer that supports global illumination and an HDR rendering space.* This creates a certain amount of chaos because the code for forward and deferred rendering are separate, and they seem to develop separate, unrelated lighting bugs.
Global Illumination. X-Plane 10 supports global illumination in deferred rendering mode, which means that thousands of lights can light up any part of the scenery system. Thsi means that (for the first time) an object may be lit by dozens of light sources at once. It turns out that the linear light model is a lot more important when we have more than one light source. (In fact, Alex and I realized that we needed a linear light model when looking at highways lit by streetlamps.)
New Light Billboards. X-Plane, like most flight simulators, uses billboards (textured squares that face the camera) to draw the light effects near a light source, like glare and bloom. The shape, textures, and equations for the light billboards are heavily revised in version 10.
Clouds. The weather system is being rebuilt, including new shaders for cloud puffs. Since cloud puffs aren't like solid buildings or airplanes, they have their own shaders with their own light characteristics. We are also experimenting with increased ground visibility, which affects fog.
* Some users may confuse HDR, which just means an image with increased dynamic range for light levels, with the more common effects that games ship once they have an HDR render: bloom and tone mapping. Bloom is when bright light sources "blow out" and splat light around nearby areas; tone mapping is a technique to visualize that high dynamic range on a normal monitor - often it is used to simulate your eyes adjusting to variable light levels.
I do not think we will ship bloom in version 10.0; I experimented with it and found it had almost no value. First, there are very few scenes in a flight simulator where bloom is that useful; it seems to be a lot more useful for interior rendering, like you'd see in a first person shooter. Second, X-Plane already has a number of bloom-like effects, including halos around lights via billboards, sun glare, etc. With most of the important cases already covered by ad-hoc effects, my early experiments with bloom weren't very promising. We may revisit bloom later, but I don't think it's as important as other effects for now.
Similarly, I don't think we will have dynamic tone mapping because we will have an overall dynamic exposure control running all of the time. Again, the value of tone mapping is more obvious with first person shooters, where you can go from interior to exterior and you want the world to be 'overpoweringly bright' for a while. By comparison, pilots do their best to preserve their night vision, and the interior of an airplane is designed to match that; instruments auto-calibrate their brightness to the overall light levels, making tone mapping less important.
8 comments:
Interesting post. But we are going mad about just seeing more examples. More screenshots. Just examples of what is being worked on right now and what we have right now. You do not have to unfold every little detail, just give us some little glimpse of what is being worked on atm. Pretty please!
A lot of tone-mapping I see in games is more reflective of what a camera sees to begin with... when I'm in the shade of big trees in a wooded area the sky doesn't look white to my eyes...just to my camera. The game effects are largely done just because they can do it and say they've added a feature. It's somewhat distracting when those games are constantly tweaking the brightness of the sky and landscape.
Ben, you've commented in the forums that you'd like to see more regionalisation of scenery for XP10 but that the scenery file formats will be more demanding (not your words exactly but of that tenor). I've been working on a city scenery on-and-off for my hometown which employs rules-based procedural object generation seeded with real world GIS data. The aim is to automate the generation of the final XP file formats into the pipeline as well and my current thinking is to hold the whole project over until XP10 file format specifications are available.
Is there anything fundamental in the object/texture creation that will likely mean I'll have to revisit the current process (which generates a single Blender file full of placed and textured buildings which a script will parse, culling objects into separate files and generating the XP DSF)?
Basically if you produce an output list of object placements and OBJ models, you can continue to do this in v10, and it will work at least as well as in v9. You might want to take advantage of draped geometry:
http://xplanescenery.blogspot.com/2010/10/draped-object-geometry-in-x-plane-10.html
that is, the ability to have ground overdraw textures anchored to the object that properly sit on top of the ground. Also, v10 will have some OBJ performance enhancements that you'll want to make sure you are using to get maximum throughput with lots of objects. (Part of this is just having OBJs with no crud, and part is using things like the new draped geometry instead of the old ATTR_poly_os.) There will be authoring guides with instructions on what to do to hit the 'fast path'.
So you don't have to use the new v10 autogen system..the autogen is higher level than OBJs, but placing OBJs still works and the OBJ is the way we draw everything 3-d.
Will the runway lights suffer (they are the ones that interest me) of attenuation, loss of intensity as we move away from the light bulb?
A light bulb (blue or green) at 3 Km (about 2 nm) of distance cannot be practically the same intensity as one that is at 10 m (about 33 ft).
This is even more strange when you see the runway lights (departure/arrival) and you go at 10000 ft.
Runway lights intensity (the way we see them) should also be affected by general lighting (sunny day, cloudy day, sunset ...)
Regards
Wow Ben,
That is a lot to digest. I just wanted more realistic night skys which simulated normal light polution levels but it seems you guys are going way beyond that. Kudos, I can't wait to see how it turns out.
Ben, the problem with trucks speeding through neighbourhoods that plenty of us have noticed but not really reflected on can be easily fixed by adding a rule to the autogen algorithm. The problem (in most cases) is not trucks speeding through neighbourhoods but that houses are allowed to be placed too close to -motorways-, which is apparent in the actual screenshot. Simply by adding a rule that neighbourhood houses can not be placed nearer than lets say 25 meters to highway-tagged roads the final result will for sure look a lot better.
I think you already have implemented rules for trucks not being allowed to run down neighbourhood (-tagged) streets.
Happy coding and I am really looking forward to placing an order on XP10! Evan
I bet the simmers that are complaining about the "too dark" night lighting in x-plane are users who believe that MSFS night lighting - with its extreme ambient lighting at night and no contrast - is realistic. Please don't let they degrade the excelent x-plane lighting engine into the poor MSFS lighting engine for god sake! By using MSFS - with its wrong ambient light - those users have been brainwashed by decades to believe that they can distinguish the ground textures where there's no light sources. Take a look on MSFS landing lights by instance. No one need to use landing lights in FSX because you can clearly see the ground texture in front of the plane even where there's no light sources at all.
Post a Comment