Japanese version

In Microsoft Flight Simulator, there is a limit to the number of objects that can be displayed in a certain area. If this limit is exceeded, a part or a whole of the scenery suddenly disappears. I have been told that good scenery (which works well independently) sometimes does not appear because it is being used with other sceneries. It seems that this phenomenon is caused by reaching the limit of objects that FS can handle. Good scenery with lots of detail tends to have many objects in a very small area.

First, objects disappear. Sometimes the objects disappear completely, or sometimes they appear under some conditions and then disappear. This phenomenon is known as a hysteresis effect. This occurs mainly because they are affected by the presence of the other objects. By the way, in SceneryMaker, visibility can be set using an Area() command (like the other compiler, e.g. SCASM.). In FS, when flying in a rural area, we cannot see the object from a greater distance than this visibility value, and we can see it if we're closer than that value. But in the center of downtown with many objects, this is not true. Even if we are at a place nearer than the visibility value, sometimes it doesn't appear.

Hysteresis Effect
	The place to which we are going is visible.
	The place where we are and the place to which we are going are both visible.
	Only the area behind us is visible.

Please look at the pictures above. The top picture describes what happens over the Tokyo Haneda International Airport, and it shows the case heading for the center of Tokyo. In this case, objects near Haneda can be seen correctly.
The middle picture describes what happens near Shimbashi or Hamazakibashi-JCT, and buildings at Ginza or Otemachi are starting to appear.
The lower picture describes what happens over the Yurakucho station through over the Ginza buildings. In this case, if both Tokyo MEX way (Tko_hw1.bgl) and Yamanote-line (Tko_tr1.bgl) sceneries are installed, sometimes the Tokyo station doesn't appear. But it only happens if you're in a straight course from Haneda. If you fly through Tokyo bay or go to west toward Tokyo station after passing over the Sumida River, Tokyo station appears correctly.
The display of each object is affected not only by the visibility value, but also hysteresis effect, which is determined by the mutual geographic relationships of the objects.

There is no easy way to solve this problem, because it is a characteristic of FS. I think it's only way to wait that a future version of FS will solve it.
But there are some methods that can be used to decrease the phenomenon.

-1- Setting visibility
First, it's a basic but good idea to set the visibility low. This decreases the "self-assertion" of each object, and reduces the possibility that nearer objects will be affected by more distant objects. But if the visibility is too low, your object will not appear at all because it will be "killed" by the other objects. After frequent experiments, I set the visibility of Tokyo MEX way to 36 km. Of course, because of the hysteresis effect, this scenery does not automatically appear at exactly 36 km. If the visibility is set to around 10 km, the hysteresis effect causes the disappearance of Wangan line at Oi-wharf in a course from the center of Tokyo to Haneda Airport. If the visibility is set to less than this value, the scenery is killed by the default FS scenery, and doesn't appear at all. A concrete value of the visibility is determined only by experiment, but this situation is similar to a real life on a commuter train in Tokyo. "Too much self-assertion and too much modesty, both are no good." This is true in the case of a commuter being crushed to death (even worse than transported livestock !!). It's a great pity to experience this even in making sceneries ! Essential true solution (making new train lines, transfer of the capital, realization of "true" democracy....etc.) is strongly hoped for Microsoft (,train company and Japanese government).

-2- Decreasing the number of objects
This method is adopted many times in the Yamanote-line scenery. For example, if two tracks are to be laid, only one object which depicts two tracks is laid, instead of two objects each depicting one track. In this way, on the track between Yurakucho and Tokyo stations, the total number of the objects is only 1/8 of what it would otherwise be, as a result of using only one object for 8 tracks. (There are 4 lines: Yamanote, Keihin-Tohoku, Tokaido, and Tokaido-Shinkansen lines. Each line has a double track.) In concrete, texture is used a lot. Please look at the track located just south of Tokyo station. There are many tracks, rails, curves, and points, but this is all created by just ONE object. The image of the rails is all created by texture. Of course, the resolution of the picture affects the amount of the texture.

-3- The other methods
Theoretically, it is possible to draw a complex object when the plane is near, and a simple object when it is far away, through the use of conditional statements in your scenery code. I observed that the limit was reached even if the scenery code was executed only one routine at the same time using conditional statements. I did experiments many times in the center of Tokyo using the full limit of objects. This is suitable for Moving Yamanote-line scenery too. As you can see, only ONE train is moving. But the number of the objects is very high. This is because the program must generate many separate objects, just like making a lot of cell pictures of any animation. If the number of objects is not increased by conditional statements, Tko_tr1.bgl and Tko_tm1.bgl have to show the same behavior with regard to an object's disappearance. In really, it is completely different. The animated "Moving Yamanote" scenery has too many objects to use together with other scenery.
The method using SetVar and conditional statements outside of PerspectiveCall is good, it really works well. (This method is written in a document of Mr. Kukushkin below.) But there is no effect in the center of Tokyo with strong hysteresis effect. I think that this method is effective in the situation that there is only one complex object in a vast wilderness.
There is an another method of controlling three visibility parameters using CondRefpoint. Meanings of v1, v2, and v3 are explained in a document. But this method also could not make no effect to decrease hysteresis effect in the center of Tokyo.

Above mentioned stories are all related to 3D object (strictly defined that a polygon in the PerspectiveCall command). Because I learn that this limit of the number of the object does not affect dots and lines from documents, I make fireworks sceneries consists of only dots and lines. But I find that there is the other limit for dots and lines different from the limit of 3D object. When I put fireworks on the center of Tokyo or Manhattan island where is almost reached to the limit of the number of object, all object including fireworks are displayed correctly within some quantity. But if I put more fireworks or more long time (increasing time in an animation is almost equal to increasing the number of object. It's the same situation to Animated Yamanote-line scenery.), objects disappear. With many experiments, I think that it is good to understand that the limit of the number of dots and lines is independent of the limit of the number of 3D object.
Because, in spite of the fact that the number of 3D objects in Tokyo is more many than in NewYorkCity (in the case of full installation Tokyo MEX way and Yamanote-line), the limit of dots and lines in NewYorkCity is more strict than in Tokyo. You can see beautiful night view of NewYorkCity and find that there are many dot lights on the many bridges around Manhattan island and vicinity. You can also find dot lights in Tokyo MEX way and Rainbow bridge in Tokyo, but a density of light in Tokyo is less than in NewYorkCity. On the contrary, fireworks affects an appearance of Tokyo MEX way sometimes. It maybe seems that 3D object limit is not independent of dots and lines limit, but I find that Yamanote-line does not disappear, in spite of a disappearance of Tokyo MEX way. In the night view, Tokyo MEX has lights but Yamanote-line has no light. Tokyo MEX is killed by fireworks with 3D road for the limit of the number of dots and lines, I think. (There is a difference that dot command in Tokyo MEX is in the loop of PerspectiveCall .)
So, it seems that if dots of fireworks and dots of Tokyo MEX fight, fireworks seems to win, and I think that there is a handicap with Tokyo MEX for receiving limitation as a 3D object because Tokyo MEX locates within PerspectiveCall loop. (Of course, visibility setting also affects there.)

TwilightExpress (LAGO) Tokyo scenery uses photo-realistic textures as ground textures. As described in the manual of this scenery, a conventional method of making add-on sceneries doesn't work. In this manual, there is a description about synthetic scenery, but there is only abstract information that a person should handle Scenery MAKER well.
Concrete countermeasures are thought in two ways. First method is using Priority command. But it doesn't work in my condition. The method using _CondRefpoint also doesn't work in my condition yet.
Second method is using sclink. This works well. But very easy installation in conventional sceneries (only putting in and out) is not affordable. You can download sclink from World Wide Guide site below. I respect such a nice program and a good site.
And I observe that build-up of the memory is effective for increasing the number of objects, only in the case of this LAGO Tokyo scenery. (Capacity of an internal buffer is the key in the case of MS version, as I write later.) My system has 96 MB of RAM, and I observe that some objects are not displayed at my acquaintance he has 32 MB RAM system. The reason of this phenomenon is unknown.

At last, FS98 comes in. I experiment with a limit to the number of objects which is the biggest pending problem at once.
After all, unfortunately, this limit is the same as previous versions, it seems that there is no improvement at all. When I put a lot of Tokyo MEX and Yamanote-line scenery files, objects disappear as before. Further more, about the limit to the number of dots and lines, a situation changes for the worse. In a case when I access the same directory of the same contents of Tokyo of FS6 from FS98, a part of fireworks does not appear by influence of Tokyo MEX way, in spite of appearance correctly in FS6.
But, I hear really BIG news !! Microsoft produces a FS98 converter, and this makes the limit of the number of objects in a scenery larger ! This is an essential solution made by Microsoft, and it's great. Next, I show some experiment about Tokyo vicinity sceneries which I made.

Installation	FS6	FS98+fsconv98
Whole detail versions of Tokyo MEX and Yamanote-line (MS version)	Almost nothing to be seen.	Good ! all objects are displayed. Light versions are not needed almost.
3 fireworks in Tokyo installed in the same time	Sumida-river is OK. Tokyo bay is partly displayed. Jingu is not displayed.	Good ! completely displayed.
Whole detail versions of Tokyo MEX and Yamanote-line (MS version) + All 3 fireworks in Tokyo	Too bad.	There is a difficulty, but almost displayed with strong Hysteresis effect.
Tokyo MEX and Yamanote-line (TW version)(ver0.6)	With strong Hysteresis. Difficulty with FS6, FS98+ is recommended.

In spite of greatly eased limitation, it is not almighty. And in TW version, there is not a difference like in MS version because of a contribution of sclink maybe. But FS98+ is recommended after the construction of Edobashi and Hakozaki JCT is completed. Further, after the Belt highway of center of Tokyo is completed, it is impossible to use except FS98+ at last.

Further, FS98 is:
"It takes much time to start program, to go to the situation, and to re-built scenery database."
"Frame rate is very low. (hard job for Pentium 166MHz.)"
"Expression of 3D in the scenery has not been improved in my case. (I use Canopus POWER WINDOW 3DV SX card.)"
"Situation file is compatible with FS6, but if the situation contains a setting of no panel, pressing "W" key is required after starting the situation."
Therefore, if we use Microsoft Flight Simulator as a vehicle for travelling time and space in Slew mode, I recommend strongly a use of FS98converter. FS98 without FS98converter is no use.
About FS98(J), it seems that an original version is already eased the limitation. Therefore it is no need to apply FS98converter.

I have not written so detail, there is another display limit which is "a limit to the number of poligons within PerspectiveCall command" adding to "a limit to the number of the 3D objects" with Hysteresis effect, "a limit to the number of dots and lines". I came across it when I made complex JCTs of Tokyo MEX and animated Yamanote-line. This limit is appeared as a phenomenon that whole objects suddenly disappear in spite of a condition not reached to the "a limit to the number of the 3D objects", if too many poligons are put within PerspectiveCall command routine. About this phenomenon, a solution is very simple. If objects too many are re-located to the outside of PerspectiveCall command, other objects appear again. But it means that context of each objects is failed. Concrete number of this limit is 28 of road units of Tokyo MEX, which is converted to around 100 - 128 poligons. And Hysteresis effect aforementioned relates only "a limit to the number of the 3D objects", objects suddenly disappear about "a limit to the number of dots and lines" and "a limit to the number of poligons within PerspectiveCall command"

Now, I make ski jumping stadium of NAGANO Olympic. I already know these 3 limits. About "a limit to the number of the 3D objects", I expect that there is no limit and no Hysteresis because Hakuba is the place where there is nothing in the mountains area. About "a limit to the number of dots and lines", it is no relation because I rarely use dots and lines in this time. About "a limit to the number of poligons within PerspectiveCall command", if I observed, then I put some objects out to the PerspectiveCall command loop in spite of no good displaying. Therefore, I think rather optimistically that I can make 4 jumpers of Japanese team all jumpers who are Gold medalists easily. BUT....... LIMITATION comes, after making Mr. Harada only. Further, I have to decrease the number of animation cells from planed number, for avoiding object disappears. After many experiment, I find that this is not "a limit to the number of poligons within PerspectiveCall command". Because phenomenon is not changed even if I put out them to the outside of PerspectiveCall routine. And this is not "a limit to the number of the 3D objects" either. In this phenomenon, there is no difference between FS6(=FS95) and FS98+. (With further experiment, FS6 is better then FS98.) And I use sclink, but it is better not to use sclink. These are non-accountable phenomenon for "a limit to the number of the 3D objects".
Anyway, what is the specific condition in this time only ? The answer is .... I put many objects around 1-2 meter size, because this is an animation of jumper. On the contrary, in a case of Tokyo MEX, Yamanote-line and other default scenery of Tokyo, these sceneries consist of around 10-20 meter size objects minimum. Now, I name this phenomenon "nuclear force" as a matter of convenience, because this phenomenon is observed in the condition of compressed small objects to high density. This is a same idea that a proton and a neutron are combined by not gravity of Newton dynamics but nuclear force. And when objects disappear, not only objects disappear but also FS is terminated by errors or computer hung-up. Mentioned above, FS6 is better than FS98+ in a condition of "nuclear force". You can confirm it easily. There are versions for FS95 and FS98 in my NAGANO Olympic scenery, and Nagano98.bgl is for FS95 and Naga98a.bgl is for FS98. If you choose Nagano98.bgl by FS98, then FS hung-up and you have to re-start even Windows95. After all, it seems that "a limit to the number of the 3D objects" and "a limit to the number of dots and lines" look like nearly the same, and "a limit to the number of poligons within PerspectiveCall command" and "nuclear force" look like nearly the same.
It seems that there are four fundamental forces ( = limitations). Including this, some conditions are expressed as a next table.

	FS5.1	FS6	FS98	FS98+fsconv98
Inner variables	Many variables possible to use.	Few variables possible to use, and poor compatibility with FS5.1 variables.	The same to FS6. Well compatible with FS6.
Hysteresis effect	Each has the same.
.
A limit to the number of 3D objects	Each has the same limitation.			Limitation is eased drastically.
A limit to the number of dots and lines	These two have the same.		Worse than previous.	Limitation is eased drastically.
A limit to the number of poligons within PerspectiveCall command	Probably each has the same.
Nuclear force	Probably each has the same.		Probably the same to FS98+.	Worse than FS6.

Quantum mechanics, there is a famous Uncertainty Principle by Heisenberg. It maybe "position and momentum cannot be certified in the same time". Scenery has nearly the same phenomenon.
In the animation of jumper of NAGANO Olympic, jumper jumps very fast. If you see it from the distance, you recognize the motion but you cannot recognize correct position. If you see it from the near, you recognize the position but you cannot recognize correct momentum. What is it mean ? So, if a certainty of the momentum goes to zero, a certainty of the position becomes infinite. Anyway, I make the mode which can be seen all animation cells in stop motion. Please enjoy each picture with static condition.

In quantum mechanics, an orbit of an electron around an atomic nucleus is not continuous, it depends on quantum transition. In FS scenery, an animation is not easily animated continuous as an intention. One motion per 1/4 second is a limit in my circumstance. I make 1/8 second rate at a last of downhill and from jumping to landing, but I cannot observe at this rate. It is unknown whether this rate is not changed as a FS itself or rate is changeable by a hardware performance. My hardware is bare Pentium 166 MHz, it is not so good. How about Pentium II 333 MHz ? Video card maybe affect this performance.

Fortunately, all problem which I mentioned above is fundamentally resolved in FS2000. This is very nice, but there are many new problems which is occurred by FS2000 is appeared. In detail, please read this article.
And, I write about FS2000 dynamic scenery HERE.

I have got very useful advise about a limit of the number of objects written in this page, and knowledge of FS inner variables which is indispensable for making Moving Yamanote-line scenery from Mr. Konstantin Kukushkin. I would like to say many thanks to him.
I want to say thanks to Mr. Gene Kraybill (I can't contact him either. If you know about him, would you tell me the information please.) for correcting sentences of this page in English. He gave me very useful advise for fixing my poor English.