Форум

[ Обновленные темы · Новые сообщения · Участники · Правила форума · Поиск · RSS ]

Страница 1 из 2
1
2
»

FS9 Autogen Issues

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:10 | Сообщение # 1

Группа: Удаленные

Wondering if anyone may have any insight to why part of this photo tile won't take autogen? I used Autotrees beta to add autogen trees to the entire photoscenery and then I've been opening these in the annotator to add buildings and relocate any trees that didn't wind up in logical places. Here are some screenshots:

Here I replaced the tile with a blank texture, as you can see it's not the entire tile that's not taking autogen:

Here's what it looks like in the annotator, the yellow outline approximates the offending area:

I have some tilted LWM polygons under this tile to try and smooth out the airport plateau problem, but I disabled my LWM3.BGL temporarily and it made no difference. I've looked at the area with LWMViewer2 and I can't see where there's anything weird under this area other than my tilted polygon. I've noticed other tiles in the photoscenery with bare areas, but most of them are out and away from the airport so it doesn't matter so much. This looks horrible and it's what you see when on final for rwy 16 so I'd like to get it sorted if possible.

Also, is/are there GUID's for the default autogen trees so a person could place them like any other object?

Сообщение отредактировал bar_rodoy - Понедельник, 01.08.2011, 11:12

@737@

Дата: Понедельник, 01.08.2011, 11:13 | Сообщение # 2

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Quote (bar_rodoy)

Also, is/are there GUID's for the default autogen trees so a person could place them like any other object?

Here's a couple of links that might help set you on course for finding a satisfactory solution for accessing FS9 Autogen:

http://www.wiki.fsde...read.php?p=3920

http://www.wiki.fsde...ead.php?t=16786

Quote (bar_rodoy)

You've got some obscure things happening in that yellow area !

Be aware that both LWMViewer versions 1+2 only show DEFAULT filenames for the area under one's aircraft, and it will not identify or list 3rd party files (ex: UT-USA land class, MegaScenery autogen objects.

You may also wish to identify the quad matrix ID for the area of interest and use FS9 (or better yet FSX TMFViewer) to load up files in TMFViewer for that area based on FS filename strings and/or FS folder location to see if you can get an idea of what might be involved there as well.

BTW: There was a clash between UT-USA night lights and Megascenery night lights in FS 2004 that required use of only 1 or the other, or disabling both to stop clobbering of daytime autogen objects.

http://www.simforums...topic26191.html

Also, if there is a thermal too close to the ground, it could eradicate autogen.

There are a number of other scenarios which could potentially clobber autogen in the area of interest when in the vicinity of an airport; I'd suggest a search at FSDeveloper Forums may turn up additional insights, and posting a copy of this inquiry there in the Autogen Forum might evoke some input as well. :wink:

http://www.fsdevelop...splay.php?f=104

PS: How did you make and place your "LWM3 polygons" at the area in question ? :Confused:

Hope this helps ! :smile:

@737@

Дата: Понедельник, 01.08.2011, 11:14 | Сообщение # 3

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

RE: "...identify the quad matrix ID for the area of interest..." in my post immediately above

New post as AVSIM's ridiculous Edit option "timed out" on me; it took me a while to find this FS9 "base file" diagram:

http://forum.simflig...ific-bgl-files/

Posted Image

FYI: If necessary, disable JavaScript / refresh page to right-click and "Save Image As" to download full JPG file for future reference.

IIUC, this is the FS9 equivalent to the FSX Base File reference.

Ex: Emma Field / Seattle area airport backgrounds are in [FS2004 install path]\Scenery\Namw\Scenery\AB915150.bgl

PS: Many thanks to Joe Bush for originally posting this info. :wink:

Hope this helps further ! :smile:

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:14 | Сообщение # 4

Группа: Удаленные

I appreciate your reply, it obviously required some research to gather all the links and I really appreciate it. I'm at work at the moment but I'll read up on all this this evening and see if I can find a solution. I do have UT lights but no megascenery products installed. I'll try disabling the lights. LWMViewer2 does actually seem to be showing me the UT files in place for the area and the originals have all been renamed by UT so I don't think I'm missing anything hidden under that particular tile but I'll give TMFViewer a try (actually hadn't thought of that). For the moment I've back-burnered the autogen issue and am currently trying to make a gmax groundpoly for the airport with some limited success.

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:14 | Сообщение # 5

Группа: Удаленные

SBuilder can make those, it took I think 7 tilted polygons all fitted into place like pieces of a pie. It's not a perfect solution to smoothing out terrain by any means, I need to fiddle and tweak some more with the coordinates and elevations of the polygon points, I've really only had success in moving the ugliness out and away from the airport where it isn't so noticeable at this point. A greater number of smaller polygons I think would do a better job of smoothing out the area, as it is now some of the corners of the polygons "stick up" a bit. I wish you could assign an elevation for every point of the polygons, but basically all you can do is assign the highest and lowest points and SBuilder makes a perfectly flat "tectonic plate" between the two. The airport has a small hill to the East in the real world and another just off the end of Rwy 34 which is actually "NOTAM'd" as a hazard on the approach plate, so I'm trying to keep these hills intact if possible. These polygons do show up in LWMViewer2 incidentally.

Thanks again,

@737@

Дата: Понедельник, 01.08.2011, 11:15 | Сообщение # 6

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Quote (bar_rodoy)

Thanks for the heads up on the ability of LWMViewer to actually display 3rd party TMF BGLs from UT; I'd forgotten I turned UT-USA off a while back when working on some scenery, and had forgotten to turn it back on. :blush:

It's been a while since I tinkered under the hood in FS9 with LWMViewer2, and I didn't recall having seen the UT files at the time I last ran LWMViewer2 ( probably because it was turned off then as well ! )

But it's good to know Jim Keir's marvelous utility still performs admirably for FS inquiries with both default and certain 3rd party files; thanks for so kindly pointing that out, as I would not want to have dissuaded anyone from making use of that valuable resource ! :Big Grin:

BTW: Relative to the current inquiry, are you still running the FS add-ons install configuration you described here ?

http://forums.flight...FS9-Water-Addon

@737@

Дата: Понедельник, 01.08.2011, 11:16 | Сообщение # 7

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Quote (bar_rodoy)

Good to know, as I had the impression with SBuilder for FS9 (SB9) and Airport design Editor (ADE9X) we could assign the 3rd elevation of such triangles (at least where they overlap neighboring triangles).

Was this what you were describing as the current behavior of SBuilder with LWM3 polys?

http://www.newsite.f...ead.php?t=10663

Some additional info as to how others are using sloped flatten polys:

http://www.newsite.f...ead.php?t=10663

To see what ADE9 does with such "triangles" versus SBuilder8 / SBuilderX, I guess one must "RTFM" (and test):

In SBuilderX:

1.) Click Help > SBuilderX Help > Search Tab

2.) Enter the word "Slope", then Click "List Topics"

NOTE: "Working With Points, Lines and Polygons" = only hit returned on "List Topics" Search)

3.) Click "Working With Points, Lines and Polygons", then Click "Display"

4.) In SBuilderX Help right-side Window Pane, scroll down to "Set Altitude"

An example of Sloping Polygons in the Airport design Editor (ADE9X) English Manual:

1.) Download "ADE9x-Manual-EN.zip" from:

http://www.downloadc...ffyduck.org.uk/

2.) Browse to "ADE9X Current Version" > "ADE9x-Manual-EN"

3.) In that PDF Document, Navigate to: 15.2.3 Sloping Polygons (Pages 188+189)

It would be interesting to see what others experience may be with FS9 versus FSX sloped flattens as to whether all 3 vertices can actually be assigned individual elevations in ADE, SB9 and/or SBX. :Thinking:

I'll be curious to read what you find out on this latter sloped flatten issue, as well as the original above autogen issue when you have a chance to check into it more !

PS: I really appreciate your MOD to the Finney Crosshairs Plus, and use it all the time. :Applause:

I was also wondering if you ever considered making a very large version of the Finney Croshhairs Plus (ex: 100 M / 10 M graduations) for occasional odd FS scenery measurement tasks (sort of like we had in Lou Volland's FS2002 "Crosshair Box English" and "Crosshair Box Metric" aircraft)... as these don't render in FSX ? :Praying:

Scenery Design Planning Aircraft

http://library.avsim...misc&DLID=33046

Scenery Design Aircraft Metric Version

http://library.avsim...misc&DLID=33058

Regards,

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:16 | Сообщение # 8

Группа: Удаленные

I didn't know ADE9X could do those polygons, I'll definately have a look at that, or is that an FSX only thing?

Yep, still running "Holger's Water", tried lots of others, still haven't found anything I like better... :smile:

Jim

EDIT: Sure, I can whip something up on the scenery .mdl. It'll be an FS9 model (exported with the FS9 gamepack), but if I texture it, it should work OK in FSX for what you need it for. Did you want it graduated in feet or meters?

@737@

Дата: Понедельник, 01.08.2011, 11:17 | Сообщение # 9

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Quote (bar_rodoy)

ADE has a version for FS9 (ADE9) and for FSX (ADEX); AFAIK, most features are duplicated between versions (with exceptions as it's still in ongoing development).
If it wouldn't be too much work, I'm thinking one each for both Feet and Meters would be ideal, as some FS Developers would work in either (or both) sets of units... depending on their project world location, or scenery creation methodology. :blush:

Very good of you to consider this, and I think many would greatly appreciate having you post another fine contribution to the FS scenery development community for download ! :Big Grin:

Regards,

Сообщение отредактировал @737@ - Понедельник, 01.08.2011, 11:17

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:17 | Сообщение # 10

Группа: Удаленные

I honestly hadn't been into the "FSX side" of ADE9X yet and I see where there is a polygon button that's absent in the FS9 version. Those apparently are some type of XML polygon that's new for FSX. If I'm not mistaken the ones SBuilder makes are compiled with scasm. In ADE9X -> FSX it looks like the thing to do is make triangles and set an elevation for each individual point. In Sbuilder you can set only the highest and lowest point and the sim renders a flat plate between the two, laying flat and perpendicular to a line drawn through the center of the earth (I think). I've had little success with less than 4 points as it seems impossible to control the elevation of the 3rd point in a triangle. A line drawn between the highest and lowest points needs to go across the plate diagonally rather than down the length of one side. I wound up using triangularly shaped 4-point polygons which seemed to work pretty well. Having the ability to set the elevation of that 3rd point is yet another compelling reason to switch to FSX.

Also, I looked at those Lou Volland crosshairs thingy's and started building a 100m square placement tool, but it seems to me that a grid pattern of maybe 10m squares filling the box might be more useful than the concentric squares it appears Lou used. Any thoughts?

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:18 | Сообщение # 11

Группа: Удаленные

Well I'll be dipped, it turns out the UT lights are in fact the culprit with the autogen issue. I disabled them and low and behold that tile displayed it's autogen perfectly. Doesn't really solve any problems though since most users (me included) are probably going to want to run the UT lights. I wonder if I can exclude the lights somehow without excluding everything else too?

@737@

Дата: Понедельник, 01.08.2011, 11:19 | Сообщение # 12

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

I'd need to delve further into ADE and SBuilder9 to see what each is able to do and what format BGL each is outputting for sloped (aka "tilted" or LWM3) flattens.

BTW: A 'few of the few' leads I've found thus far researching this LWM3 topic in Forums at AVSIM and PTSIM / SBuilder Support:

http://www.google.co...304850557947867

FYI: Thus far, I've only had time to look through the first 2 pages of hits on the above Google query
Currently, the Lou Volland "Crosshair Box" aircraft have these limitations:

1.) They don't render in FSX

2.) They are limited usefulness for some tasks by their sizes:
a.) Crosshair Box Metric "Has 1, 10, 15, 20, 25, 30, 35, 40, and 50m. boxes"
b.) Crosshair Box English "Has 1ft., 10ft., 20ft., 25ft., 50ft., 100ft., 150ft. and 200ft. boxes"

I'm wondering if it might be practical to do 2 types of such a "FS scenery developer's helper object aircraft" ? :Thinking:

1.) A bigger "cross-hairs" aircraft for scenery placement that's fly-able / slew-able mouse-yoke-able as we have in your MOD-ed Finney Crosshairs Plus

This could have 100 Meter / 328.083 Ft. and smaller increments of "numeric unit" and color bar graduations on it along the X,Y,Z object axes (which in this case might be made with the same MOD-ed Finney Crosshairs Plus or comparable type object)

2.) A "LOD reticle" or "Quad Matrix grid" aircraft as we have in the Lou Volland English and Metric crosshairs

This could have LOD-13 and LOD-13 Area Point (aka "cell") sized "numeric unit" and color bar graduations on it along the:
a.) Outermost LOD border (...and...)
b.) Central crosshair axes (which in this case might again be the same MOD-ed Finney Crosshairs Plus or comparable type object)

NOTE: FSX SDK TMFViewer loads legacy and FSX placement BGLs, but not legacy imagery BMP tiles (...only FSX's imagery BGLs load/display with grid overlays etc.)

FS default land class LOD quad matrix info can be visually displayed as a grid on FS top of terrain with Richard Ludowise's CellGrid2004a (and Edgar Knobloch's CellGenerator displays Lat/Lon info in a somewhat comparable manner).

And of course one can identify legacy tile info in a dialog box with Richard Ludowise's TCalc2004 Version2.0 and/or George Davison's "IdentifyTile".

However, in some scenarios one might wish to have a FS LOD / Quad cell grid visually superimposed upon one's FS legacy format custom land class photoreal terrain texture (BMP) tiles, which apparently cannot be done using methods provided by Richard Ludowise's CellGrid2004a and/or by Edgar Knobloch's CellGenerator.

For this, I'd like to use either a 100 Meter or LOD-13 sized "grid aircraft" (and/or FS9 format scenery library object with no 'crashbox' if possible) as an overlay visible on top of one's FS terrain.

If during 3-D modeling, the central aircraft datum / object reference point is placed precisely at the object's "top left corner", one could in FS map view (or via another utility) "jump" the aircraft to known fixed coordinates of FS quad matrix "NW corner origin" vertices to display a "frame of reference" for certain scenery design considerations. :wink:

Of course, the latter "aircraft flat on ground" procedure would only work well over 'flat airport terrain'.

Other textured "mesh-clinging" grids that display with priority on top of photoreal textures in FS9 would have to be made by rather esoteric methods (if can even be done).

Additionally, I had the impression that if it can be done, by now either Richard Ludowise's CellGrid2004a and/or Edgar Knobloch's CellGenerator might have provided a way to do this for visualizing grids on legacy photoreal scenery in FS9, and that such display of such in-sim visible terrain grids might be similarly implemented for FSX.

PS: I'd be interested in reading other FS2004/FSX Scenery Developer ideas as to what crosshairs / grid / ruler aircraft and/or scenery objects they'd find useful. :Nerd:

Hope this provides some additional helpful input. :smile:

@737@

Дата: Понедельник, 01.08.2011, 11:19 | Сообщение # 13

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

What's the airport ICAO or coordinates of the scenery area in question ? :Confused: (...if that's confidential, PM me here)

The [FS install path]\FS2004\Scenery\UTUSA\Scenery\LM9*.BGL files contain UT-USA night lights.

These are SCASM / Scenery Assembler type BGLs which can be examined as *.SCA output via BGLAnalyze version 3.1, suggesting FS legacy code is used for a "NAV light".

Apparently the UT-USA "NAV Light" objects clobber autogen when placed with methods implemented in those SCASM-type placement LM9*.BGL files.

BTW: I'm not familiar with the complexities of SCASM, but as I read it, such lights normally display at a default hard-coded size.

However, there may be some question as to whether there's a way to over-ride a resulting eradication of autogen display by "light" objects via specifying an "X,Y footprint" size in object placement:

http://www.scasm.de/..._cmd5.htm#light

http://www.ptsim.com...848&hilit=light

http://www.ptsim.com...287&hilit=rwy12

http://forum.avsim.n...ch-lights-help/

FYI: Only FSX has implemented an "XML" scenery object placement parameter option to disable autogen suppression:

<NoAutogenSuppression>

Hopefully there might also be a feasible way to actually display night lights via the very large coverage area UT-USA file set for FS9 without also suppressing autogen.

It might be nice to have an alternate version of the UT-USA LM9*.BGL file in a different format that instead uses the smaller "Light Balls" that Dick Ludowise so generously created recently for the FS Community:

http://forum.avsim.n...me-light-balls/

I don't know whether Allen Kriesman as author of the UT product line might ever consider releasing an alternate file set for FS9 and FSX to provide smaller lights for those of us that would prefer them that way (rather than the current ones which IMHO, are too large and visually distracting from the rest of the scenery for GA aircraft night flying... and perhaps as well for heavies during take-off and landings).

But I guess it wouldn't hurt to ask him ! :Big Grin:

PS: I hope Dick Ludowise and others might offer more info here on whether such night lights can be implemented in FS9 without also suppressing autogen... so we know whether there might be any point in pursuing this option. :Angel:

Regards,

Спец_Блатной

Дата: Понедельник, 01.08.2011, 11:20 | Сообщение # 14

Подполковник

Группа: Персонал

Сообщений: 95

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Quote (@737@)

LWM3 poly for FS9 requires for each polygon, a min altitude and a max altitude. Then, for each point in the polygon 3 values are needed, corresponding to lat, long, and an 8-bit fractional height (i.e., in 1/256ths) between the max and min alt defined for the polygon. The sdk makes no mention of it, but at least it was always my understanding that the polygon had to be planar. Thus the problem of properly computing the height value at each point. I think SBuilder works by assuming the polygon is a plane, and computing the vertex heights accordingly. Naturally there is no way to do this for a triangle. But playing with simple triangles, I could create one that works by setting the max and min altitudes in the LWM poly properties, then going back and editing the altitudes of the 3 points in my polygon. That seemed to work and the scm file that SBuilder created seemed correct. Note that LWM3 polys are clipped at LOD 13 boundaries, so if your triangle crosses a boundary you will end up with two polygons, one of them 4 sided.

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:20 | Сообщение # 15

Группа: Удаленные

Thanks for that little tidbit Scott, I just did a 5 minute test with this and completely eliminated a problem area I've been fiddling with for a week :smile: . Much appreciated!

Gary, one issue I'm having even with the 100m model is it's so big that you can barely see the outer rails as they are so far away (see last screenshot I posted, it's not finished, I just exported it to see what it would be like in the sim). I put some NAV lights on all 4 corners and it helped, but it's difficult to really tell where the outer edges of this thing are from spot view, top-down isn't so bad but it appears faint against most backgrounds. Currently the rails are .1m square in cross section (about 4"), I can make them bigger, like maybe 1m and they'd show up better (stronger and able to take more abuse too :smile: ), but I wonder if I'd be giving up accuracy? If I remember correctly an LOD13 square is around 1200m, no? Another problem is that an LOD13 square isn't the same size and shape in Alaska as it is in Panama. Kind of a neat idea with re-positioning the reference point, I'll look into that.

The airport is KMYL, McCall, ID. I've narrowed the lights down to LM917160A000202.BGL. Thanks for the heads up on the naming convention, that definitely saved some time. I hadn't viewed the area at night and was surprised to see that the lights were not excluded by the photoscenery as most everything else is. I guess it stands to reason that the objects were still there if they were knocking out the autogen. Fair enough, if this scenery ever sees the light of day I'll just put a notation in the readme about the UT lights and disabling the bgl.

@737@

Дата: Понедельник, 01.08.2011, 11:21 | Сообщение # 16

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Quote (bar_rodoy)

Many thanks for the replies, guys!

Posting from cellular mini-browser as I'm still on the road until tomorrow; will reply then, once back at a proper keyboard (...don't know how "Text-ers" can stand using these things!).

Regards,

@737@

Дата: Понедельник, 01.08.2011, 11:21 | Сообщение # 17

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Hi Scott:

I'm refreshing my familiarity with the FS2004 Terrain SDK "Terrain Vector Data.doc"; IIUC, this is the pertinent section with the parameters you are referring to:

Code

"The Sloped LWM Polygon: LWMPoly3 and LWMPoly3Ex
The LWMPoly3 structure adds the ability to include height information for each point in the polygon and is normally used for wide river channels that gradually slope downhill. There are two structures to use depending upon the number of points in your polygon:
Use LWMPoly3 for polygons with up to 62 points.
Use LWMPoly3Ex for polygons with 63 to 191 points.
The system cannot handle polygons with more than 191 points. Break these up into smaller polygons.

struct LWMPoly3
{
UINT8 bPointCount:6; // Up to 62 points
UINT8 bReserved:1; // Must be 0
UINT8 bAttrib:1; // Polygon fill attribute, 0 = water, 1 = land
SINT16 iMinHeight; // whole elevation in meters of the lowest point
SINT8 iMinFraction; // fractional part of lowest elevation in 128ths
SINT16 iMaxHeight; // whole elevation in meters of the highest point
SINT8 iMaxFraction; // fractional part of highest elevation in 128ths
};

struct LWMPoly3Ex
{
UINT8 bPointCount:6; // Must be 63
UINT8 bReserved:1; // Must be 0
UINT8 bAttrib:1; // Polygon fill attribute, 0 = water, 1 = land
SINT16 iMinHeight; // whole elevation in meters of the lowest point
SINT8 iMinFraction; // fractional part of lowest elevation in 128ths
SINT16 iMaxHeight; // whole elevation in meters of the highest point
SINT8 iMaxFraction; // fractional part of highest elevation in 128ths
UINT8 bExPointCount; // Number of polygon points = 63 + bExPointCount
};

The Sloped LWM Point: LWMPoint2
Points with height are used to define the vertices of polygons using method 3. The origin (0,0) is located at the northwest corner of the area. (255,255) is the southeast corner of the area. The height value is an 8 bit encoding of the range between the minimum and maximum heights of the polygon.

struct LWMPoint2
{
UINT8 bX;
UINT8 bY;
UINT8 uHeightIndex;
};

PS: I wonder if one can also implement some additional tricks with LWM3 polys like the SDK says we can with LWM2 polys: :Thinking:

"Specifying No Flattening with Flight Simulator
Note: If you do not desire flattening for a particular polygon or data area, use an iHeight value of –9999 and an iFraction value of 0. No flattening info will be applied for a polygon or data area that contains these values."

@737@

Дата: Понедельник, 01.08.2011, 11:22 | Сообщение # 18

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

Indeed, the quads do vary, which I had forgotten in my initial session of "imagineering" after a long day, so a "1 size fits all" LOD / LOD Cell sized aircraft would be unfeasible.

To refresh my memory on this I went looking and found FS-Insider Adam Szofran's wonderful article "Global Terrain Technology" at its new URL at:

http://www.microsoft...balTerrain.aspx
BTW: Even though a "1 size fits all" LOD / LOD Cell sized aircraft would be unfeasible, perhaps a scalable FS scenery library object 'might' still work.

The big question with regard to that option might be what is feasible for the creator of that object (you), as I wouldn't want this to become too complex of an undertaking that inappropriately places demands upon your very kind generosity for offering an upgraded / alternative crosshairs tool for scenery placement.

Also we'd need to see if this would work for the end user, from the standpoint of such an object's resulting size and visibility as a function of granularity of control over scalability (when configured via an interactive preview capable object placer such as EZ-Scenery / Instant Scenery or Whisplacer).

NOTE: I'm not sure yet if custom (non-default) object libraries can somehow be added to Whisplacer for use in FSX.
I still trying to find more references on how to use "Nav lights" in a SCASM or BGL-C type BGL in FS2004 scenery without suppressing autogen; 1 possible lead so far:

http://www.fsdevelop...4752#post144752

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:23 | Сообщение # 19

Группа: Удаленные

yes I'm sure someone could probably make a scaleable (animated) model that would read the current lattitude through XML and adjust it's width accordingly to match the size of an LOD cell anywhere on the planet, but I'm afraid that person isn't me. I spent almost my entire weekend fiddling with my ground poly and haven't made any real headway on the scenery placement tool. I did manage to add some modeled nav lights (ala Posky) to all 4 corners of the 100m job which helps with visibility somewhat. I'll do a little more fiddling and get a "beta package" together soon for you to try out.
Thanks for that, I've managed to decompile LM917160A000202.BGL and find the individual light placements which I copied to a new .sca file. I added the "dummy" return call to all of them and recompiled this to "kmyl_lghts.bgl" which now displays the lights at night without knocking out the autogen.

Additionally I followed a link that someone in that thread posted (which was irrelevant to the OP's query in that particular case, but very relevant to me) and also managed to tweak my groundpoly so that it doesn't interfere with autogen either :smile: .

That's two tweaks in one evening for me that worked and I'm stoked. KMYL is starting to look pretty good! :smile:

@737@

Дата: Понедельник, 01.08.2011, 11:25 | Сообщение # 20

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

First, a couple of edits for omissions and errors in my post above (...thanks this time due to a recurrent AVG pop-up 'nag-screen' that grabs console focus < grrr ! > ) :
"Subdividing the Surface of the Earth
To help organize and manage the terrain data at run time, we subdivide the surface of the Earth into cells organized into a quad tree. There are several schools of thought concerning how best to do this. One of the simplest is to subdivide the globe along geographic lines of latitude and longitude. However, because the lines of longitude converge at the poles, the scale of the cells varies with latitude. Polyhedral subdivisions of the globe can reduce the scale variation, but at the cost of added complexity [2, 3, 4].

Figure 2: Geographic subdivisions of the globe

Figure 3: Polyhedral [6] subdivisions of the globe

The biggest disadvantage of polyhedral subdivision from our perspective is that it's simply too difficult for content producers to author tiling textures that fit the often triangular or parallelogram shaped cells. The geographic subdivision method, in spite of the convergence issues at the poles, simply wins on the basis of simplicity and familiarity. Besides, while Flight Simulator allows trans-polar flight, most of the action still occurs at the middle latitudes where the majority of the world's population is concentrated.

To minimize scale distortion where most of our customers live and fly, we designed our quad tree so the ratio of north-south to east-west extent of the cells is nearly 1:1 at +/- 45 degrees of latitude. This was done by designating six root cells, three north of the equator and three south of it. Each root cell covers 90 degrees of latitude and 120 degrees of longitude."

BTW: Even though a "1 size fits all" LOD / LOD Cell sized aircraft would be unfeasible, perhaps a scalable FS scenery library object 'might' still work.

The big question with regard to that option might be what is feasible for the creator of that object (you), as I wouldn't want this to become too complex of an undertaking that inappropriately places demands upon your very kind generosity for offering an upgraded / alternative crosshairs tool for scenery placement.

Also we'd need to see if this would work for the end user, from the standpoint of such an object's resulting size and visibility as a function of granularity of control over scalability (when configured via an interactive preview capable object placer such as EZ-Scenery / Instant Scenery or Whisplacer).

NOTE: I'm not sure yet if custom (non-default) object libraries can somehow be added to Whisplacer for use in FSX.

@737@

Дата: Понедельник, 01.08.2011, 11:27 | Сообщение # 21

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

What I meant to communicate was that I'd be grateful to have something even as basic as a larger 100 Meter size Finney Crosshairs Plus to use with occasional special project needs such as planning ground poly use and/or checking out RWY display anomalies in FSX, the SDK for which, IIUC, now requires that custom ground polys / RWYs be made in max 100 Meter segments... to accommodate the "spherical" FSX world model and curved horizons.

http://www.fsdevelop...ght=Round+Earth

http://www.fsdevelop...ght=Round+Earth

The idea for a "LOD reticle or Quad Matrix grid aircraft as we have in the FS2002 Lou Volland English and Metric crosshairs" is more just my thinking out loud as an opener for discussion to hopefully solicit input by you and other scenery developers to see what might be of interest to the FS Community.

I like the idea that you expressed for somehow being able to "make a scalable (animated) model that would read the current latitude through XML and adjust it's width accordingly to match the size of an LOD cell anywhere on the planet".

But within my currently limited understanding of aircraft and/or scenery modeling, I had not anticipated that might even be possible to achieve, so I certainly would not have asked such a complex task of you under the auspices of your very kind offer for a quick MOD of the existing Finney Crosshairs Plus. :blush:

At most, I thought we might initially identify a way to add some extra sort of graduations and/or a 3D 'frame of reference' to that scenery designer's helper which may contribute to easing certain tasks involved in the scenery development process.

Regarding the possible creation of a "scalable" FS scenery object library object for a 'frame of reference' beyond the current crosshairs and CellGrid markings limited to non-photoreal default or custom land class, I meant that via the use of the XML "Scale" parameter, one might be able to assign an appropriate size to a "LOD reticle or Quad Matrix grid" as in this example of "Scale" seen in the context of placement code for a default rotating civilan airport beacon:

Code

<?xml version="1.0" encoding="ISO-8859-1"?>
<FSData
    version="9.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="bglcomp.xsd">
    <SceneryObject
       lat="42.7958654038715"
       lon="-70.8411665715632"
       alt="0.0M"
       altitudeIsAgl="TRUE"
       pitch="0"
       bank="0"
       heading="7.0"
       imageComplexity="VERY_SPARSE">
       <LibraryObject
          name="{7f38bfbc-e295-4a40-845c-3f3c872cfa82}"
          scale="1.00"
          />
       <AttachedObject
          attachpointName="attachpt_beacon"
          pitch="0"
          bank="0"
          heading="0">
          <RandomAttach
             randomness="ALWAYS_DISPLAY"
             probability="1"/>
          <Beacon
             type="CIVILIAN"
             baseType="AIRPORT"/>
       </AttachedObject>
    </SceneryObject>
</FSData>

When configured via an interactive live-preview-capable object placer such as EZ-Scenery / Instant Scenery or Whisplacer, one can dynamically assign "Scale" with immediately visualized change in object size on-screen.

However, I'm not certain if the "Scale" parameter in FS SDK XML processes fractional units (aka 'granularity of control over scalability') beyond 2 decimal places to allow precision sizing of a FS scenery library object so that such an object might be used at a specified size for LOD / QMID grid unit reference purposes, live in an FS flight during scenery development activities. :Nerd:
Glad to see things are working out well with the airport project... I think you should feel free to have fun with that right now and consider the scenery builder's crosshair project later whenever the Muse's inspiration moves you in that direction. :wink:

I'd welcome the opportunity to take a look any any beta creations related to either your KMYL airport... or any scenery development aircraft/object you might produce when the time is right. :smile:

PS: Did you place the "RotatedCall :dummy" string after each individual Nav light object, or a single one (ex: at the beginning / end) in the *.SCA file ...to achieve the FS7/FS8/FS9 SCASM equivalent of the FSX "XML" scenery object placement <NoAutogenSuppression> parameter to disable autogen suppression via the SCASM re-compiled output *.BGL for night light placement ?

Code

RotatedCall( :dummy 0 0 0 )
Jump( : )
:dummy
Return

http://www.scasm.de/...a_cmd2.htm#rcal

http://www.scasm.de/..._cmd2.htm#jmp32

http://www.fsdevelop...ead.php?t=14940 <-- See Post#1 for another autogen-sparing example of "RotatedCall"

Code

RotatedCall( :end 0 0 0 ) ; dummy call to preserve autogen
Jump32( : ) ; finished now, get outta here

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:30 | Сообщение # 22

Группа: Удаленные

I couldn't see any way around adding it to each individual light object but then I spent about 20 minutes with this. Some of the lights were assembled into strings like this though:

Code

; ----------------------------------------
; Object # 326, offset: 0xABC4 size: 518 bytes (0x0206)
;; Lat: 0004C238Ah Lon: 0AD711336h
; ----------------------------------------
Area( C N44:54:02.33 W116:05:51.40 100 )
         IfVarRange( :  028C 2 4 )
         IfVarRange( :  0346 1 32767 )
         PerspectiveCall( :L00ABF0 )
         Jump32( : )
:L00ABF0
         RefPoint( rel :  1.00 N44:54:02.33 W116:05:51.40
                 V1= 32767 V2= 1 )
         Light( m 4 -51.24 23.50 180.12
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 -50.74 23.00 180.62
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 -61.38 19.00 275.73
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 -60.88 18.50 276.23
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 90.36 10.00 -316.11
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 90.86 9.50 -315.61
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 34.12 12.00 -153.99
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 34.62 11.50 -153.49
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 -13.10 16.50 13.01
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )
         Light( m 4 -12.60 16.00 13.51
                 1065353216 0.00 0.00 CC 167 255 255
                 0.00 0.00 1.00 )

         RotatedCall( :dummy 0 0 0 )
         Jump( : )
         :dummy
Return
EndA

...which made it easy, as you can see just the one RotatedCall for the entire string. Something must have gotten lost in the decompilation however because my lights came out a greenish white rather than the traditional UT orange cast. It was easy enough to change though, the "CC 167 255 255" controls the color, I've learned. I changed every occurance to "CC 255 179 83" as an experiment and made them orange again, just a little surprised that the color was lost in the decompilation (and whereinahell did the seemingly random "167 255 255" come from?). Actually I too am a little put off with these lights because of their flickering on and off depending on your viewing angle and distance. Also there's the issue of distributing copyrighted material in the event this project ever gets thrown to the wolves. I think I'll opt for an effect type light for this scenery instead. I've actually built one already, complete with light pole using some highly modified variations of Thorsten Reichert's ramp light effects available here.

I see what you're saying, I was stuck in "aircraft.mdl mode" :smile: . I've never used one of the preview capable object placers, it should be easy enough to build the scenery model though. I'm almost certain the scaling factor's accuracy would go beyond 2 decimal places, although that'd be a tough one to verify. These scenery placement models/objects are really child's play in Gmax though, you really should fire up your copy and get into this yourself. I did the "House Tutorial" (gmaxSceneryTutorial.doc) included with the FS2004 Gamepack SDK and it really turned the lights on for me. Only takes a couple hours and you'll be well on your way to building whatever you want in a scenery placement tool. You'll probably loose interest and start pumping out all sorts of cool scenery objects instead though, I'm guessing :smile: .
Absolutely, you're on "the list" :smile: . It'll be a while till KMYL is ready for anyone to look at. I need pictures so I can make buildings and there just aren't many on the net (naturally). I'm thinking of driving to McCall over one of the coming weekends but it's 6 hrs one way and I have no idea what kind of reception a "video gamer" would get there. I wish I knew somebody in the area that was into flightsim. I did manage to find a photo of what appears to be an airport maintenance building and scratched up a quick model in gmax. I love the dent in the tin where somebody apparently backed into it:

Here's another, all I could tell from the photo was that the hangar was an off-white with a green roof and had a sign on the gables. This is the ficticous "Idaho Forest Industries hangar". Can a scenery designer take these kinds of liberties with a scenery, or do I need to be more accurate than this? Also disregard the Afcad aprons & taxiways, they're gone now, replaced by the groundpoly, but I can't say it looks any better because I don't have any of the taxiways or ramp areas done yet.

Seems we've drifted a bit off topic Posted Image

@737@

Дата: Понедельник, 01.08.2011, 11:31 | Сообщение # 23

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

I like those buildings you made; as a "low and slow bush flyer", I find that the more objects show realistic "wear and tear"', IMHO, the more 'immersive' FS becomes ! :Applause:

Thanks for the encouragement with 3D modeling... I'm already getting familiar with the capabilities of Sketchup and the option for Collada *.DEA export to be imported into FS via Arno's ModelConverterX; but I had not considered aircraft model work in GMAX quite yet !. :wink:

I'm still researching a way to use a different night light with either BGLC / BGLC_9 vs SCASM code, preferably I'd like to use light balls of the type Dick Ludowise (described as the "smallest" possible in BGLC).

I anticipate that using these "light balls" as ONLY floating points of light at all locations away from airports where I'd be on the ground, because I'd be using them at an offset above the ground without any suspensory 'light post' object, I would save on frame rate hits... and might be able to have many more of these lights populating my roads etc. with better FS performance.

But I'm not certain yet whether one can achieve a good visibility distance control in BGLC / BGLC_9 code versus XML scenery object placement code.

Hopefully Dick and/or others with knowledge of those arcane options will comment here as to how one might implement use of that "smallest light ball" for larger scenery coverage areas (involving thousands of lights) rather than using the "default" light objects which IIUC are achieved via Effects, SCASM, BGL_Light etc. as it seems that they each have their own issues as to size, visibility at a given point of view in FS.

I believe many of us would like to better understand what the displayed difference might be in use of these lights in FS:

BGL_LIGHT LIGHT_LANDING

BGL_LIGHT LIGHT_NAV

and...

Dick's "Light Point" MDLs (do these use the same default 'BGL_LIGHT' object... or are these a "new" light object type ?) :Confused:

http://www.fsdevelop...hread.php?t=629

http://forum.avsim.n...me-light-balls/

If they all use the same FS internal default "light object", can one access the same via an FS "Effect" / *.Fx file ?

For example, what would the difference be in visual appearance and performance between Dick's "Light Point" MDLs and FS 'Effects', if those "Effect lights" were displayed via XML rather than SCASM or BGLC / BGLC_9 code ? :Thinking:

Example Effect Light Placement via XML

<FSData version="9.0"
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation="bglcomp.xsd">
<SceneryObject
lat = "42.795718831249"
lon = "-70.8413330516989"
alt = "0.000M"
altitudeIsAgl = "TRUE"
pitch = "0.0"
bank = "0.0"
heading = "0.0"
imageComplexity = "VERY_SPARSE" >
<Effect effectName="fx_NavWhi" effectParams="DAWN=0;DUSK=1;" />
</SceneryObject>

</FSData>

I hope in this thread we might also identify additional options with FS night lighting for the FS Community to use ! :smile:

bar_rodoy

Дата: Понедельник, 01.08.2011, 11:33 | Сообщение # 24

Группа: Удаленные

Yes, I think you're right, this is the best way to go for street lighting. I did some testing previously using some bgl lights I'd built in gmax, attaching them as obstruction lights to other objects (hangars), but hadn't tried using them as street lights. I compiled a couple examples of Dick's code from one of the threads you linked above. I found the white lights actually had a yellowish orange cast so I changed the color to 99CCCC which is a sort of dirty-aqua color and I like the result so far. These lights are a much smaller point of light than the UT style scasm light incidentally. Only after doing some of these tests did I notice that, previously I assumed they were the same.

I used "TreePlanter" (which was pretty slick) to place 86 instances of this particular light and I can't see any frame impact whatsoever and this is running on an old Athlon XP 2700+/GEForce 7800 w/256mb system. They may be a little close together, I may go back and thin out every other one, but here's what they look like:

I don't think so, an effect is an entirely different thing using a bitmap that's stored in Effects\Texture, where as near as I can tell bgl lights utilize halo.bmp which resides in the main Texture folder (I used filemon at one time to detect what was being loaded when the lights came into view, this is merely my observation, and by no means, conclusive). Runway lights, taxiway lights, VASI, etc, I believe all fall into this classification of FS lighting which isn't the same as effect lighting. One major difference is that the bgl lights are visible at a greater distance than an effect, which is the main reason I sought an alternative to "fx_obslight.fx" for the hangar obstruction lights mentioned above. Another difference is that the bgl lights don't seem to be affected by the FS9 cloud draw order bug that causes effects to be drawn behind clouds that they should be appearing in front of. It's widely accepted that this only affects effects that are attached to objects, but from my observation it affects any effect that's placed as a scenery object whether attached to another object or not. (say that 3 times fast :smile: ) I think an effect light has (or can have) a more pleasing appearance than a bgl light from up close, so what I did on some of my above mentioned hangars was to attach the bgl light to all but the highest LOD, with LOD_100 using an attached effect instead.
Don't know about LIGHT_LANDING but LIGHT_TAXI makes a splash of light on the apron where the LIGHT_NAV is a point of light in the air. I think LIGHT_LANDING is the same as LIGHT_TAXI in this regard. Rather than halo.bmp it appears these types of lights use spotlight.bmp, which is the same bitmap the aircraft landing lights use. It's also the file that get's replaced with the add-on "Xenon landing lights" packages available in the libraries, which leads to some rather odd looking light splashes in some cases I've observed. I personally think a much nicer ground light splash effect can be achieved through use of an .fx effect, so I've pretty much ruled this type of light out for use in scenery design. Dick talks about being able to rotate this type of light up to 89.99° or something like that, which I haven't tried. That may look considerably better, I'll have to put that on my list of things to try one day.

In the meantime I've had some success in adding some semi high-res layers to my ground poly:

@737@

Дата: Понедельник, 01.08.2011, 11:34 | Сообщение # 25

Полковник

Группа: Персонал

Сообщений: 104

Награды: 0

Репутация: 0

Замечания: 0%

Статус: Не в сети

The Athlon XP 2700+ in a capable motherboard can deliver some unanticipated extra performance with a simple (conservative) FSB overclock on the supplied cooling fan.

BTW: Your GeForce 7800 with 256 MB VRAM is rated close to my old ATI AGP-8X video card; you might also be able to boost its FS throughput substantially with a optimized AGP Aperture Size, (safely) adjusted PCI latency and (conservative) overclock for the AGP video card ! :Thinking:

http://www.gpureview...d1=43&card2=382

If you'd care to try out some video card tweaks for a quick test flight (you'll see results immediately upon loading your flight), just let me know and I'll send the info to you in a PM.

Additionally I have researched some significant tweaks for FS9.Cfg that might further enhance your FS9 experience (...seriously !). :Nerd:

If you'd care to try them out via a simple edited 'copy' of your FS9.Cfg for a quick test flight (you'll see results immediately upon loading your flight), just let me know and I'll send the info to you in a PM.

Alternatively, we could connect live via 'TeamSpeak' sometime

Excellent info, thanks for sharing your insights and test results with these 'lighting' options !

Regarding an FS lighting "Effect" idea I had in mind, may I inquire as to whether you've worked with the interactive FSX Visual Fx Tool ?

I was curious if you had ever tested the Fx "Emits Light" attribute, and knew whether this invoked use of similar FS sub-system 'light objects' (such as I thought might be involved with "EmissiveBloom" and gauge objects etc.) ?

FS9 Autogen Issues

Страница 1 из 2
1
2
»