X-Plane 10.04 beta 2 is out now. Release notes here; like all betas, you’ll need to run the updater and click “get betas” to see this – it won’t auto-update until we go final. Report bugs here. Do not post bug reports on the blog.
A Temporary Outage
The beta was actually ready last night, but iWeb, one of our hosting providers, had a fairly major outage in the data center that the update servers are hosted in. The servers are now back on the net, so updates should work normally.
Our overall strategy for updates is to spread out the update pool over a few providers so that temporary outages only reduce capacity, not availability. In the short term, however, we have a lot of capacity at iWeb because their pricing is really aggressive and we had to push a lot of bits for the X-Plane 10.0 roll-out. This is the first outage they’ve ever had; if we see continued reliability problems we’ll get more aggressive about rebuilding our demo/update mirror.
Controlling Scalability
With 10.04 beta 2, the attached objects on the parking garage facade now shows more or less cars based on the object rendering setting. This means that if you have a computer that cannot instance and you run with lower object density, the KSEA is going to be a lot less expensive than it used to be. The facade engine also allows more control over object placement, which Tom was able to use to further reduce overall object count.
Our plan is to include this kind of object density control on all parts of the airport lego brick library so that the amount of “ramp clutter” is variable by user settings. Chris and I were in the terminal at KCLT waiting for a flight and looking out across the ramp, one thing was clear: there’s a ton of crap floating around the ramp at a major airport. With variable density objects, authors can put down major “mini-scenes” (e.g. a jetway plus docking position) and we will be able to scale from the minimum objects to make the sim functional all the way up to a ton of clutter for machines with good instancing performance.
What’s On the White Board
I have a white board on my wall with some of the highest priority bugs scribbled all over the place; I like it because it gives me an immediate view of what can’t get ignored, and when I am on the phone I can simply write down an issue that someone brings up. So far the white board issues tend to be in a few categories: crashes and serious bugs, performance, authoring platform features, and rendering artifacts.
With 10.04 beta 2 I finally had a chance to start killing off artifacts; the taxi lines should (previously they’d get all bent out of shape when they went around sharp curves) and the water shader is better. (The water shader still isn’t done, but there should be no more hard lines in it.)
At this point rendering errors and performance still dominate the board and my next few weeks of coding.
Ah, the taxi lines should. That’s great news! 🙂
Also, the bug report link in your post is broken. It needs more http://.
Thanks – link fixed!
Any update on the ATI performance problems on Windows?
Not at this time.
Hi Ben,
Thanks for your honesty with the ongoing issues. It’s refreshing to have developers that communicate with the community at large, esp. being a fellow developer.
As for the ATI issue, I know you’ve said it affects “high-end ATI cards.” Does this include the Radeon HD 6870, or just the 6900/7900s?
Thanks again for your diligence!
Chris
Yes, it affects the 6870 too. Basically if you have an ATI card on Windows and no matter what you do it doesn’t get good fps until you kill clouds and cars, you have this bug.
Yesterday, I had 2 (!) FPS in the clouds… Had 15-20 FPS before 10.04b2 with my ATI 6890/Intel i7. Something’s definitely not right. Hope you can sort this out soon.
Keep up the great work Ben, and everyone else at Laminar. You guys are doing great.
Hey Ben, just making sure before I dump this in the wrong place – are issues with DSF generation supposed to be reported via the same bug form or elsewhere? What data points (screen shot, coordinates, etc) are most useful to make things easy on you?
Errors in the global scenery (e.g. Sidney harbor is borked – don’t report that – we already know! 🙂 can be reported on the bug report form. I just accumulate them into the bug base in the global scenery category for triage once I have time to recut some tiles.
We may at some point make a more specific interface for this, but for now the bug report form is best.
Sidney…who is sidney, do i know him!
Last two updates are fixing many issues, thanks Ben, Chris and Austin.
Regarding density control, would scenery authors also be able to limit the maximum visibility that particular objects can be seen from in the upcoming scenery tools? (Admittedly I don’t know if this is possible with existing scenery tools).
I’m thinking for example that small objects (e.g. traffic cones) could have a max visibility that was set to 100 yards (configurable), and larger objects (baggage carts) set to 400 yards and so forth…
It could enable the ability to “cheat” as you put it in another post, giving good performance with high object density close to your viewpoint.
This is already possible, but it is done in the OBJ itself, via ATTR_LOD.
Hi Ben,
What Anthony describes is indeed handled by ATTR_LOD but his first three words, “Regarding density control …”, and the Controlling Scalability item in your post have more to do with the DSF commands “sim/require_object” and “sim/require_facade” which, although they’ve existed since DSFs were introduced in v8, I doubt most scenery authors are aware of, let alone use. The problem is there is no useful interface for these (unless I’ve missed it). Because the syntax of the command effectively uses an object index value, editing a DSF in a text editor to exploit this feature is too labourious and prone to error to contemplate. Now, if WED had a ‘Required Object Rendering Level’ setting in the properties panel for objects and facades, could the DSF exporter build the object index in the DSF file appropriately according to the authors settings … ??
Right. Here’s everything in play.
1. ATTR_LOD culls objects by distance, modulated by the world LOD setting. LOD is set on the object (or facade). This is not new.
2. The library can randomly select between objects, including blank ones. This is not new. The ratio of blanks to cars is immutable.
3. sim/require_BLA stops the random removal of hand-placed scenery. WED 1.1r1 (due out tomorrow if all goes well) adds customization of this. This is also not new, but being able to set anything other than “always show my scenery” is new to WED – code written last week.
4. “show_level” (new for facades in 10.04b2, for .agp in 10.04b3) is new to v10 and handles the “annotated” objects, that is, objects attached to facades and other scenery elements. These “sub objects” can now be thinned out even as the base structure exists.
So for example, take the KSEA parking garage. Its sim/require_fac setting guarantees that it ALWAYS shows up, but its attached annotated car roofs use “show level” to come in over time. So the derived attached car objects vary in density even though the facade is ALWAYS there. (The cars are not hand placed – they are “annotated” as part of a repeating roof pattern.)
Sir, did you mean WED 1.2r1 instead of 1.1r1?
Music to our ears if you mean what I think you meant! 🙂
No I meant 1.1r1. Here’s the deal:
1.1r1 contains overlay editing and is basically done. It will go final!
Approximately right after I finish that, 1.2 will go, well, “developer preview” or “beta” and get built with v10 features. 1.2 is bottlenecked by me not wanting two betas at once.
Buuuut: level control is in 1.1 since it’s an overlay feature and not v10 related. So no typo! But 1.2 is coming soon too, which gets you facade wall control, previews of AGS, and ATC layouts.
water shaders!!! woo hoo- great! no more lines over oceans lakes, , no more checkered dark puzzle pieces from outer space view! very excited to fly
THANKS
This is the very first update which actually improved my FPS according to the FPS test (from 6/6/6 to 7/10/10), great job :).
Hope someone fixes the power lines standing where they shouldn’t be (eg. on roads) some time… I am just mentioning, not meant as a report of course (not the place here now) …just a reminder because it looks so unrealistic.
On the general subject of fixing scenery. Ben’s mentioned in another post that fixing scenery defects is often done by re-cutting the dsf’s. In the above example I’m guessing this could mean recutting (nearly) all scenery tiles. Question: Would this mean all dsf’s (all 80GB of them) when then need to be downloaded again, or can the existing dsf’s be overlaid with smaller files to achieve the desired fix?
Most of the wide-spread powerline and road problems are actually bugs in how the sim renders the grid; no recut needed.
What about if/when we do have a whole-Earth recut? I don’t know yet. But I do know that some DSFs are more important than others, and the world is a big place, so at least we could recut “important” (by population density or scenic interest) DSFs more frequently, and/or phase recuts in regions.
Guys, you are doing a fantastic job. It almost made me cry when i first saw the game in motion. Came from FSX and aint returning. I know I shouldnt flood here and waste your pressious time however if you could answer one question you would make my day even better. Ok here comes. I have a GTI 560 ti, it runs the game very well, however, it is x16 card and the slot i have in my mobo is x16 but only wired as x4. I just ordered a riser flex cable to extend the “real” x16 slot. Do you think the performance will improve when stickin the card into this “pure” 16 slot? Thank you very much. Cant wait to get to work and take the 747 for a spin again!
4x vs. 16x…I don’t know. That’s a big difference in bandwidth but if bandwidth isn’t what holds your system back it will be moot. Still, we do recommend 16x.
Do you all plan on making better water colors? Maybe something more blueish?
i am waiting surf,Anthozoa,snow,dry wet,vc rain,airplane damage :-p
The sky is the best,the light nice….good work
Chris Sergio: I really like the improvements in ATC in Beta 2. The delays between ATC urgings and the lack of extra flack from AI commands are much better. Also Altitude entries to runway approackes are more manageable, although often, when entering the destination airspace, the vectoring of the aircraft to a 6000 or 7000 altitude at that point is rapidly followed by a reduced altitude of typically 3000 feet on the vectored return path which is often within 10 or 12 miles of the landing and makes for a steeper and more difficult descent than the typical 3 or 4 degree approach which is a roller coaster ride for faster aircraft.
Is there any thought of making transmission of ATC radio communications from BOTH COM1 AND COM2 Radios? Currently, it appears that Com 2 can only be used for ATIS access. If the use of COM2 for ATC could be provided, the preset of all ground control frequencies could be done there, and COM1 could be used for in the air ATC operation.. at the option of the user and making single handed flying much easier.
Best Regards and Thank you
Beta 2 is an excellent improvement… things are looking great!
New command-view control is great. This was desperately needed to really take control of complex VCs like rollons crj-200.
Still don’t like the way knobs are manipulated because sometimes I have to drag them 5 times all over the screen to get the desired AP figures – but I can live with that (even hoping that now, once mousewheel-function is welcomed in XP, one day there will be at least an “option” to control rotating knobs via mousewheel too;).
Thanks a lot, looking forward to each update and info. I´m enjoying XP10 more and more…
Flo
I looked at mouse-wheeling the knobs, but I don’t think the fit is obvious…to the sim a knob and a throttle are the same underlying tracking gesture, but clearly one is knob appropriate – for the other, the throttle would move out from under the mouse as you wheel, which would be sort of useless.
If you have to drag a manipulator too far that’s the fault of the model-maker.
Zoom is perfect for the mouse scroll-wheel: very useful, intuitive and consistent with in other windows. The only improvement I can think of is to add a touch of lag and overshoot to the panning and zooming. That would make it more natural and elegant á la — iPhone scroll functions — though very low priority in implementation.