The (new) World for PSX
The Kathmandu situ file (
03 Approach 005-Kathmandu-RNAV procedure.situ) coming with PSX provides the showcase par excellence for what PSX_Tellurium can (and can not) do. During development and testing, I became quite familiar with, and fond of that beautiful part of the world, even though I can visit it only in a simulation.
Recent events there have however been a harsh reminder that beauty is only one facet of nature, and that there are others. So, allow me to begin this documentation with a request:
PSX_Tellurium, like PSX_Earth before it, is of course freeware and will always remain so. I won't even call it "donationware".
But when you venture into the tricky approaches between the majestic mountains of Nepal, please do take a moment to contemplate, and also to consider making a donation to the Red Cross or any other charity of your choice now operating in the area in order to help people there get back on their feet.
By all accounts the Nepalese have always been very welcoming and helpful to all sorts of "Westerners" (in the broadest sense) visiting their country, and they should be able to now rely on our support.
! Caveat 1
As most potential PSX_Tellurium (PSX_T) users will already have been PSX_Earth (PSX_E) users before, this document assumes that you are familiar with the PSX_Earth documentation.
It therefore describes only the features which have changed or are new.
If you do not know PSX_Earth yet, please read its documentation first, to learn about the basics.
! Caveat 2
PSX_T is currently a beta version (and I strongly suspect it always will be). So, expect weirdness and surprises. If you encounter any, read the Notes at the end; they contain more details and background regarding possible "issues" and how to deal with them (or not).
!! Caveat 3
Currently PSX_T will run only in the Google Chrome browser. It "should" work at least in Firefox, too, but doesn't (and I do have strong doubts that it ever will. See Note 1 for background.)
Sorry about that. But then, Chrome is available for free, too (and moreover, even as an old Mozilla/Netscape/Firefox fan I have to say FF isn't any more quite what it used to be...)
Tellurium? Whaddaya mean, PSX_"Tellurium"?
The new application is definitely not merely an update of PSX_Earth, so a new name was needed, which should of course still have some relation to the old one. And as it is based on the Open Source library called "Cesium", "Tellurium" was the obvious choice.
It could have been "PSX_Terra" (which was in fact the working title) or "PSX_Tellus", Tellus also being the Earth (Mother) or alternatively the happiest of men (not the PSX_E/T author thus). But why be modest when one can be grandiloquent.
Besides, the real Tellurium is characterized as "brittle, mildly toxic, rare" which nicely captures the robustness and architecture of the program, and the number of its users.
Finally, it could have been worse: I was contemplating "PSX_Terrarium", but what would that have made you the beta user, desperately trying to catch the bugs...?
In the beginning of this year I had to announce the imminent demise (on December 12, 2015) of PSX_Earth (PSX_E), because Google will then cease to support the Google Earth (GE) browser plug-in on which PSX_E is based.
My original intention was to use this auspicious opportunity to put the PMSG (Poor Man's Scenery Generator) add-on peacefully to rest: With the vast and ongoing improvements of VisualPSX (for using Microsoft FSX as the scenery generator) and XView (for using X-Plane), I thought there might really be no need or market any more for something far more primitive like PSX_E.
However, a few (but vociferous) voices were raised to the contrary. Apparently there are still Poor Men out there.
So I started to look into alternatives to GE and found Cesium.
Now, from the user's point of view this may appear to be very similar to the Google Earth browser plug-in, but as soon as you try to develop an application based on Cesium, you become forcefully aware that it really is not (Note 2).
While the usage is very similar to GE, Cesium offers much more powerful options to the developer — and is thus much more difficult to learn. Have a look at its API...
Thus the idea of spending a pleasant weekend doing a quick "1:1 port" from GE to Cesium died very quickly.
And several weeks later we have now PSX_Tellurium. I've done my best (always an ominous phrase) but (and therefore?) it is by no means polished; hence the "beta" moniker.
You will find that some features of the old PSX_E had to be given up; but as a comfort, some new goodies have been added. Various components still look the same, but work differently from PSX_E, so please continue to read this document.
As said, PSX_T will probably stay in "beta" status forever: It would take (me at least) many weeks, full-time, to properly come to grips with the intricate concepts, architecture and API of Cesium (see previous Note), time which I can't invest. So the hope is that the current "beta" will already suffice (Note 3).
There are two different ways of using PSX_E and now PSX_T, both of which have much in common, but also differ in some respects:
This was the original idea. It "only" requires a strict top-down view (from aircraft to "Earth") moving in sync with the aircraft position, and it can all be done in 2D. Add some zooming capability perhaps, and you are done. (Well...)
Cockpit View (more precisely: "Belly Camera" view, see PSX_E doc.s):
Representing the view from the cockpit means you are now entering the 3D world and have thus to handle all sorts of "oblique" views (looking at, above, or below the horizon; the latter case including, as the extreme, the aforementioned top-down view). So you now have to worry also about altitude, terrain, pitch, bank, and whatnot.
In a way, Cockpit View mode includes the Moving Map mode as a borderline case (tilt the camera to -90°, and you are looking top-down. Or perhaps not -- there are some complications (see below under "Pitch").
As PSX_E before it, PSX_T also tries to fulfil both roles. You'll probably like that, but you should also understand that this is the reason for certain quirks and compromises which had to be made, as detailed below.
The initial PSX_T version (just as the earlier PSX_E) used the data as supplied by the PSX Main server. This works, but results in a rather "stuttery" (read: low "frame rate") performance. (I haven't run scientific tests, and am not quite sure if it is the same, or worse, or even better than with PSX_E).
The reasons are multiple and complex, see Note 4 for details).
In my view, it may still be considered sufficient for a Moving Map, which does (at least in general) not have to be very smooth.
But it is definitely not good enough for Cockpit View. So the next step was to try using the Boost Server data. This was quite successful for many situations (in particular flight at higher altitudes); less so in others, e.g. at lower altitudes, in turns, or on the ground. But even then it's generally still better than the Main variant. (It is all difficult to assess: much will depend on the respective computer power and network quality; remember that the actual "map" data all have to be fetched from an external server via the Internet, with all its temporal and local variability of data speeds).
So why not just use the Boost variant all the time if it stutters less then the Main variant?
Because it puts a considerable load on the computer, that's why. The PSX_T development was done on a machine with an i7 CPU running at 3.5Ghz, 16 GB RAM and an NVidia GTX670 card, which copes quite well. By current standards this is still a good but certainly no longer "top end" machine, so most PSX users may in fact have something even more powerful. Then again, especially the potential PSX_T users may not have (Poor Men, remember?)...
Besides, apart from the performance spec.s, much will depend on other details of the environment (Internet speed etc.), and also on personal views (what degree of stuttering is still "acceptable"?).
If in doubt, shift the burden to the user: So PSX_T is now available in both variants; you pays no money, you makes your choice! :-)
Essentially the same as before, except that you no longer need the Google Earth browser plug-in, of course.
As noted above , PSX_T does currently not work in Firefox, even though Cesium as such does. Opera and Internet Explorer (v.11 or later) "should" also work. You'll need a newer version of whatever browser, because Cesium uses HTML5 features, in particular WebGL.
The make of the graphics card (NVidia, AMD, Intel, etc.) also plays a role; if you encounter "surprises", you have to consider that, too.
Unpack the ZIP archive to any folder
! You have now to make sure that on extracting the archive, the sub-folder
.../cesium_min is created;
so check that "use folder names" or similar options are activated in your unpacking tool.
! Keep the Main and the Boost variant of PSX_T completely apart, in separate folders. They are completely independent of each other. (Yes it's wasteful, they could use a common base, but it only leads to mix-ups and aggravation. Believe me, I tried :-))
PSX_Tellurium.inifile, and edit as required:
port on which the PSX server is listening for clients
! This will vary for the Main Server (default port 10747) and the Boost server (default 10749). Both PSX_T variants bring their own
PSX_Tellurium.ini file, preset with the respectively correct defaults, just do not mix them up.
Start PSX_T in the same way(s) as you did PSX_E.
*.html!); this requires that your OS knows about the file association between
*.jarfiles and Java.
java -jar PSX_Tellurium.jar
http://localhost:10314/PSX_Tellurium.htmlinto your browser (currently Chrome only).
PSX_Tellurium.htmldirectly by simply "dragging" the file into the browser, or by using the browser's
File > Open...menu items.
file:///..., you will have by-passed the HTTP protocol, the server, and the proper data processing, and it just won't work.
For more details see the PSX_E doc.s, link above.
Always start PSX before PSX_Tellurium, and make sure that you switch the correct PSX server on (Main or Boost) for the PSX_T variant you are going to start next. If PSX_T shuts down after a few seconds, this is the first thing to check! :-)
Note also that the Boost variant of PSX_T requires only the Boost Server (other add-ons may need both Main and Boost to run).
With regard to the PSX_T "BellyCam Control" gadget, keep in mind that while it looks very similar to the one in PSX_E, it does not always operate in the same way; so even if you know PSX_E well, do read the following description of the PSX_T feature changes and additions.
The bank angle of the aircraft was simply ignored in PSX_E. It has now been included, in order to make the Cockpit View mode more realistic.
However, it is still not entirely correct: As long as you look forward (camera bearing kept at 0°), it will be fine. But if you look sideways (i.e. swivel the camera), it will not be quite realistic (see Note 5 for details).
PSX_E also ignored aircraft pitch. This, too, has now been added to PSX_T, for better verisimilitude (and the chance to use long words).
It also opened a can full of quite a few quite interesting worms, not only for development, but also for you the user; so the following notes, while perhaps boring, are necessary nonetheless.
For starters, terminology: We have now to distinguish between aircraft pitch (angle between longitudinal aircraft axis and horizon), and camera tilt (angle between camera "view" direction and longitudinal aircraft axis). What we eventually see (the "visual pitch", so to speak) is of course the sum of both: If e.g. the aircraft pitch on take-off is, say, +15° up, and (in order to see your house) you tilt the camera down by -45°, your actual "viewing pitch" will only be -30°. Of course. You knew that.
But there is more to this than meets (or misses) the eye, and there are some side-effects. All easy enough to understand, but one must be aware of them.
For instance: As we know, a modern airliner, even when at level flight (CRZ) has a nose-up attitude, i.e. positive pitch (2-3° or so, I believe). So, a camera "in neutral", i.e. with a camera tilt of 0°, does not mean you are looking level at the horizon; you are actually looking (slightly) upwards into the sky (as the pilot will when looking strictly "forward"). In order to really look level at the horizon, you camera tilt would have to be -2° to -3°.
More importantly, this means that except in nose-down attitudes of the aircraft, you will not be able to achieve a full "top-down" view at the Earth (such as you would want to have for a proper Map View!): Even if you tilt the camera fully down (-90° tilt, which is the limit), your view direction would (in CRZ) be -87 to -88° at best. Or if you manage to get yourself into a extreme nose-up type situation (aircraft pitch e.g +50°), you would not be able to look down towards terra firma at more than -40° "view pitch".
For Cockpit View this may all be acceptable or indeed realistic, but it prevents a correct Map View (which requires truly vertical "top-down").
Therefore an extra rule has been added:
! If your camera pitch goes below -80°, the aircraft pitch will be completely ignored and the camera pitch will be set to precisely -90° "absolute" (with regard to the horizon).
In other words: Whatever the pitch attitude is into which you managed to get the aircraft, you will always be able to achieve a proper Map View by tilting the camera down for more than -80°. It will then jump to "absolute" -90°, never mind where the aircraft nose is pointing. HTH, as they say.
(Alternatively, I could of course simply have extended the tilt scale scale beyond -90°, but it would so mess up the design and looks of the gadget...)
All unnecessarily complicated, you say? Wait, there is more...
As it turns out (see forum discussion), all the above re: pitch applies strictly only to the Main variant, using PSX Main Server data.
The specialty with the Boost Server data is that (unlike the Main server) it does not deliver aircraft pitch as defined above, but the angle of attack (AOA). Now, Hardy has in the forum discussion suggested how to solve this difficulty, namely by injecting, via the Main server, terrain altitude at position, as obtained from the scenery generator add-on (you would therefore have to run both PSX servers, which is perfectly OK).
However, for various reasons this turned out to be not feasible in PSX_T (one snag being that for each position update, terrain elevation would have to be fetched from external data servers, as PSX_T itself does not have a terrain database).
Eventually the best solution was to simply use the data "as delivered": true pitch in the Main Variant, and AOA in the Boost variant.
According to my (limited) experiments, this discrepancy between AOA and pitch will not have too bad an effect in normal flight situations: deviations (between real pitch and "visuals") of perhaps 5° up or down will be hardly noticeable in the Cockpit View.
Only in extreme cases there will be a major difference: e.g. if you force the nose up to +40° pitch (as per PFD), the AOA and thus what you see outside in Cockpit View, may only be 8° up. (Also, Happy Stalling! :-))
Your mileage may vary, of course; it also depends other factors.
In any case, keep in mind that this only affects the "automatic" viewing pitch, with camera tilt "in neutral" (at 0°)! Of course you can at any time compensate for any shortcomings of AOA vs. true pitch by manually operating the camera tilt via the slider, so that you really look straight at the Earth when falling out of the sky (just an intentional emergency descent, of course).
Another new feature, although less conspicuous: Zoom is now genuine zoom, which it was not in PSX_E (see Note 6). The zooming camera is now really moving along its line of sight, as it should, either forward (zooming "in") or backward (zooming "out").
Selecting a useful zooming range was a bit of a headache, as Map View mode and Cockpit View mode have somewhat different requirements: For Cockpit View, a relatively moderate range would be OK, say 0.2x to 5x (<1x means zooming out), whereas Map View demands a larger range, especially when zooming out in order to get an overview perhaps covering hundreds of miles.
Separate zoom ranges for each mode would be cumbersome, so a compromise was made, and you need to be aware of the following features:
! On purpose, zooming is available (indicated by the zoom slider being visible) only when the camera is pointing below the horizon. While it is pointing above the horizon, the zoom slider will be invisible.
In part this is for reasons of the calculation methods (we don't like square roots of negative numbers :-)); and besides, zooming upwards into the sky does not make much sense anyway.
! Note that the slider scale is logarithmic: around the "neutral point" (1x, i.e. no zoom either way) zoom will change slowly; at the ends of the scale it will change rapidly.
The general zoom range goes from about 0.1x to about 5x, which should be enough for most purposes.
Moreover, at the lower end (far zooming out), the zoom factor will jump to about 0.01x, which is mainly intended for long-range Map (Over)View.
Be advised that zooming may require the map data server to deliver (possibly lots of) new map "tiles" of a different resolution, which takes time, especially when using 3D terrain; it depends on Internet connection speed, etc. Experiment a bit so that you get a feeling for the amount of rapidly "zooming around" which your setup can handle, and for how much zooming is acceptable esp. in critical (flight) situations where every second matters.
(Nota bene: Of course PSX_T does not slow down or in any way interfere with the PSX simulation, you can still rely on your instruments. It's only that the external view (in PSX_T) may get "out of sync" if the tile delivery cannot keep up with things.)
! It is your responsibility to make sure that you do not zoom into terrain (a.k.a. CZIT)! If you are zoomin gin towards the Earth and suddenly realize "My God — it's full of stars!" (real ones, too, not the type Donald Duck or Wile E. Coyote so often see), then you are not in the wrong movie but have zoomed in too far...
The zoom slider does not "snap" to preset values. This gives you full control, but makes it a little tricky to get back to precisely the "1x" (no zoom at all) setting.
The trick: Tilt the camera upwards until zooming is disabled (the slider vanishes); this will reset the zoom to exactly 1x.
This is the slider in the PSX_T browser interface (i.e. not the "BellyCam" gadget). It is in its old place, as in PSX_E, but has now a completely different function: It allows you to change the altitude of the camera from -3000 ft to +3000 relative to its real altitude.
! Again, this slider has a logarithmic scale: small changes around the "neutral" centre position (therefore easily resettable to 0), large ones near the ends.
There are two reasons for this slider:
One is simply convenvience: In certain situations it will make things "look better", the most useful case perhaps being that with the aircraft sitting on the ground you can now select at your own preference what altitude (of the cockpit above ground) gives you the best "visuals". Of course these changes affect only camera altitude, not the altitude of the actual aircraft in the PSX simulation.
More seriously, there is a somewhat grave conceptual issue (not bug) with terrain altitude as represented in Cesium. E.g. you may end up below ground even though the aircraft is perfectly positioned. Or you may "hover" when the plane should be sitting on the ground. See the chapter on "Terrain and Altitudes" for an explanation.
In these situations the "ALT correction" slider can bail you out, as it were.
In PSX_E a little blue plane a.k.a. the PSX Marker indicates your current position on the map, and as we are by now all sentimentally attached to that little blue plane, it had to be in PSX_T, too, of course.
However, this required some new thought: In PSX_E you can only zoom in, so in any view other than vertically top down (or very close to that) you cannot see the marker.
Now, in PSX_T you can zoom out, too, which means even in certain oblique cockpit views you could see the little blue plane, and that creates all sorts of complications. These have been resolved by a very simple feature:
! The PSX Marker will only be visible in Map View (strict top-down view).
It will vanish when switching to any kind of cockpit view (more precisely: with any camera tilt higher than -90° absolute).
This didn't only make life considerably easier for the developer, but also makes sense for the user: representation of the plane marker in a 3D view does not really help you determine your position. In fact, it is easily misleading: the plane symbol does not change size with distance, so in a 3D view it is impossible to deduce where exactly on the map its position ( = nadir, the point "right below it" on the ground) would be; you could see that only if the marker were sitting on top of a kind of needle stuck into the ground below it.
(If interested, see Note 7 about some more fun which was had with implementing this simple marker.)
In version 1 it was already possible to orient the map "North up" by rotating the camera bearing until its pointer co-incided with the blue "true North" needle. However, this required constant re-adjustment whenever the aircraft changed its heading.
To satisfy popular demand (hi Keith! :-)), a better "North Up" Map Mode (NUMM) has been added in version 2.
This mode can be activated by clicking on the "Bearing" label in the "BellyCam Control" gadget, which has the following effects:
Left: Default Map Mode (almost but not quite manually adjusted to "North Up", by changing camera bearing to point to true North)
Right: "North Up" Map Mode, activated by clicking on the "Bearing" Label. Tilt and bearing sliders disabled.
The label changes to "
North-Up Map", to indicate the active map mode.
Camera bearing changes to 0° (i.e. true North).
The camera bearing slider, while still visible, is now disabled.
(If you look closely, you'll see that its appearance also changes accordingly, albeit very subtly).
Manually changing the bearing would turn the map out of "North Up" orientation again, which we don't want in to happen in NUMM; hence the de-activation.
Camera tilt changes to -90° absolute (i.e. true top-down view).
The camera tilt slider is now also disabled.
See Note 9 for the reasons.
The zoom slider still functions normally (see Note 10).
To revert to "default" map mode, click the "
North-Up Map" label; it will change back to "
Bearing", and the tilt and bearing sliders will behave as in v.1 again.
Google Earth offers various layers which can be switched on and off: On top of the satellite/aerial image one can have displayed place names, roads, borders, and so on. You can activate/de-activate some of these layers in PSX_E via some checkboxes in the browser interface.
In Cesium layers are not available in this way, and therefore the checkboxes are gone in PSX_T. However, all is not lost: Cesium does offer various maps from different sources, all of which you can select for the PSX_T display. From Bing (Microsoft) there are satellite/aerial images without additional markings, the same with labels, also a road map; then there are various maps from Esri, OpenStreetMap, and several others; so all your requirements can probably be met.
You select a map by clicking on a somewhat inconspicuous button in the upper right corner (I have already added a golden border to it to break the camouflage a little):
The upper twelve fields correspond to aforesaid maps. The lower two have to do with 2D vs. 3D terrain representation, see next chapter.
Alas, the "Airports" layer from PSX_E is missing in PSX_T. It is based on a special custom KML file which can be read and overlaid by the GE plug-in.
In PSX_T this turned out to be too costly: PSX_T can in fact read and display content from KML files, but the one used with PSX_E contains over 6700 airport entries, and processing these slows PSX_T down to a halt. It could perhaps be optimized but was deemed not important enough a feature to slow down the release...
As a workaround, you can always load a "street map" type background in PSX_T and go looking for the airports (even though they won't have the ICAO code). :-)
fun immersion realism, we will of course want to see 3D terrain properly displayed, and that is indeed available in Cesium and thus PSX_T, too. However, it is not active by default; you need to click on "STK World Terrain meshes" at the bottom of the map selection mentioned above.
The "WGS84 Ellipsoid" button means in fact flat 2D maps (flat with regard to terrain; they are still 3D representations of the Earth ellipsoid, but without displaying terrain altitudes). The "STK World Terrain" button will however give you 3D mountains (and plains :-)).
Which brings us to a major issue concerning terrain and all that is related to it. PSX, like most everyone else, uses "MSL" (above Mean Sea Level) as the reference for (geographical) altitude. However, Cesium does not. It uses (as does aviation GPS, it seems) the "WGS84 Ellipsoid" as the reference. And in the words of Esri, "height above the ellipsoid will not be the same as MSL and direct elevation readings for most locations will be embarrassingly off." Indeed.
This is unfortunate (for our purpose) in two respects: Firstly, "WGS84 Ellipsoid" altitudes can not be translated straightforward to MSL altitudes. Secondly, the discrepancy between the former and the latter for the same terrain location can be considerable: "Mixing up the ellipsoid and MSL will make your heights incorrect on the order of tens of meters", "up to 100 metres (328 feet)"; and what is worse, this dicrepancy will vary locally in unpredictable (by mere mathematics) ways. See Note 8 for details.
So depending on where you are, PSX and PSX_E may have quite different ideas about your altitude. It will not matter too much at higher altitudes (unless you can visually spot the difference of being at FL340 vs FL320), but of course it does matter a lot for the question when exactly you are touching the ground on landing.
But until Cesium, too, offers MSL based altitudes (and that seems indeed to be on their TODO list), there isn't much that can be done about it. The best work-around I could think of is the "ALT correction" slider described above.
As already mentioned, the PSX_E checkboxes for the display of layers are no longer needed in PSX_T, which resulted in an empty space. As nature abhors a vacuum, I tried to find something to put in there, discarded the idea of a music player (in the cockpit??), and eventually came up with nothing better than yet another METAR fetcher: Fill in the ICAO code of any airport, hit
Enter, and you will receive (from NOAA) the current METAR (Real World™, real time, not necessarily the PSX weather!). Not very original but better than an empty space.
Finally, some general hints for PSX_T usage...
Don't take them too strictly: Much will depend on the specific circumstances of your system (Internet connection speed, CPU and graphics card power, etc.) and also external factors (esp. the current load on the map servers). So, experiment a bit to find out what can and cannot be achieved in your specific setup.
Do not load the file
PSX_Tellurium.html directly into the browser (by dragging or via the menu
File > Open) — if you see
file:///X:/<Myour path>/PSX_Tellurium.html in the browser's address bar, it won't work.
The Cesium code in the page has to come from a server (in this case built into PSX_T). The address bar should indicate that the HTTP protocol is used:
Always start PSX first, and PSX_T next. Only then open the browser interface, via a bookmark or using the URL
http://127.0.0.1:10314/PSX_Tellurium.html, and connect to PSX_T.
If the browser tells you "This web page is not available" or similar, it means that you have not yet started PSX_T (and thus there is no server running yet to supply the PSX_T web page interface).
You can in principle switch to other situ files in PSX "on the fly", i.e. without disconnecting PSX_T first. However, give it some time to load the new scenery; depending on conditions it may take a few seconds. In complicated cases it may still be better to disconnect PSX_T before the situ change and then reconnect.
When starting up PSX_T or when switching situs, put PSX in MOTION freeze first. Again, depending on circumstances this may not be absolutely necessary, but it's generally a good idea (esp. when using 3D terrain!) to give PSX_T (or rather the map serving process) some time to "catch up" and stabilize, without having to cope with a constant stream of new data from PSX. Just try it out and see what your specific setup can stand.
As explained above, do not change camera tilt, bearing, and zoom too "wildly": map tile changes take a little time. Generally "looking around" (camera bearing changes) are uncritical, tilting may or may not be, and zooming probably poses the toughest challenge for the system (due to changes of map tile resolution).
Always disconnect the web page first before exiting PSX_T by closing the "BellyCam Control" gadget.
If you fail to do so, the Cesium widget (scenery) in the browser will crash. Normally not a big deal (just load any other page), but sometimes it hangs up Chrome, so that its processes have to be shot down manually (Task Manager or similar).
Occasionally, weirdness may occur: E.g. you may find yourself underground, staring skywards through a framework of landscape-textured beams. This may look dramatic but is mostly harmless; it generally means simply that you have placed yourself below ground level, usually due the discrepancy between the PSX MSL and the Cesium "WGS84 Ellipsoid" altitudes. It may also be caused by inappropriate zooming or tilting values.
If the scenery looks completely messed up try to set the camera tilt to slightly above zero (horizontal), this will also reset the zoom to "neutral" (1x).
If that does not help, try to correct the altitude with the "ALT correction" slider on the web page.
(Remember: This will affect only the camera view, not the actual aircraft altitude in the PSX simulation.)
In certain (rare) circumstances, the scenery may appear to move in an odd "wobbly" way; for instance, it may do small jumps forward and backward (remember the old "PS1 plus FS2004" days? :-)). The reasons when and why this happens could not be nailed down more precisely. Generally, the situation seems to stabilize itself after a few seconds anyway; if not, try playing around a bit with the sliders.
During development (this may or may not apply to normal use), I got the impression that the browser (Chrome) occasionally became "fed up" as indicated by some slowness and/or unresponsiveness (no hard data; it may all be in the mind). In these very rare cases, it helped (perhaps also only in the mind) to disconnect PSX_T, close the web page, close and restart the browser, and then reconnect to PSX_T. It takes only seconds, and there is no need to restart PSX itself or reload the situ, so it may be worth a try if you feel things are not going as smoothly as they should.
At the moment, all these minor disturbances are so rare and so un-replicable that there is not much chance of further analysis and potential fixes.
Your best strategy is probably to load e.g. the Kathmandu situ (
03 Approach 005 - Kathmandu - RNAV procedure.situ), with or without 3D terrain added, then to connect PSX_T and to see how it goes.
Put the aircraft out of VNAV PTH into ALT mode at 7000 ft or so (so that it will follow the go-around route instead of landing), and enjoy the show, while trying out the various PSX_T options and sliders, to see what can and cannot be done with your specific setup.
Admittedly, lots of quirks remain in PSX_T; and on other systems, more will be discovered. But to iron all those out would demand a lot of time and work (or might be impossible altogether). Hence the "permanent beta" status, to sort out what the users (if any) can live with, and what would really need fixing... :-)
For some reason unknown so far, PSX_T will not run in Firefox, even though it "should". The problem is not with Cesium and neither with Firefox as such: other Cesium applications do run just fine.
The Cesium authors promptly responded on the developers' forum and did try to help, but as this is an application-specific issue (and not, as I had hoped, some trivial oversight on my part), they would need sample code to replicate the problem. However, in order to be relevant, any sample code would also require a PSX installation, so it is not practicable.
At the moment I have not much hope of being able to fix this; and it is also a question of how much demand there actually is for that. For the time being your best (and by far easiest) bet is therefore to simply install/use Chrome. (In my opinion, even as an old fan since Netscape times, Firefox has become a bit of a liability anyway. Not sure if Chrome is the alternative, but...)
Cesium is Open Source, which is generally a Very Good Thing, but also implies some aspects less auspicious for "end user usage". Above all, it is itself still under development — essentially also a Good Thing, but it means that some features are still missing (e.g. availability of MSL-based altitudes) or may change in the future. Moreover, documentation, especially for beginners, is often a bit scanty. Cesium is actually quite good in this respect, offering a range of demos and a well-accessible API document. Even so, the learning curve (in my opinion) is very steep: Cesium is very powerful and versatile, but that also means one has to understand quite a lot of things all at once, before one can get going.
For the "beta" reasons above, and for those mentioned in Note 2: If you happen to be familiar with Cesium, don't be appalled by the amateurish use which is made of it in PSX_T; this is after all a first Cesium project.
As such, it is probably too ambitious and far from being efficient, let alone optimized. I'm sure any experienced Cesium developer will confirm that, should s/he ever get to see it (I'd like to hear about it).
Why did the PSX Main Server suffice (well...) for the Google Earth based PSX_E, and why do we need a Boost-based variant at least for Cockpit view in PSX_T?
The PSX_E position updates use a GE function called
flyTo(). It's specialty is that it does not just move the camera from A to B, but also interpolates positions between updates. Very nice, if only there weren't a snag (as usual):
Unfortunately, this interpolation does not move the camera from A to B at the same altitude, but makes it describe a kind of parabolic curve. If A and B are far enough apart, you will enroute (due to interpolation) be lifted to the edge of space (it may be hundreds of kilometres up) before being sent down again to Earth at point B. This happens even when A and B have the same altitude above MSL. And it cannot be switched off. It's not clear to me why this is done; I suspect merely to make things "look nice". :-(
For very short A to B steps (such as in PSX_E, where positions updates are made at a rate of 1 to 5 Hz, these "kangaroo jumps" (my term) cannot lift the camera up very high; in fact they are almost imperceptible. Almost, but not quite: they give the motion in PSX_E this rather strange "pulsating" quality, which is quite different from the usual "stuttering" due to low frame rates. What you see are tiny kangaroo jumps caused by the interpolation between micro-steps.
Cesium does in fact also have a
flyTo() function, also with interpolation, and alas! also with parabolic kangaroo jumping. Unfortunately this seems to be (impression, no hard data) even more pronounced than the one in Google Earth, and it was found to be unusable even for the micro-steps of PSX_T.
Open Source to the rescue? Unlike with GE, the Cesium source code is freely available, and nothing prevents one (indeed one is encouraged) to enrich it, e.g. by adding an interpolation method without kangaroo jumping: "go from A to B while staying at the same altitude". Sounds straightforward enough — until you have a look at the source code in detail (to get a taste, have look at the mere API). I am sure it is perfectly do-able, but not by me, unfortunately.
The only alternative was therefore to use another function which simply places the camera at a given (and constantly updated) position, without interpolation between updates.
This is straightforward and works just fine. But at a "frame rate" of only five updates per second (5 Hz is the rate at which the PSX Main server supplies data) it also results in clearly visible "stuttering"; perhaps just about acceptable for a Map View, but not for any Cockpit View.
(I also did a lot of experiments trying to supply a custom interpolation, but that didn't succeed. The dilemma is that if your calculations become too complex and are not professionally optimized, you will lose in CPU time what you try to gain by the interpolation.)
Hence the idea of making a PSX_T Boost variant using the Boost Server (which delivers updates at 72 Hz), while also keeping the PSX_T Main variant (for users whose setup cannot afford the performance load, or who need only Map View anyway).
Even if using the Boost Server, don't expect to be completely free of the famous "stuttering". On a "decent" (by current standards) machine it all moves very fluid and smooth indeed at higher altitudes, and in level and straight flight. As soon as you come closer to the ground or do turns, that may change, to a larger or smaller degree.
I think, however, that the bottleneck is then not PSX_T itself, but the map servers: after all, map "tiles" have to be downloaded all the time from the Internet. This also means that it depends very much on "local" circumstances if and when you see stuttering, and how pronounced it is.
While PSX_T now does represent the bank angle, it is still cheating a little. Here's how (and why).
Imagine you are in level flight, banking 25° to the right. If you look forward, out the windshield, you will see just that: no pitch (apart from the usual 2-3° nose-up), and 25° of banking. And you will see just that in PSX_T, too. All good so far.
Now you turn your head by 90° to the right, to look out the right side window, and behold: what was your bank angle of 25° has now become a "pitch-down" angle of -25°. (Purely visually, of course, nothing to do with the actual plane pitch which is still level).
Similarly, looking out the left cockpit side window results in a perceived "pitch-up" of +25°.
And in the same manner, real pitch (in forward look) will change to perceived "bank" in sideways look.
This "sideways looking" effect is not implemented in PSX_T: you will always see the same "banking" angle, wherever your camera bearing is pointing too. Perhaps, given enough time (so that it can be used in PSXVII), I could even figure out the math of the transition between bank and pitch, but it would in any case require quite a few calculations (until someone tells me about optimized matrix operations), and given that it has to happen 72 times per second, I strongly suspect it would delay and thus mess up the currently smooth operation... Not worth it, for such a minor feature. Methinks.
In PSX_E, zooming was (seriously) "faked": The "zoom" slider really changed only the camera altitude, while not changing its position above ground.
For a real zoom, the camera must of course move forward (or backward, when zooming "out") along its line of sight, i.e. its lateral position must also change (independently from the aircraft position). Or you must figure out how to change focal length... This can of course all be calculated, but the trigonometry involved, the lack of professional optimization, and especially the need to keep two separate coordinate sets for aircraft and camera made a "do it yourself" approach impracticable for GE/PSX_E.
More luck with Cesium and thus PSX_T, because the library has a zoom function built in which is of course optimized. So now you can truly zoom, both in and out...
[This is reported here ony as a "war story" about the adventures one goes through with this kind of project. No practical significance for the user.]
Originally, the PSX marker (the little blue plane), just like the camera, was "driven" by the constantly updated geographical coordinates. Which led to all kinds of hassles. E.g. unlike GE, Cesium does not have a "clamped-to-ground" function, so the marker, when placed on the ground (where it should be) would vanish underground as soon as 3D terrain was used. There also was the question in which cockpit views the marker could or could not be seen, and so on.
Only after several days of Fruitless Fiddling it occurred to me that the marker (when used in top-down view only) could just as well simply be fixed in the middle of the screen, as opposed to painfully follow the changing geographical coordinates. In other words, a simple static "overlay" would do the same job, and that is now what you have. Much more robust against all sorts of special cases (2D vs 3D terrain, flat terrain vs. mountains, viewing and zoom angles, and so on).
The one weak spot may be that the calculation of "screen centre" (to be precise: centre of the Cesium scenery widget) could be flawed: I had only one resolution (1280x1024) for testing. Let me know...
As explained above, the marker is visible only in top-down view. And while its position is fixed (relative to the screen), it will still correctly rotate if you change the camera bearing. In PSX_T, rotating the camera actually rotates the scenery, of course, and the marker follows that, so that the plane symbol always points into the correct direction of its travel.
There may be some question why one would rotate the camera (bearing) anyway in top-down view, but it can be handy: You can e.g. choose between "North up" and "HDG up" orientation of the map, by selecting appropriate camera bearings. (Keep in mind that the light-bue "needle" in the "BellyCam Control" gadget always points to true North!).
The "WGS84 Ellipsoid" is an idealized geometrical description of the shape of the Earth (no, it's not a Disc, it's a 3D body). Altitudes in this system are given as "distance above the ellipsoid surface".
MSL altitudes on the other hand (foot?) are based, as the name betrays, on the level of the seas' surface(s), and that is not a geometrical ideal but varies from place to place in an irregular pattern, due to all sorts of factors.
To learn more, go e.g. to the Esri page explaining it all; they also have nice maps about the Earth being a potato, and the sea being perhaps mean, but anything but level.
While PSX_T is in NUMM, the camera tilt slider is disabled, for two reasons:
The first is technical: It was found that the map, even with the camera bearing fixed to true North, will still rotate (temporarily) when the aircraft turns; it will then slowly revert to true North, but the overall effect is confusing (and of course nullifies the idea of "fixed at true North, whatever").
After much tearing of hairs, the reason for this behaviour was discovered: Due to the inner workings of Cesium, it seems to be necessary to disable banking, too, in order to keep the map fixed in "North up" orientation.
And this in turn means that while in NUMM, the Cockpit View would therefore not show any bank angle, and would thus be of inferior quality (now that we finally and proudly have banking!).
The second reason is usability: In 3D Cockpit View, NUMM means that you are looking fixatedly towards the North, whatever the aircraft heading. This results in a logical but still weird appearance: You seem to move sideways or even backwards (namely when the plane heads to the South while you keep staring towards the North). So Cockpit View has been altogether disabled in NUMM.
[The only use case I can think of for a 3D Cockpit View fixed to true North would be around Christmas, when you are impatiently watching out for the arrival of Joulupukki who as we know comes from his home base in Korvatunturi, i.e about as far North as it gets.]
The zoom slider works normally also in NUMM. It has been suggested that it should be automatically set to the special "max zoom out" position, for best long-range overview. But I think it is better to let the users keep the freedom to use whatever degree of zooming they like. Besides, it depends on the aircraft altitude how much of the map your maximum overview will cover. At higher altitudes (CRZ) it may well be useful to not zoom out quite so far.
Thanks and credits go to
Cesium is under the Apache 2.0 License, see file
README.md in the
(This folder contains a subset of the full Cesium installation: demos etc. have been omitted.)
Licenses for the various third party components of Cesium are listed in the file
LICENSE.md, also in
As to PSX_Tellurium itself, I dunno. Do no evil.
PSX_Tellurium is free, but I reserve the Copyright (© Martin Erdelen 2015).
Don't make money from it, don't use it commercially (not always the same thing), and don't distribute modifications without contacting me first. (This latter restriction is for technical rather than for legal reasons... ;-))
End of document
Laboured Day 05.05.2015: version 2
© Martin Erdelen 2015