A way to double the maximum number of trees in a landsc:

[KEW]

This was determined using FMS bete 8.5. It will probably work for all previous versions :

Trees are usually defined as two panels at right angles to each other, intersecting at their vertical centers. They are normally made with two sides to each 2D panel because a single side can be seen from only one direction

If you use "CULL OFF, a single sided panel can be seen from both sides. This means that you can define a tree by only representing two single sided panels.

The lighting for the two panels will be the same on both sides, so it will depend on whether you use clockwise or counterclockwise coordinates.

The example below uses the "Tree.bmp" from the FMS "World" scn.

If this is inserted in the middle of a .scn program, make sure that you use "CULL ON" at the end of the trees or you may get strange effects with the objects that follow..

CULL OFF
POSITION -12 -24 2.9
TEXTURE TREE TRANSPARENT

256 0 -6 0 11
0 0 6 0 11
0 256 6 0 0
256 256 -6 0 0

256 256 0 -6 0
0 256 0 6 0
0 0 0 6 11
256 0 0 -6 11

[TreeHugger]

Did you try whether this does in fact allow you to place a higher/double number of objects in a scenery? Please fill us in with the results of your tests.

Regards

[KEW]

I came up with this solution because I had to remove trees from one of my landscapes to add two new picnic tables. When I used the method shown, I was able to double the number of trees before I ran out of allocated memory.
I suggest that you try it for yourself.

KEW

[TreeHugger]

Ah, OK.
I thought you might have done some methodical testing. In that case, specific info on scenery/objects/polygons would help to reproduce the results.

Regards

[KEW]

I made my local field in FMS seven years ago in Win-98, but it was only a panorama and I didn't run into any size limitations. A week ago I revisited FMS. I downloadeed Beta 8.5 and found that none of the old fields I had on CD would run. I looked into this and found that FMS does not appear to support the "LINE" command any more along with acouple of other minor things.

I got all of the old fields working, and then tried upgrading the graphics in the old "Rodez" field. This is when I ran into the size limit a few days ago.
I have made acouple of new sites but I am still trying to find out what the real limits are and what space each type of command uses up. So far, I don't think the area of bitmap coordinated objects has any effect. I think it is the total quantityand type of command that control the program size.

Increasing the resolution of the bitmaps in the landscape does appear to reduce the size available for the rest of the program, but I have not tested anything quantatively yot.

Let me know if you draw any solid conclusions and I will share mine too..

[KEW]

I have been doing some systematic testing to try to find out what are the limiting factors to the number and size of objects that can be uncluded in a .scn before the allocated memory overflows.

So far I have observed some rather odd data and a very strange anomaly. I do have some firm conclusions, but I have not been able to quantize all of them yet because of some conflicting results.

The number and size of the bitmaps used to make up the world map adversly effects the number of objects that can be placed on it.

There appears to be a limit on how many times the "TEXTURE" command can be used to read the bitmap images. So far I have not found a limit for how many times or how much area of the bitmap data can be read from the specified bitmap and projected onto surfaces after using this command.

I found that a total of 36 256 x 256 bitmaps, less the number of bitmaps of the same size used in the world map, could be read using the "TEXTURE" command. If larger bitmaps, e.g. 512 x 512 are used in the world map, then the number of 256 x 256 bitmaps containing the same total number of pixels should be subtracted from this number.
There must be other limits but I have not found them yet.

This would indicate that a very large number of objects could be placed into the scenery by sequencing the placing of the surfaces on all different objects using the same bitmap under the same "TEXTURE" command. Using this, I was able to place fifty trees into a scene using five different tree bitmaps and five "TEXTURE" commands. I believe that I could have made a lot more but I ran out of available time.

I guess from your questions that you are already aware of some of this. Would you like to offer any helpful information?

[TreeHugger]

I don't have an explanation for this effect, I just found it to be quite puzzling. All the sceneries I've made so far are panoramic, so I've never run into any complexity limit.

Here are my thoughts:
It shouldn't make any difference to the graphic engine whether you define two single-sided polygons or one double-sided - the triangle count is the same. Just like a quad or two triangles will eat the same amount of memory after tesselation. If it was a performance issue with the graphic engine, it would just get laggy with more objects rather than throwing an error. That would point towards a certain size or command limit on the scn-file itself. But then again, I've also witnessed cases where one scenery designed to max out on objects would not load on other systems, indicating it's somehow hardware related as well. That's why I asked about your testing procedure and results, to shed the light of empiricism into this bundle of assumtions of mine.

Regards

[TreeHugger]

There appears to be a limit on how many times the "TEXTURE" command can be used to read the bitmap images.

Now this is something that's familiar to me, because it affects panoramic scenes as well.
When you reference a texture for some quads, then another one for more geometry and finally the first one again, it will get loaded into memory twice. With big textures like panorama images this will eat up video memory like a hungry wolf. The solution is, like you suggested, to put all geometry referencing one texture into a single block. In other words, sort your quads by texture reference and use just one "texture" command each.

Regards

[KEW]

Thank you for your comments. It is gradually beginning to make sense to me but there is still a lot that I know that I don't know. I am keeping notes on my findings so that I can maybe help others through some of the frustrating parts of the learning curve.

I will keep pushing the limits and will post my findings. I guess we really need a good manual and probably the only way we can get one is by writing it ourselves.

Regards,

Keith.

[KEW]

I have done a little more testing on two other computers:

Computer 1: 600 MHz, 128 MB RAM, Intel 82810E Graphics with 32 MB RAM.

Computer 2: 470 MHz, 512 MB RAM, Intel 82810E Graphics with 32 MB RAM.

Computer 3, 500 MHZ, 128 MB RAM, Cirrus Logic Graphics with 2 MB RAM.

On Computer 1, I made a test program that had just enough "TEXTURE" statements in it to mess up the graphics without causing an error message. When I ran the program on the other two, I got identical results.

This indicates to me that the memory limit problem is not caused by the size of computer RAM or graphics RAM. The FMS program must only allocate a specific amount of memory for the graphics to work in.

Regards,
Keith.

[TreeHugger]

On Computer 1, I made a test program that had just enough "TEXTURE" statements in it to mess up the graphics without causing an error message. When I ran the program on the other two, I got identical results.

Very interesting, so there is a certain amount of TEXTURE statements that will cause graphic errors, but not yet fail to load the scenery? That's one more case to be aware of. The independence from System and video RAM is obvious in your tests.

All I know from experience with panoramic sceneries is the maximum of raw texture data I used was 72MB (six bitmaps 2048px wide, 24bit). With the same textures referenced twice, that would create a memory footprint of about 260MB, load slowly and and cause an occasional stutter when the swap disc activity began to kick in. No graphic errors or error messages, though. When I optimised the scenery to single texture reference the memory footprint was reduced to 130MB and everything was running fine with either 128 or 256MB of video RAM.

More questions than answers on my side, apparently...

Regards

[KEW]

Thanks for the information.

I should have mentioned that "messing up the graphics" was indicated by the tree bitmap I was using for the objects showing up on the ground instead of the grass I had programmed in. The object data overwrote the area containing the floor map and all of the objects were the right shape but were plain grey in colour.

By the way, I had a look at some of the photorealistic German fields you mentioned in an earlier posting. They are really stunning. So real tht I felt like rolling in the grass and the snow. I shall enjoy flying my favourite planes in them.

Regards.

[TreeHugger]

By the way, I had a look at some of the photorealistic German fields you mentioned in an earlier posting. They are really stunning. So real tht I felt like rolling in the grass and the snow. I shall enjoy flying my favourite planes in them.

I'm glad you like them! Most of the look is owed to the great photography that I could build upon. Getting things into FMS is fairly easy as you see in the .scn-files. How do these sceneries perform on your machines - any lagging or glitches?

Regards

[KEW]

The .scn files took about four times longer to load than the "World.scn" but they run fine. I have flown around all of them on the 600 MHz computer a number of times without any hesitation problems or glitches.

Regards.

[KEW]

I have finally been able to clean up the .scn of my old flying site in Toronto, and get it working correctly in beta 8.5. I put it together 7 years ago in Win.98.

It is a 360 degree photograph panorama of the site where the Electric Model Flyers of Southern Ontario used to fly. The quality is by no means up to the sites you have been putting together, but if you are interested in taking a look, send me an e-mail at k-walker@cogeco.ca and I will mail you a zip file.

Regards.