Hi Gary,
Most of your discussion has been on the use of default landclass. Roby is using photo-scenery.
Hi George:
Thanks for sharing that important info regarding the scenery milieu for Roby's project.
Roby:
AFAIK, FS SDK (resample generated) photoreal imagery BGLs are technically a form of 'custom' land class, and inherently are assigned a rendering "sequence" second only to certain airport objects such as default RWY MDLs, and will always render on "top" of 'default' land class scenery content.
I use the term "sequence" here in an attempt to describe scenery rendering as a function of resultant visibility (from top to bottom), and to distinguish run time render outcomes from various terms historically used in FS scenery building such as:
* "layers" in either a VTP or 3D object modeling context
* a "render priority" in the context of parameters set in Terrain.Cfg
* and/or as
layer and
priority, as both are sometimes used in a Scenery.Cfg file / FS scenery library GUI context.
...thus describing FS run time
outcome versus numeric layer assignment / position / "
intended" render priority etc.
IIRC, vector content listed in Terrain.Cfg is a special form of default land class which has an inherently assigned rendering "sequence" below that of both the above airport objects and custom photoreal land class draped onto the terrain mesh.
Thus, custom photoreal land class will normally "cover up" default types of land class,
and special types of default land class objects such as vector polygons and poly-lines which have scenery library objects mapped with them to form what I refer to as "
meta-objects" which are assigned a GUID and listed in Terrain.Cfg.
However, IIUC, one can set a blend mask attribute using specific gray scale values in a 8-bit TIF file to allow default land class vector polygon and poly-line scenery content to
also be rendered at run-time when such a "transparency-enabling" blend mask is processed in a multi-source INF file via FS SDK Resample to output a imagery / placement BGL for one's custom photoreal land class.
When this is done, one will get a imagery / placement BGL that not only allows default land class (including vector polygon and poly-line scenery content listed in Terrain.Cfg) ...to be seen, but any autogen annotations applied to the underlying default land class may
also be seen all the way through to the "top" of one's scenery as rendered in FS at run-time... in the "transparent" parts of one's custom photoreal land class textures.
Such a scenario technically could allow a line of "Telephone Poles" to show through to the top of one's custom photoreal land class textures.
But in this scenario one may find it is easier to place scenery library objects as a "line of objects" via XML, rather than utilizing vector content along a poly-line using items listed in Terrain.Cfg, given the extra work involved to create a transparent window in one's custom photoreal land class.
Since transparency is inherently "computationally expensive" according to ACES, one might wonder what the performance trade-off may be between multiple areas of transparency in ones imagery / placement BGL versus forfeiting texture draw call batching by placing scenery library objects via "BGLComp XML" ...as separate "instances" at discrete coordinates.
If such performance issues are a concern, one can of course use the FS SDK Autogen Annotator to place one's Telephone Pole objects mapped to the custom photoreal land class via a *.AGN file.
Perhaps one could make the creation of lines of Telephone Pole objects (as autogen) somewhat easier by first using
ex: Google Earth with FSX-KML to generate all the poly-lines geographic Lon - Lat (X - Y) decimal degree coordinates with a sufficient number of (14) decimal places of precision.
Then one one could convert those coordinates from geographic to FS quad tree LOD-13 cell grid coordinates as "X-Y vector offsets" used in the special XML code compiled into AGN files, thus placing lines of Telephone Pole objects as
autogen.
Possibly Arno's autogen utilities might also be of some help with this process utilizing ESRI *.SHP shape files as input.
Might this be a viable option for your project ?
GaryGB