First a quick note: X-Plane 10.10 Beta 11 is now out. What happened to beta 10? It lasted about 15 seconds, from when it went live to when I realized that aircraft were missing and code signing was screwed up.
We’ve had a few of these “beta bounces” where a beta lasts less time than a Plutonium isotope. The basic policy is this: if we cut a beta and it is live on the net at all, even for one second, and we then realize the beta is borked, we cut a new beta with a new beta number. Thus the very short life span of beta 10 – we didn’t reuse the number 10.10b10 when we fixed the problems.
Why not just reuse the beta number? Because we want to make sure that anyone who accidentally gets the broken beta gets the new beta, and to do that we have to bump the version number. Now that X-Plane auto-checks for updates, people get the new beta within seconds of it going live.
Autogen
A while ago I posted a road map for our autogen cities. Part of the work involved improving the road generation algorithm (a lot of which has been done for 10.10, and some of which still needs more work) and part involved new art assets.
Our original plan was to include the latest art assets with 10.10, but we are now planning on releasing the next round of city art assets with 10.20, the 64-bit version of X-Plane. There are two reasons for this:
- The urban assets aren’t entirely done, but they are very inter-dependent. To maximize framerate, Propsman shares as much texture as possible betewen parts of the urban package, so it’s quite tricky to release part of the autogen.
- The new autogen does take a little bit more memory. Not tons more, but for a user on the red line with 32 bits, upgraded autogen might require memory that isn’t available.
So rather than take up Propsman’s time finding a way to cut off and release part of the art assets, only to hear from users that thy are out of memory on OS X, we’re thinking it’s better to get on with 64-bit and release the art assets as a whole on a build that can handle them.
I think we may be able to release the new road pack with 10.10, and a number of other art assets are already in the 10.10 betas – new aircraft, upgraded global terrain, and new lights.
That makes sense. Any rough ETA on when we’ll see a 10.20? It sounds like you’ve already been making progress towards it while 10.10 is in beta on a branch. Is that in a shorter timeline (few weeks) or is it months away?
No time estimates – we just end up with a flamefest if anything in the plan changes and the original estimates aren’t right. When we get close to a 64-bit beta I’ll post to get plugin developers some notice. Eager plugin developers can start cleaning their code for 64-bit now using the 2.1 SDK.
As much as he and I want to know when, Ben is exactly right. However, I look forward to both all the art assets and 64bit finally, will be a real game changer under OSX. Hope to see more posts on progress and release sooner than later. Really anxious for this important needed update. More new planes would be great too!
Thanks guys
Hey Ben — as we keep improving our OSM neighborhoods in order to better support the 10.20, is there anything else that we can do besides fixing roads? Which landuse tag values (landuse=residential, landuse=industrial, landuse=forest…) are you planning to recognize/use at this point?
Thanks!
I think for the first recut we are not planning to use more OSM data – just to do better with what we have. I am not sure though, as the plan on what we do next is not complete yet. The big thing is roads and water – water should be blue on the OSM map (and I must fix bugs so we import it properly in all cases) and roads should have their bridging, layer and one-way set correctly.
Of course we are not the only x-plane tool to use OSM, so for Benny’s building importer there can be other tags…
As a side note, we don’t uns OSM landuse tags (opther than maybe the parks in the cities if I recall correctly). As we need global, and more or less consistent landuse information OSM is still a no-go (as so many places are not covered by it). But with great scientific sources like CORINE (for Europe), NLCD (USA), CLDB (Nez Zealand) and GlobCOVER (for the rest of the planet) we have a quite good basis (quality vise too!).
This article is quite old already, but it covered a lot of the basics of the scenery (data part too):
http://xplane10.wordpress.com/2011/12/10/developer-interview-andras-fabian-mr-x-terrain/
64 Bit is really an awesome news. One thing scare the hell out of me though, it’s about third party aircraft with their own plugins : they won’t work in 64 bit, and will need to be redone by their authors. We won’t be able to fly our favorite planes in the meantime, and the time gap might be somewhat big.
We are going to ship 32 and 64 bit versions of the sim – 32 bit is NOT being dropped, as some users won’t be able to run 64 bit. So you’ll have the (non-ideal choice) of running 32 bit with add-ons or 64 bit without until your add-ons “go 64”. The ppc->x86 transition for Mac users was the same way, except that for an x86 Mac, the PPC version was unusably slow. In this case the 32 bit version is what you have now, you just won’t be able to push the tex res and autogen as far as your hardware might otherwise allow.
I hope the first 10.20rc won’t nag 10.10f users (with legacy hadware, OS’es or critical plugins) that an update is available on launching XP. It’s fine if you’ve checked the beta button; not so fine if you haven’t.
Not sure where you got your version numbers but: at any given time there are two versions of the sim “published” – the current final release and the current version in beta test. When a release candidate isn’t finalized, it is in test.
So right now our final is 10.05r1 (numeric version 100501) and our current test is 10.10b11 (numeric version 101011).
If you have the current final you do _not_ get nagged that there is a newer in test version! So 10.10b9 users got an auto-notice to get b11. 10.05r1 users don’t get nagged at all.
Hi Ben, glad X-Plane is still keeping you up at night. If you want some candles and matches I know a local store which is having a sale on at the moment if you buy bulk!!
Just a quickie; is there work still being done on optimising clouds? They are still a deal breaker for many users.
Even when cutting back to 10% clouds can cause problems. Adjusting roads and buildings doesn’t seem to make that much of an impact. Extreme or none, it’s pretty much the same. For many uses a fine day brings very high frame-rates (60+), but as soon as clouds appear it’s slideshow time (19-).
Is optimising clouds in the pipeline, or are they a low priority?
Cheers
Dom
I don’t expect the clouds to get any faster than 10.10 for a while – we’ve done all of the big things we can do. I might be able to squeeze a few % more out of the shader some day but that doesn’t make a game changer.
The one thing that could be better: a lot of airplanes (in our fleet and otherwise) don’t prefill the 3-d cockpit – that’s an optimization that can make a big difference for users who are fill-rate bound on clouds.
I meant 10.20r1 versus 10.10f but your answer to Mickaël Guédon answers a lot of other questions for me. The 64-bit won’t be painless for all but very welcome for those who can handle it. I’ll just have to wait for Tim Cook to give us a Mac Pro with a decent graphics card as well as wait for a few plugins to catch up, and stick to the 32-bit until then. Of course, I’ll run the 64-bit to see what happens. (On the quiet.)
With a fire extinguisher handy.
Right – for what it’s worth, if your hardware is old and can’t really keep up with X-plane now, 64 bit isn’t going to be terribly useful because all it does is let you run with higher settings. 64 bit is only useful if you run out of memory on settings that would otherwise have high fps.
Hi Ben, in regards to other users acf/ plugin concerns, I assume the most recent nice payware planes won’t be an issue , correct?
ie the CRJ, C-17, upcoming 777 etc
Chris: per our previous request, only post ONE comment per blog post.
Re: 64 bit and plugins, no. There are NO 64 bit plugins yet because a complete SDK is unavailable. Therefore no current add-on, no matter how new, is 64-bit ready. Every add-on maker who uses a binary plugin will need to create a 64-bit version in order to be 64-bit compatible.
64-bit is just like adding a new operating system: until the plugin author builds a version for that target, that target won’t be able to use the plugin.
Right right, sorry my bad.
re 64bit add ons- will you guys be in contact with developers of such planes and all and or make it obvious to them to make updates so that when 64bit comes we don’t end up losing high end items that we paid for and plugins for substantial more time?
I think developers are already very much aware of the 64-bit situation, as we have posted about it extensively on the blog, users discuss it all the time, it is mentioned on the SDK site, etc.
great, because if many planes go out the door function wise, especially expensive pay wares, that would be terrible.
I look forward to more 64bit progress news, can’t wait.
1 last thing- when some planes load without the or (a) plugin, you may get a warning that says it will not work correctly. Would it be possible to simply remove the plugin from a acf folder and run it anyway in 64bit xplane 10?
It depends on the plane. Generally if you remove the plugin, some part of the plane will stop working.
I just tested me theory, some worked no change, and some a few visual issues, i.e. thrust reverse engine covers. Problem is development is dead or in limbo on some planes and xpushback- so there wont be a pushback truck tool anymore. , trade off, may lose some nice planes or the full functionality. guess thats one way to trim a library down, but..
Thanks for the information
Wouldn’t it be a good Idea to give the Plug-In Developers advanced copies of the 64bit version, so they can a) get started on redoing the vital plug-ins, b) give you feedback on how 64bit works with their changes and general viewpoints?
Having 32bit and 64bit sounds messy… I thought that FSX was 64bit but it isn’t….
The public beta will _be_ that advanced copy for plugin authors! That way any plugin developer can participate.
This is another pointless “you guys are doing awesome!” posts…
You guys are doing awesome!
Really. I never would have believed that so much could be drawn on 2500 pixel display and still run fluidly (if such is a word)–a mobile GPU at that! And its still not 64 bit?!
The update in “autogen” is badly needed. Europe, especially the big cities, look like crap in xp10. simply ridiculous.
i think that laminar is to slow in keeping “up” with those improvements.
ai-traffic is another point. it is still a pain to see airplanes stuck in the middle of the grass between the runways or doing other stupid thinks.
i feel laminar is still to slow or even not professional enough to fix this elemantary things just in time. hire more people and become more professional if you guys want sucess against lockheed…
I have to agree 100%.
While I absolutely admire things getting done and tried in new betas, I also think that the to-do LR list has wrong priorities.
I would sure enjoy new lighting techniques, supersonic model improvement etc. but the most important for me and I am sure many others is to see the world as close to real one as it can get.
I am flying around NYC and Boston as it was already after 3rd World War ..lol
I would like to say again, I admire and respect the efforts of all LR team in all X-Plane areas but the priorities in my opinion are upside down.
Cheers, AJ
Totally agree… Even though XP10 is a great product, it is also common to hear people say “it does not seem good” or “it is very different to what I knew”.
And I think part of the problem is how things are told. UI changes get lost among many different comments like “blah blah blah ATTR_cockpit_blahblah”, and peple that have not a technical background get confused. Also, all the modifications to the default airplanes, which are a great effor can be short to “Airplanes do now look better”.
My point is that now FS does not exist any more, in order to increase the user population (that will give you more $$$), a marketing effort has to be done. We’ve heard dozens of times about the “plausible world” (which, by the way, is an incredible piece of rendering engine). It is needed that more and more people come to XP, so third party developers will focus their attention on it.
By the way, my congratulations on the product. My comment is not about it, but about how it is marketed. XP10 is great, and it gives me loads of incredible flying hours!
Our priorities for features are _not_ directly observable from the list of what has been done on 10.10 for two reasons:
1. Features that have gotten a lot of work but are not done are simply not listed at all. But that does not mean they have low or no priority. Alex has done pretty much NOTHING but autogen since X-Plane 10 shipped – that we have had Alex do only this is an indication of how high priority it is, but since the work is not done, there is no indication of his progress yet.
2. Not everyone in the company works on the same features. So if Austin changes the supersonic model, this does not mean that autogen is low priority. It does mean that autogen bug fixes were on _my_ plate (and I fixed a number of autogen and road bugs, some of which are not in the release notes because only Alex sees them because the new autogen is not released) and autogen was not on Austin’s plate, freeing him to work on physics.
I fully appreciate the frustration that you and other users feel seeing incomplete autogen. The only ones who are more frustrated are Alex and myself, because we (1) know what it will look like when done and (2) have been working on pretty much nothing but autogen for literally _years_. So I cannot and should not say “do not complain about autogen” – of course you would like it to be done! But I can say that it definitely IS a very high priority!!
Hi Ben,
As long as autogen stays as a HIGH priority , we will just keep our fingers crossed and wait…*smile.
Thank you a great simulator.
Andrzej
I think a priority of fixing bugs and performance issues are highly important. I also believe that finding the right amount of percentage between eyecandy and performance is neccesary in order to have a simulator that runs smooth.. As the end user and developer I can honestly say I do not want a replica of the infamous Microsoft Flight Simulator platform where performance has from the gecco went down the drain..
When performance and bugfixes is fixed or solved I think an focus on eyecandy could be great, in regards to autogen I aslo believe that this must be one of the first priority the company should have, then of course texturs.. US looking textures, houses etc. in Europe and other country is not realistic or just an american dream he he.
Anyway, XP is by far the better choice and if 64bit and seasons are coming in the future, Ill think you have a masterpeace on your hands, and I for sure would purchase every new edition there is…
Good luck
I appreciate your efforts to get the airport lighting to look the same with or without HDR enabled. And I can see that you’re still working on it. I’m sure you’re already aware of this, but airport lighting way too dim to be of use in b11. HIRL edge lights are practically invisible at distances greater than one mile. I realize that many of the lights are directional but even looking directly down the runway, it’s impossible to use them for alignment. ( I guess the good news is that they look pretty much the same with or without HDR enabled )
I’ve filed a bug report just incase you aren’t aware of this so I’m not trying to report a bug in this forum. But I do have a suggestion / request / plea. In real life, ALL runway lighting intensity is adjustable by the controller, and at many airports also by the pilot. Is this function possible to add to X-Plane 10?
I’m not sure the status of pilot controlled lighting – I think the dataref still works, but the ATC menu system doesn’t have it any more. But I am not 100% sure.
+1
The runway edge lighting is practically invisible. It ruins the best part of XPX which is the night flying. Is there a way to manually turn it up ? Maybe you could add something to the rendering options so we can turn it up or down !
Will we have to re-buy x-plane 10 to get the 64bit version or will the 32bit version CD key work?
No re-buy. You’ll have the 32-bit and 64-bit version and you can run whichever one is best for your OS, your computer, and your add-ons.
Time for a screenshot of almost “what it will look like when done”? Maybe that will calm the hordes. 😉
when he time is right prior to release, that would certainly alleviate mine and many others anticipation inquires.
Great idea. And some showing-off à la “will blow FSX out of the water”, “hyper realistic” etc. etc. would be very helpful too. The best with X-Plane is the imagination of what it could be…, isn’t it?
Seriously: New Autogen will be released for both versions (32/64), right? So those having no ram-issues (like me) will “be able” to stick with 32bit until plugins are reworked for 64bit, right?
Thanks
Flo
We will release it for both. What we are not sure is how we can smooth off sharp edges on the 32-bit version. We have tossed around ideas like not allowing the absolute highest settings on the 32-bit version, but nothing has been finalized.
I know you have a ton on your plate, but it might be worth checking out SMAA if you don’t already know about it:
http://www.iryoku.com/smaa/
Might be a cheap (programatically and computationally) way to add a middle ground between the “ok looking” FXAA and “awesome but my computer is melting” SSAA antialiasing options in HDR mode.
I dunno about cheap – what they’re doing is combining a filter based scheme (a la FXAA 1.0 and MLAA) with an over-sampling scheme (a la SSAA/MSAA) in a sane way. I can confirm the author’s comments: if you either apply a filter first and then a resize or a resize first and then a filter (e.g. using filtering and over-sampling one after the other in either order without them being aware of each other) the result is a fail.
But this isn’t cheap because it is doing both a filter AND over-sampling! This is a way to make SSAA and FXAA both work for even BETTER results. That’s not cheap.
More advanced versions of Timothy Lottes’ FXAA also do this (E.g. have ways to take sub-sample input) but I don’t know the IP status, e.g. if it’s only in the NV driver now (and how that’s ever supposed to work).