Subscript Error - very large set of textures

[boleyd]

When trying to create a mosaic for a set of textures in excess of 2000 I receive a Subscript 9 error. I am warned that no more than 2000 textures will be presented, then the error. Working with a 600mb set of textures and BGLs that undoubtedly exceed 2000 texture files. It is from www.georender.com .

Given the number of textures involved I would need to be able to somehow subdivide them into groups of less than 2000. Not actually moving them but the creation of a map that defines the subdivisions. Otherwise, the chances of finding a particular texture is almost nil.

Another approach is to link via Connect or FSUIPC to bring up a mosaic of textures of the one that is under the aircraft and perhaps two more on each side to gain a perspective. Allow edit of the texture directly beneath the aircraft which is used as a selection pointer in this case.

Regards,
Dick Boley

 

[artmartin]

I agree that the mosaic function is the least polished part of my program and was never intended to handle scenery areas with thousands of tiles. I'm really tempted to add in some interaction with FSUIPC or FSCONNECT to give the users a method of navigating tiles more easily. That said, it would about double the size of my source code to add in that complexity so it'll be quite some time before I tackle that.

Here's the latest things I'm adding:

When creating multiple house rows, one has the ability to tell the computer to add in vegetation areas between and behind the houses that are produced. Almost done with that and the results are really cool. Housing developments look so much more realistic now, not just little rows of squares.

A custom bridge builder control. You define, from the generic objects, the ramp and span objects for the bridge you want to build from the generic objects available in FS. You also define the distances between those objects when the bridge is constructed and any rotation necessary for them to line up. In my program you then draw a line on the scenery tile where you want the bridge created and the program then places the ramps at the end at the proper orientation and as many span segments as necessary between the ramps. My quandary is whether to use autogen as the placement mechanism which requires additions to the DEFAULT.XML file or to simply create standalone XML files which get compiled into BGL's. I'm leaning towards the latter since it worries me that for distribution, requiring additions to the DEFAULT.XML adds in real complication and possibilities that there will be conflicts as different scenery designers add to that file.

Art

 

[boleyd]

Seperate BGLs would be my preference.

Dick Boley

 

[artmartin]

I tend to agree. Had a few local simmers over last night to look over my scenery and I made up a CD for them each. Pretty straightforward to copy the scenery directories and give them instructions on installing them into the scenery library but then I remembered that I had made custom object groups in my DEFAULT.XML file for things like bridge segments. My autogen program has the ability to define a rectangle on the scenery tile, set the number of objects you want strung end to end within it and any additional rotation you want imposed on them, and the program creates in this case a bridge. Naturally you don't get the end segments that way so the bridges are incomplete. Well, in order to distribute my scenery and have the guys get to see my scenery as it shows up on my computer, I have to explain to them how to put the new lines into their DEFAULT.XML file. This is perilous and technical stuff and I simply can't imagine distributing my scenery to a large audience and requiring each of them to edit an XML file. The two guys last night were certainly hard-core users and I'm not worried about them handling the task but the general public should not be touching low level files to install scenery.

The same thing goes for the objects I created using Rwy12 Object Placer. Wonderful program and has some great addon objects but it seems to me to be a burden on end users to require them to have some freeware addon to use your scenery even if it doesn't cost them anything but a download and an install.

Now mesh is a different story. I think it's completely realistic to distribute scenery, either free or commercial and stipulate that it just won't be up to standards without a hi-res mesh behind it. There's freeware meshes for anyplace in the US and a considerable part of the rest of the world.

So here's my next quandary. The autogen program places houses, vegetation, and objects based on not lat/long but on relative positions within the scenery tile. If I create a .bgl file that defines my finished bridges I'll have to position the segments by lat/long. I'm building the bridge building tool within the program because it's there but I'm seriously considering making it a separate program. I can get the latitude and longitude of the NW corner of the scenery tile from the file name but it will be difficult knowing the exact lat/long of a point on the image file. All the scenery tiles are completely square (256 X 256) but may represent an area that on the globe is long and thin or short and thick depending on the latitude. I don't think you can simply extrapolate the lat/long using the XY graphical position on the tile. There will be some error. Now whether that error will be substantial enough in that small area is beyond me. Does anyone know just how many degrees/minutes/seconds of lat/long a single scenery tile represents?

Maybe it's easier in a separate program using FSUIPC or FSCONNECT to pick your starting and ending points by slewing in FS where you'll already have the lat/long readings. I'll probably end up with the method that requires the least amount of intense brainwork. Successful programmers are often lazy programmers since they relate best to the majority of the users out there.

Art Martin

 

[rhumbaflappy]

Hi Art.

I answered this at AVSIM, but I'll repreat it here for others:

Each photoreal tile represents an actual LOD13 area in the FS world.

The tiles are 256 x 256 ( or 2^8 ). We know the LOD13 span for longitude ( 120 / 8192 or 0.0146484375 degrees ), and latitude ( 90 / 8192 or 0.010986328125 degrees ). 8192 happens to be 2^13... which is why it is called LOD13.

2^21 ( 2097152 ) should be the span of pixels in a photoreal tile:

longitude = ( 120 / 2097152 ) = 0.000057220458984375 degrees
latitude = ( 90 / 2097152 ) = 0.00004291534423828125 degrees

In other words, ( 0.0146484375 / 256 ) is the span for longitude for the pixels, and ( 0.010986328125 / 256 )is for the latitude span of the pixels.


If you know the NW corner of any tile, then you should be able to calculate the exact position of each pixel within each tile using the above spans. Position 1,5 from the NW corner would be:

( W + ( 1 * 0.000057220458984375 ))
( N + ( 5 * 0.00004291534423828125 ))


Each pixel, of each photoreal tile, has an exact address in the sim. The actual math is actually pretty simple.

Dick