From: Stuart B. <stu...@gm...> - 2018-11-18 22:02:55
|
Hi All, I've just committed some changes to 2018.4 to support a new STG file verb that provides scenery designers with access to the random building shader. This follows on from a discussion Rick, James and I had at FSWeekend, where we wanted to reduce the disk space requirement of OSM buildings, and ideally make them even more efficient. So instead of having a huge .ac mesh that generates a large number of buildings, each building is defined in ~20 bytes. The STG verb format is BUILDING_LIST <filename> <material name> <lon> <lat> <elev> where: - <filename> is the name of a file containing building positions - <material name> is the name of the material that will be referenced to find random building parameters. - <lat>, <lon>, <elev> defines the center of the set of buildings, and also the point at which the material definition will be evaluated (for regional materials). For example: BUILDING_LIST buildings.txt OSM_Building -2.72943543 56.00080606 36.1 The referenced file (in the example buildings.txt) contains lines of the form x y z rot type where : - (x,y,z) define the bottom left corner of the building in cartesian space (+X is North, +Y is East, +Z is up), with (0,0,0) being the position referenced above - rot is the clockwise rotation around the Z-axis in degrees, rotating around the bottom left (SW) corner of the building - type is {0,1,2} which map to small, medium and large buildings respectively, as per random buildings. For example, the following entries generates 3 small, 2 medium and 2 large buildings in an easterly line: 0 0 0 0 0 0 100 0 0 0 0 200 0 0 0 0 300 0 0 1 0 400 0 0 1 0 500 0 0 2 That the x,y,z,rot parameters reference the SW corner is not ideal, but imposed by the random building shader. It _might_ be possible to change this, but it would involve sufficient additional shader math that my head would hurt :) Each BUILDING_LIST generates a separate Quad tree (an efficient spacial LoD tree), so for maximum efficiency, the number of BUILDING_LIST elements should be kept to a minimum - perhaps only one per tile. I've done very little testing of this, so it is probably somewhat fragile, but it's a pretty safe change as the code-paths are only exercised if the BUILDING_LIST verb is used. -Stuart |