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]

[KEW]

[KEW]

[TreeHugger]

[KEW]

[TreeHugger]

[KEW]

[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.