P3D v2 AGNRectangularVegetation: Using ModelEntry GUID Rather Than Grouping id?

[JRobinson]

I have some autogen near an approach path that makes it impossible to follow the 3° glideslope if I use something like Cottonwood 5-16m City and/or tb Elm1 8-18m City in that area. The trees are too tall of course, the friendly name is misleading as Cottonwood 5-16m City for example uses models as large as 30m (with a relative weight of 5). The shorter groupings are either too small and invisible or they contain "sets" which interfere with autogen buildings, roads, etc.

My solution was to decompile the autogen with agn2txt and replace the Cottonwood City GUIDs equally with a mix of the GUIDs for veg_tb_Cottonwood_12m, veg_tb_Cottonwood_14m, and veg_tb_Cottonwood_16m which are ModelEntries rather than Grouping IDs. I did the same with the Elm using similar sized models. Much to my surprise this worked and allows the 3° glidepath to be flown without the trees looking particularly strange or out of place.

You can open and edit/save the re-compiled autogen in the annotator and when you select one of the trees it simply tells you "veg_tb_Cottonwood_14m" instead of "tb Cottonwood 5-16m City". You can copy & paste these trees as well. The trees change seasons normally in the sim.

I only did this for a very small area under the approach path, there were less than 300 autogen objects involved and the rest of the PR uses standard groupings. This non-standard autogen gives me what I want in both P3D2 and FSX without need for any custom autogen descriptions.

This may have some potential too where using a specific tree size would be beneficial (you always end up with that gargantuan tree on the edge of your parking lot that hides all your vehicle placements for example), this could mean very precise control of your autogen where you need it in high detail areas of the PR, you could effectively paste exactly the tree you want almost as if placing specific objects with Instant Scenery - except they would follow the seasons.

Here are the available cottonwoods arranged in a grid from smallest to largest, all placed with the annotator, they show a fall variation in September and a winter variation in January:

I'm curious if anyone can see a problem with hacking autogen like this? ...or have we been doing this all along and I'm just now catching on?

Jim

 

[Timmo]

Interesting- Do you know if this method allows the resultant agn files to be distributed to other users and get the same result?

 

[JRobinson]

I don't know but I don't see why not, I'm using the default autogendescriptions for all the GUIDs and all the ModelEntries are default.

This works, but depending on the resolution of your PR the annotations may come out very small and bunched up or very large and spread out. Try it, copy the code from the boxes below then open a PR in the annotator, zoom in on an empty field and right click these annotations onto the PR. Make sure you have your .agn backed up before messing...

Here are the cottonwoods that make up the grid pattern in the screenshot:

ANNO:1:1:0:0.000378:0.000378:-0.009148:-0.004733:-0.008770:-0.004733:1182112969:1310482734:2669862274:766935985#1:1:0:0.000378:0.000378:-0.004596:-0.004809:-0.004218:-0.004809:1310827013:1131691862:3491332009:1614814565#1:1:0:0.000378:0.000378:-0.000043:-0.004733:0.000335:-0.004733:1105531342:1301280206:2772055955:324045623#1:1:0:0.000378:0.000378:0.004393:-0.004733:0.004771:-0.004733:178018805:1139659054:2022236837:3723301038#1:1:0:0.000378:0.000378:-0.009148:-0.000589:-0.008770:-0.000589:513766855:1199956777:3560307587:313464770#1:1:0:0.000378:0.000378:-0.004479:-0.000647:-0.004101:-0.000647:1424569835:1328125542:3983095447:1032276626#1:1:0:0.000378:0.000378:-0.000043:-0.000647:0.000335:-0.000647:2085355520:1320848087:1896978077:2960479412#1:1:0:0.000378:0.000378:0.008770:-0.004733:0.009148:-0.004733:3652889827:1118289720:1134361476:3141863971#1:1:0:0.000378:0.000378:0.004510:-0.000588:0.004888:-0.000588:2325284083:1302738262:468690563:836713194#1:1:0:0.000378:0.000378:0.008829:-0.000588:0.009207:-0.000588:71396845:1162601136:4203634351:1283176313#1:1:0:0.000378:0.000378:-0.009207:0.004431:-0.008829:0.004431:1208956759:1237445172:3715021202:4100410596#1:1:0:0.000378:0.000378:-0.004362:0.004373:-0.003984:0.004373:366548690:1256782161:2719391874:3815687079#1:1:0:0.000378:0.000378:0.000074:0.004372:0.000452:0.004372:3523276692:1297013732:3426290329:703255327#1:1:0:0.000378:0.000378:0.004743:0.004372:0.005121:0.004372:4081193605:1321961793:2416983480:2200465286#

Here's a similar arrangement for the Elms:

ANNO:1:1:0:0.000378:0.000378:0.008759:0.002717:0.009137:0.002717:2020398920:1145643888:2928600989:2305228653#1:1:0:0.000378:0.000378:0.008763:-0.002284:0.009141:-0.002284:1874865893:1141868480:1194926005:1851891833#1:1:0:0.000378:0.000378:0.004456:0.002755:0.004834:0.002755:3605609805:1217018677:1693649568:985393706#1:1:0:0.000378:0.000378:-0.000042:0.002700:0.000337:0.002700:583667916:1199915352:2022926977:1823696185#1:1:0:0.000378:0.000378:-0.004377:-0.006379:-0.003999:-0.006379:2292615598:1166579087:1208747400:1033014702#1:1:0:0.000378:0.000378:-0.004396:-0.002288:-0.004018:-0.002288:3122901155:1138127432:2034826647:3798616052#1:1:0:0.000378:0.000378:-0.009148:0.006014:-0.008770:0.006014:3612369718:1114076496:1664689565:3035195692#1:1:0:0.000378:0.000378:-0.009148:0.002730:-0.008770:0.002730:2095905684:1323016627:1362096802:3358026052#1:1:0:0.000378:0.000378:-0.009142:-0.002297:-0.008764:-0.002297:4166621555:1229494892:3526198696:1948107887#1:1:0:0.000378:0.000378:-0.004379:0.002740:-0.004001:0.002740:3570085455:1327531093:1871933607:2432677414#1:1:0:0.000378:0.000378:-0.000038:-0.002277:0.000340:-0.002277:2261123214:1118815735:1664785064:322922636#1:1:0:0.000378:0.000378:0.008770:-0.006392:0.009148:-0.006392:3549689958:1117276711:1637408172:4212129187#1:1:0:0.000378:0.000378:0.004401:-0.006373:0.004779:-0.006373:3211228605:1083463125:1669964711:3874084602#1:1:0:0.000378:0.000378:0.004452:-0.002291:0.004830:-0.002291:285645948:1276157488:225521537:3243938979#1:1:0:0.000378:0.000378:-0.000039:-0.006387:0.000340:-0.006387:498727168:1188122280:2187320709:1186866312#1:1:0:0.000378:0.000378:-0.009147:-0.006375:-0.008769:-0.006375:1229875613:1100046174:3566127493:1051366939#

Still working on singling out a few more tree variations, that's all I have done so far.

 

[arno]

Hi Jim,

I see no problems with this. You can indeed assign the GUID of an individual vegetation entry, but also the GUID of a vegetation group. Both are supported by the autogen.

Same goes for the roofs. You can assign a specific one or a group.

In most cases a group is better, since it will add some variation and therefore a better result. But in the kind of case you describe, where you want more control it makes much more sense to place specific models indeed.

 

[JRobinson]

I appreciate your input Arno and I'm pleased to hear that it won't make my terrain.dll explode or something. I didn't know you could do this with roofs as well, that might be interesting for doing housing developments where large groups of houses all look basically the same. At any rate this certainly opens up a lot of possibilities, especially if a person wanted to get into making custom autogendescriptions and adding some ModelEntries of your own. Thanks very much for the AGN tools BTW, I've used them to do all sorts of things with autogen that would otherwise be impossible - or at least a heck of a lot of work.

Jim

 

[GaryGB]

Hi Jim:

In response to the very interesting ideas in the OP of this thread, as well as a more recent thread on related topics ...here:

http://www.fsdeveloper.com/forum/threads/installing-custom-autogen-configuration.428760/page-3

http://www.fsdeveloper.com/forum/th...togen-configuration.428760/page-3#post-679071

Sort of off topic for this thread but yes I've been using this approach a lot, most of what's seen around houses in my Inverness thread have been annotated this way while I still use the groupings and larger veg rectangles for the outlying areas without houses. One complaint we often hear is "the trees are too big and they dwarf the houses" so this is a good solution for that problem too. I haven't found a way in the annotator to use a ModelEntry GUID directly, only regionalizations or groupings. Once you've hacked at least one autogen tile however, it's possible to copy & paste these specific vegetation objects in the annotator just like anything else (I use tiny veg rectangles BTW which represent just a single tree as opposed to polys).

Additionally it's possible to select/copy the veg rectangles in the annotator and paste them into Notepad as text. This can be saved and used on other PRs although sometimes depending on the resolution and size of the PR those annotations don't necessarily retain their size and spatial relationship with one another. It's possible to set the GUID in "S" (select) mode by simply selecting one of the individual trees and then switching to vegetation mode (V) and drawing some new veg rectangles to copy & paste - the new veg rectangles will retain the GUID. This is a way around the size/spatial relationship problem with saving as text although not exactly elegant, lol.

I've done most of my recent annotations with the P3D2 annotator incidentally, it seems to be no different than the FSX annotator with regard to the ModelEntrys (or anything else for that matter) and the resulting autogen seems to work fine in FSX.

Jim

...I'm curious if you've seen Post #165 et seq. in a thread on use of BGL files instead of AGN files to place 'specific' vegetation object GUIDs ?

"...take each object and store its GUID.
Then browsing autogendescriptions.xml locate this GUID.

If it is a <ModelGUID> transfer directly into the xml text of the future bgl
If it is a <model Entry> <ModelGuid> identify the first object.
And transfer the xml text of the future bgl."


http://www.pilote-virtuel.com/viewtopic.php?id=49568&p=7

Google Translated version:

http://translate.google.com/translate?hl=en&sl=fr&u=http://www.pilote-virtuel.com/viewtopic.php?id=49568&p=7&prev=/search?q=FSX+%22ModelEntry%22+GUID&client=firefox-a&hs=eRE&rls=org.mozilla:en-USfficial&channel=nts&biw=1245&bih=622


I'm not sure if the OP of the thread at FSDeveloper gave sufficient info for Arno to respond to which would have otherwise conveyed the ideas under discussion in the original thread linked immediately above; at that time and in that context, Arno's reply seemed rather "categorical" in nature based on that perhaps much too limited info given by "JPP":

http://www.fsdeveloper.com/forum/threads/agn2bgl.344006/

I found the ideas under discussion in the above French forum thread rather intriguing, however, so I thought it might merit further exploration and perhaps objective quantitative testing.

[EDITED]

AFAIK we have the option to use BGLComp scenery object placement for "small" numbers of vegetation objects (ex: trees) when we do not need (or want !) the inherent "randomizing" associated with object placement via the AGN file methods.

But to disregard issues of randomization in Autogen placement, perhaps use of BGLComp placement methods may not be necessary to achieve AGN placement of specific objects ...if I correctly understand Arno's description of another option:

http://www.fsdeveloper.com/forum/threads/agent-use.424849/#post-627631

Autogen library objects are not placed by calling one object directly. Instead you are calling a class as defined in the default.xml file. Many of these classes contain multiple library objects and in that case FS will pick one of the them. You can't influence which one. If you want one specific object, you would have to make sure it is in a class with no other objects.

Details on methods to implement autogen "classes" via those methods is discussed further here in the context of the FS2004 Autogen SDK docs:

http://www.fsdeveloper.com/forum/threads/agent-use.424849/#post-627664

...which IMHO is a "must-have" to supplement the info in the ESP / FSX Autogen SDK Docs:

http://msdn.microsoft.com/en-us/library/cc526979.aspx#Tutorial_AddinganewAutogenclass


But, I'm still wondering if, in your experience and/or to your knowledge otherwise, when we have enabled draw call batching and/or used MIP-Maps, LODs, etc. to create efficient, 'pre-sized' vegetation objects compatible with both AGN placement and BGLComp placement methods, is there really a substantially adverse FS run time performance difference when "somewhat larger numbers" of Ex: trees are placed via BGLComp-compiled secnery library object 'placement' BGLs ...instead of via AGN 'annotation' files ?

Although I recall seeing Arno state that earlier versions of the Netherlands scenery project (previously) had encountered major performance issues when 'country-wide' quantities of vegetation and/or buildings were placed via BGLComp rather than via Autogen methods, for purposes of this hypothetical 'test' scenario, I am describing a situation where only a 'smaller' number of quads are rendering ex: Trees via BGLComp placement ...within the reported approximately 14 Kilometer / 7.559376 Nautical Mile "Autogen visual display radius" surrounding the user aircraft.

IIUC, using FS QMID Grid quad sizes, one's "Autogen visual display radius" calculations might actually be:

(14 LOD-13 quads) x (1,223 Meters per X or Y axis quad span) = 17122 Meters

17122 Meters = 9.24514 Nautical Miles (at a "theoretical equilateral quad area" on the FS spheroidal QMID world model).


BTW: Additionally, as I endeavor to learn more about what we may- or may not- be able to do to further enhance our scenery with the various FS Scenery SDK methods, I noticed that the term "ModelEntry" was used in the Living World SDK in association with "Configuring Surface Vehicle Traffic", and again in a context of a rendering engine function intended to "randomize" object display for "Surface Vehicles":

http://msdn.microsoft.com/en-us/library/cc526977.aspx

I am curious if you may be aware of a way, not via calling a "class" as defined in the default.xml file, but instead via Ex: attributes for Autogen objects with specific ModelEntrys / Model GUIDs in *.XML and/or *.SPB files, to disable "randomization" for rendering of those specified objects ?

Possibly this might be achieved by increasing the "weighting" of the object(s) attribute for display at run time (...in a manner comparable to that of the methods used for "Surface Vehicles"), such that randomization for specified Autogen objects is effectively "disabled" even though display is taking place via an inherently "randomizing" rendering pathway ?

[END_EDIT]


Thanks in advance for any additional insights you might share on this topic.

GaryGB

 

[JRobinson]

Hi Gary, I'm not sure if I'm grasping completely the "jist" of that thread, apparently the AGN merge tool is capable of converting AGN coordinates to Lat/Lon to output a placement XML that can be compiled with Bglcomp? This person has then substituted some GUIDs in order to place specific trees rather than the random selection the annotator provides? My French isn't so good and neither is google's apparently, I find the thread a bit difficult to follow, lol.

What I have done (experimentally) in the past is place trees from vegetation.bgl with IS2. IS2 has a copy/paste function where you can copy a group of placements, say a group of 100 mixed trees. It's impressive really, you paste this group of trees, they appear as a group but behave as a single object, you can rotate and move this group collectively as with placing any other object with IS and then finalize the placement with a click. You can fill in a large area rather quickly, performance (once you kill IS2 and restart the sim to restore drawcall batching) seemed OK although I didn't do any tests to compare performance with AGN placements - I suspect there is a penalty. The larger problem of course is that the trees don't follow the seasons. You can get around that by requiring the end user to select a season through a control panel of sorts where multiple .bgls containing different variations of the trees could be swapped out depending on the selected season. The end user will complain profusely about having to do that however .

IMHO large area vegetation coverage with BGL placements is not a viable alternative to AGN, a tree placement here and there to fill in areas where autogen gives unpredictable results and seasonal changes are minimal might be OK.

Jim

 

[GaryGB]

Thanks Jim !

FYI: I had clicked on the "submit" button prematurely when originally composing this message, so since your original reply, my post above now shows added content from the "post-haste edits" I'm notorious for on FS forums.


I'd welcome any further insights you might share if / when you have some time to look over my additional questions above.

GaryGB

 

[arno]

Hi,

I agree with Jim. Bgl placement is not a good alternative in most cases. It will affect the performance much more than autogen when you cover big areas and you don't have seasons.

 

[GaryGB]

Thanks, Arno.

I suppose the rest of my inquiry might best be the subject of another thread elsewhere.

So when I find a more appropriate venue, I'll consider transplanting and reformulating my post above, in the hopes that might encourage some additional input and gaining of new insight on options to place scenery objects with greater control over display without randomization, while also minimizing impact on scenery rendering performance.

GaryGB

 

[JRobinson]

For my own purposes I can't see where a person really needs greater control without randomization, using the ModelEntry GUIDs in the annotator gives you more or less the same control you'd get in a placement .bgl.

Shortly after I posted this thread I decided I needed a "palette" to copy from in the annotator so I created "Autogen Park", which is for all intents & purposes a bogus 30cm PR with a bunch of tree labels on it that I annotated with ModelEntry GUIDs in the annotator. I didn't finish it yet (may never), as it turns out the Oaks were so friggin huge the autogen engine apparently didn't want to draw them so close together, some of them were no-shows, I need to modify my "PR" and spread them out a bit more, but otherwise I was able to precisely place the tree I wanted near each label, here's a shot:

EDIT: They change with the seasons (the PR doesn't, lol):

 

[GaryGB]

Thanks, Jim ...that's an excellent idea !

Although since FS2002 there have been (very few) visual guides to land class and scenery objects using (small) screenshots of individual areas and/or objects made available by generous folks in the past, your "approach" to showing an overview of autogen object groups together for comparison in context here is extremely helpful.

I'd welcome the opportunity to navigate through such a helpful "Arboretum" in a 3D FS scenery or a 2D document of screenies if you ever were to make it available to others in the FS development community.

If this type of "scenery" were available as a 3D learning resource / reference guide, I could use 1 of my 3 monitors with another separate computer running an extra copy of FS with saved flights of strategic camera viewpoints centered on each Autogen group by category name and size, so one can "jump" there to view the object during a slewed flight session.

I can already see myself out for a scenic drive through a "FS-Arboretum" in the Crosshairs+ aircraft muttering: "Home, James... and please go through the 'Autogen Park' !

GaryGB

 

[JRobinson]

Couple of developments on this, as Arno mentioned in post #4 you can also use specific RoofEntry ids rather than groupings for your AGNGenericBuildings just as you would use a ModelEntry id for AGNRectangularVegetation. This lets you specify the exact roof you want for each house. This works well when you annotate houses that aren't square or rectangular so maybe you'll make the house actually from a couple buildings intersecting one another at right angles, in that case you can specify the same roof for each which makes the house look a bit more unified. Here are a couple of my "luckier" examples:

Annotating trees using a ModelEntry id is fairly easy since you can hack some autogen and then copy & paste tiny veg rectangles that basically represent a single tree but when using the RoofEntry ids each house needs to basically fit the footprint on the photoreal so copying & pasting doesn't work. I've found that you can select an existing house by drawing a selection marquee across it then hit "B" for building and the new building you create will inherit the GUID of the previously selected building. That worked but it was a pain and I found myself panning all over the PR trying to find the building I wanted to give the annotations some variety. Finally I decided a hacked RoofDescriptions.spb was in order so I made one up specifically for annotating but not for use in the sim. I made custom groups for each of the available default RoofEntry ids and gave each one the GUID I ultimately wanted to end up with, then I replaced all the RoofEntry GUIDs with random ones. The idea is you annotate with the hacked RoofDescriptions.spb, then when you run the annotations in the sim using your normal RoofDescriptions.spb (or any RoofDescriptions.spb as long as it still contains all the default descriptions) the GUIDs from the hacked groupings become the GUIDs for the individual RoofEntry ids. It worked, lol. The end result is custom annotations without the need to supply custom descriptions. As long as the big name scenery developers always include unadulterated default descriptions in their supplied custom decscriptions there's no way this can get messed up by any FTX Central setting for example on the end user's PC.


Lastly here's a hack I just finished up on some vegetation. As you can see in the first screen the trees virtually hide all the building annotations. I set up a couple dummy scenery folders, one where I removed all the outlying annotations keeping only the city area and another where I inverted everything keeping the city area annotations and deleting the outlying areas. I decompiled the city area .agn files and did some massive GUID replacements to remove all the "tb Cottonwood 5-40m ALL" for example replacing them with an assortment of veg_tb_Cottonwood_12m, veg_tb_Cottonwood_14m, veg_tb_Cottonwood_16m, etc. I did the same for tb Elm1 8-18m City, tc Douglas Fir 5-25m City, tb Cottonwood 5-16m City, etc. I then appended the agn for the outlying areas into the hacked files which put them all back just as they were before I messed with anything. Here's the result, note the taller more voluminous trees surrounding the city remain intact yet you can now see the building annotations much better from a low angle.

Jim

 

[ollyau]

I made a GIF comparing the two screenshots for you.

 

[JRobinson]

Heh, levitating trees . Thanks!

 

[whitav8]

Jim,
I tried your Annotator "script" for the Cottonwoods and Elms - terrific! Could you please create a similar script for some houses and or small buildings? Also, could you explain the elements of these Annotator scripts in terms of positioning so I could make some myself - I guess the key is to make one yourself in the traditional way with Annotator in an isolated area, then use the agn2txt tool, edit that and then you can just paste the script. Am I correct?

 

[JRobinson]

Those "scripts" are merely what you get when you copy something in the annotator. Try it, draw a rectangle around a bunch of trees in the annotator, press Ctrl+C and then open up Notepad and paste what you copied. Save the Notepad doc as text then open it back up one day and Ctrl+A, Ctrl+C the entire document, start the annotator and paste them onto a photoreal. That's all I did to get the scripts I posted above. The positioning in that case means nothing to anything but the annotator which ultimately writes the FS positioning into the .agn files. To get that info yes, you'd need to decompile the .agn with agn2txt, I'm afraid Arno would have to help you decipher agn2txt's output, I think positioning is relative to the upper left corner of the autogen cell but I don't understand the numbers.

After refining this technique a bit my conclusion is that saving these tree varieties to a txt file as a "palette' to paste into the annotator isn't the best way to go about it. It's much easier to simply annotate with the hacked AutogenDescriptions.spb and RoofDescriptions.spb, more details of the hack in post #13 above.

So here are my hacked descriptions:
jr_hacked_agndecsriptions.zip


...and here's the "help file", lol:

You don't run these hacked descriptions in your sim, you only annotate with them (although I can't think of a reason they wouldn't also work in the sim). Basically the hacked descriptions do nothing but give you a Grouping id you can select to annotate with, the hack is that the GUID of that Grouping id embedded in the .agn file becomes the GUID of a ModelEntry or RoofEntry when you run the autogen in the sim using normal autogen descriptions.

Only AutogenDescriptions.spb and RoofDescriptions.spb have been modified, everything else is default FSX/Accel but I included them since you'll need the complete fileset to annotate with. These work for P3D v2.x as well IIRC.

Don't overwrite anything, make a folder in "Microsoft Flight Simulator X SDK\SDK\Environment Kit\Autogen SDK" named "hacked descriptions" and extract the .zip file there. When you start the annotator rather than open the usual "Microsoft Flight Simulator X\Autogen\AutogenDescriptions.spb" with the Autogen Configuration Editor, navigate to the "hacked descriptions" folder and open the hacked AutogenDescriptions.spb instead. Do the same for RoofDescriptions.spb.

You'll find new groupings available like "JR_veg_tb_Cottonwood_10m" and "!JR_Roof_Gabled_03" which are essentially Grouping id's made using a single ModelEntry or RoofEntry. All existing default groupings are still available, haven't been modified, and you can still use them to annotate with normally. The hack is completely additive and all hacked Grouping id's are prefixed with "JR_". These began life as default FSX/Accel and include no 3rd party descriptions which means you can annotate with whatever you like without worry that you're using someone's copyrighted descriptions.

When you annotate veg rectangles with these hacked "JR_" groupings they should be small enough to represent a single tree, the idea is you use them around houses or anywhere shorter trees are desired. If you annotate large veg rectangles or polys with these groupings you'll end up with large areas filled uniformly with exactly the same tree! Use the default groupings for the larger areas instead, they will give some variety.

The main purpose of the RoofDescriptions hack is to allow you to specify exactly which roof/gable textures an AGN building should have, the wall textures unfortunately are still left to chance. See post #13 above for more info/screenshots.

The RoofDescriptions groupings prefixed with "!JR_" seem to make proper use of the gable textures where the groupings lower in the list prefixed with simply "JR_" did not. You should set up a test somewhere laying out each grouping type numerically so you know that the building in the fourth row, 2nd from the left is "!JR_Roof_Gabled_08" for example, take some screenshots for previewing. Note that these building textures are all subject to changing depending on which addons an end user might have installed

Jim

 

[whitav8]

Jim,
Thanks much for your concepts and your documentation. I did discover that Copy/Paste ANNO_txt by happenstance - it is really quite useful in that once you make a pattern for a neighborhood, you can now reuse it easily. The only problem I had was figuring out where the copy was going to be positioned precisely when I do a paste (not sure where to put the mouse).

Thanks also for the altered Descriptions files. I think you have added quite a lot of capability to using Annotator - your own sceneries are terrific. I tend to make Photoreal airports using FSEarthTiles a lot and I have tended to just use Instant Scenery to try to populate the buildings and trees. I feel that I can now use Annotator to help that effort - thanks! I certainly hope that all third party photoreal providers finally decide that there is a tremendous need for annotation - I fly in helicopters and 3D elements are critical - flat imagery just looks awful at 500 feet. Obviously, they need automation for that similar to the efforts by Arno and others (VogelTree,etc)

One thing I wish we could control better is just how much of a given Autogen area we get with less than VERY Dense settings. I like to run for performance sake(I have three monitors - in P3D) with lesser Autogen settings and with just Dense, I get a very small percentage of the Annotations I just created.

Thanks again for telling us your findings!

whitav8 (Dave)

 

[JRobinson]

The only problem I had was figuring out where the copy was going to be positioned precisely when I do a paste (not sure where to put the mouse).

Once you've copied the annotations from the notepad doc and right clicked them onto your PR they should all be yellow (selected), hold down your Ctrl key and you can move the group collectively into position, that way the mouse click won't be so critical.

I agree it'd be nice if you could specify an autogen density in properties like you can specify complexity with .bgl placed objects. It always seems to be the buildings you'd least like to see disappear that go first when you start turning down the autogen slider. I make a lot of generic models in gmax to replace autogen just for that reason.

Thanks for the kind words

Jim

 

[GaryGB]

Hi Jim:

Excellent info... many thanks again for sharing your insights here !


BTW: While researching some links for another interesting "Autogen" thread, I 're-discovered' these threads, which offer additional related ideas:

http://www.fsdeveloper.com/forum/threads/anyone-experimented-with-autogen-xml-codes.747/

http://www.fsdeveloper.com/forum/threads/how-to-make-autogen-buildings-with.805/

GaryGB