Sign in to follow this  
arno

Autogen Exclusions

Recommended Posts

Hi all.I thought it might be a good thing to discuss how autogen is excluded by different design aspects of FS2002.=========================Gerrish Gray had some good suggestions for this thread... so we don't get too far off track. :)"You should emphasise that any testing needs to be done very carefully, only changing ONE thing at a time and making sure that the observation is repeatable when FS is shutdown and restarted." - Gerrish GrayFS2002 autogen sometimes has a nasty habit of not regenerating upon the addition or removal of some addon scenery. The only reliable way to insure you are actually seeing autogen supression is to exit the sim and restart it. This forces a generation of the autogen each time. You may need to: 1) activate scenery, 2) exit and restart, 3) observe, 4) deactivate scenery, 5) exit and restart, 6) observe.A slow process, but necessary, as sometimes autogen doesn't disappear until we deactivate scenery.By limiting and simplifying the attack on the autogen, and making sure we go one step at a time, we should be able to find the exact elements that exclude these guys, and can speed the process of discovery.As Gerrish also requested:This is what MS has revealed to us about autogen exclusion:"Autogen prevents automatically generated objects from overlapping custom-placed objects, but it cannot prevent building footprints for autogen objects from intersecting with one another." - 'Using the Autogen Annotation Tool.doc' from the Autogen SDK.That's not a lot of info, but it does give us the reason autogen should, sometimes, be excluded... so they don't interfere with other design elements.==========================I expect we'll get into our usual arguments over this. :) But if we stick to repeatable experiments ( I'm often guilty here ), and make sure we always restart the sim after activating and deactivating the scenery, we can probably keep on track. Hopefully, we can nail down some autogen exclusion rules, so we don't all need to reinvent the wheel in coming months. Also, if we get FS2004, we'll be able to measure new changes in autogen behavior more quickly.We need to look at different types, sizes, and shapes of objects. Runways, both the newer FS2000 style and the older style. Different types of ground polys and textures for them. Flattens, both the newer LWM and the older Area16 flattens. Excludes. And both flatten and exclude entries in the scenery.cfg file. VTP polys and lines. LWM watermasks and landmasks. CUSTOM ( photoreal ) bgls. ( I'm sure there is more...)Simple experiments will help. We should probably get used to the idea of attaching SCASM or ASM code to posts, so the thread doesn't get to large to read.==========================Leave no stone unturned... and expect challenges to your findings, even if it seems obvious to you. Try to find the "nugget" of what is actuually causing the exclusion in the scenery. "Cures" should be discussed if found.The end result may become an Autogen Exclusion SDK, posted here at AVSIM, to preserve the findings if they are significant. Dick

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi Rhumba!Nice idea and a topic worth of discussion. I will pay attention to my work and to autogen; I rarely want to exclude it. But for sure I can confirm 2 things that make exclusion:1. old style roads, rivers and railroads2. this is not always happennig but I observed it sometimes; too big scenery area defined in FSSC (and Airport and so on...).Regarding VTP lines (roads for example); I have seen trees on roads also even though I use mainly 2 layers for them: 31 for minor roads and 32 for major road.But I promise, I will look closer for the VTP lines and autogen.Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.netP.S: Did anybody ever wondered to make some scenery design tutorial book of all our findings?

Share this post


Link to post
Share on other sites

>P.S: Did anybody ever wondered to make some scenery design >tutorial book of all our findings?:-lol I think no one here as the time (or is willing to spend all that time) on collecting all the info and making some sort of book out of it.But it is true that a lot of useful information is stored in this forum. When I get back in the Netherlands I'll try to update my website with more tips (and things we found out here). But of course that can never cover all things found here.....Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi Dick,>1) activate scenery, >2) exit and restart, >3) observe, >4) deactivate scenery, >5) exit and restart, >6) observe. I was just thinking a little bit about the procedure. Wouldn't it be faster to do something like this?1) Go to the error without any extra object and make a screenshot of the situation.Then for every change in the new file you make with the additional objects2) make the new BGL with changes to whatever parameter you might think that has an influence3) (re)start the sim4) observe and compare with the screenshotThis way you wouldn't need to activate and deactive everytime, only the restart is enough I think.Also I think the human memory (with the help of a screenshot maybe) is enough to see if autogen has gone or not and then you don't need to deactivate and observe after it again.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi Arno.I think you're right in that, if we have an active entry in the Scenery Library, then the restarting of the sim should be enough. So we can leave it at that, unless we run into problems.Perhaps we should reserve a separate project folder, with twin 'scenery' and 'texture' folders to hold the experimental BGL and textures? Then they won't mix with the rest of our sceneries. Then a simple cold restart of the sim, before observation, should be enough?============Also, I know we're not scientists. So we are going to be making some generalizations, like Goran has above. That's fine.. but that will lead to challenges if other simmers haven't seen this.Another thing I've noted. If we try to give specific examples, other factors may enter the mix. I realised I have the AutoGenius AGN set. Others may have Gerrish's AGN texture sheets. So there will be some differences.Let's accept an allowance for a generalization, as long as the poster is willing to support his view, in light of a challenge, with a specific SCASM or ASM file... and we can keep in mind some differences we have by using "mods" in the sim.Dick

Share this post


Link to post
Share on other sites

Yes, I agree. I was just trying to make sure we all worked in a similar way, to make the comparison easier.I am planning to use my normal test area for the tests. That is N40 W40 and it is a nice piece of ocean, where no other scenery is close (only water) so nothing will disturb me :).I think I will add a little LandClass file that will plant a dense forest there (don't aks me how they grow in the salt water :-lol) and then I can place all sorts of polygons and other objects there with SCASM and play with the parameters to see what has an influence on my nice forest.I'll start playing with it this evening :).Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi Goran.AS I wrote above, generalizations are OK. But, expect a challenge if someone hasn't seen this before.Your point #2:"2. this is not always happennig but I observed it sometimes; too big scenery area defined in FSSC (and Airport and so on...)."Do you mean too large an area, as defined by the HeaderBounds? That should be simple to check... just place 4 objects greatly separated from each other under one expansive headerbounds, say 10* each direction, and confirm the autogen exclusion. If it doesn't happen, then the size of the area enclosed by the HeaderBounds doesn't cause the exclusion of the autogen... and that answer lies elsewhere in the code.===============I agree I've seen the older-style roads, rivers, rails will exclude autogen.My past experience is that most newer-style runways will exclude autogen 1:2 lengthwise ( half the length of the runway, added onto the end of the runway each direction ). Width normally is about 12:1 ( 12 times width excluded to each side ). I will need to check the widths with different lengths, and see if the ratios change.I made another obsevation about the newer-style runways. I made a runway with a width of 1 foot. No exclusion of the autogen I could detect, in any direction... I'm going to expand the width until I see some pattern, and find a width at which I start getting the huge width exclusion. The exclusion is generic vegetation and AGN buildings.I'm suspecting the old-style roadlines also exclude according to width... but at what ratio? And is there a 'trip switch' at a certain width, like the runways?Dick

Share this post


Link to post
Share on other sites

Hi all.Here's a simple exclusion of autogen caused by a runway. For the test, I settled on a size not too uncommon... although I varied sizes and locations in my testing.I'm attaching some code that places 2 very simple runways in the Chicago area.Here's what I've found:From the center point of the runway, expect an autogen exclusion of 2x length of runway, by 6x width of runway. Runways under 10 feet wide will show little disturbance of the autogen, and 1 foot wide runways are possible, with no detectable autogen disturbance. Invisible runways ( surface type of -1 ) still exclude autogen.-----------------If we find types of traditional ground polys that don't disturb the autogen, and if smoothing doesn't disturb autogen, we should be able to construct runways with great control over the autogen exclusion... by using thin invisible runways, with polys over them to paint the surface. I don't yet know the effects of exclude commands needed to exclude default runways, and what effects that will have on autogen.Dick

Share this post


Link to post
Share on other sites

Hi All. First, Thanks Dick for starting a new thread, since Tosh's 'bombshell' was getting very saturated :-). Second, where do you guys get the time to do all this excellent testing and responding to the tasks-at-hand -- I'm retired, 71.66 yrs old -- but still have the responsibilities of keeping peace with the wife and other family matters, keeping up with the yard work, etc, and not only that but my brain is noticably slower :-(. Since positive control of AGN (along with elevated hardened surfaces like helipads) has been a 'sort-of' passion with me, I also want to, as best I can, participate in nailing-down the conditions that kill AGN. I've got a couple of suggestions.1. In the early phases of the investigation, limit the testing to one specific area such as the '40/40' area Arno proposes. However, a possible objection to this I can think-of is that such a 'Virgin' scenery area made of all add-on objects might not yield a true-condition test of MSFS scenery areas. Therefore, it might be more objective if a 'challenging' scenery area already existing in the sim be the area limited for testing. Then, expand to specific add-on-only testing.2. Designers fluent in BGLC might investigate and contribute BGLC equivalent coding vs SCASM 2.88 for comparisons.'Just a Thought....J.R.

Share this post


Link to post
Share on other sites

Hi Rhumba!

>>Do you mean too large an area, as defined by the HeaderBounds?

Exactly! I prefer to use FSSC so maybe sometimes my terms are or will be a little bit in this way. Anyway, in FSSC You can define scenery area by using window "Scenery properties" and if set to large, then You may expect some reduction in autogen.Regarding old style roads. Wow, what a magnitude this has! I have made LJLJ airport (You can download FS2000 version at my site) and placed some more important roads around, widths were around 8 metres. And the exclusion was not only few metres sideways of the road but few hundreds of meters!!! Quite a lot.Regarding new VTP lines I should do more checking in the nearest future but I remember that I saw also trees on the VTP roads.Well this is off topic but when speaking VTP roads I just saw something interesting yesterday. It seems seasons.bgl effect whole LOD13 cells because I just layed down one road going to the hills (well mountains in real life in Slovenia) and when one LOD13 cell turned to another the road clearly turned its colour from greyish to white. My FS was set to April and on hills You could see also snow. Okay, this was just for intermezzo :)Arno and Rhumba, You were saying that You will have problems to test Autogen due to some other autogen textures. Well I propose that we test everything in some dense autogen populated area, let say Niagara falls or some USA city? Shall we define a test area somewhere there? And yet another thing. I have Athlon 1700XP with 512MB RAM, GF3 Ti200, Win XP. You certainly have different computers.. But I wanted to say, even though I could have FPS to unlimited I have locked it to 20 FPS just because of autogen. My mountains and hills are quite dense populated with autogen trees so I would also recommend to check this setting. Locking below 16 FPS will be clearly seen in FS, setting around 20-25 FPS is good setting. Too high setting will lower autogen because spare time for drawing autogen will be used for other things.Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Hi J.R.Arno might find he'll need more than one area, as Latitude may need to be checked for their effects as well. I made runways in Northern Russia, Chicago, Austria ( small town with nearby woods ). All measurements were roughly the same irregardless of the latitude or autogen type ( AGN or hardcoded vegetation ). Exclusion distances for runways are lengths ( meters or feet ), not degrees of longitude and latitude. The centerpoint of the autogen seems to control at what distance it is allowed.I measured distances by a Cessna C172SP Skyhawk ( has an 11 meter wingspan ). I also set slew movement by tapping the uparrow key 15 times at a certain topdown magnification, and timing the distance of the runway length, and the end of the exclusion of the autogen!A little crude, but it worked. I was looking for a ratio, and that is easily obtained... I didn't need the actual distance.I think we'll get some surprises about autogen exclusion, and how to control it.For example, I know you use invisible runways with helipads, as well as area16n type flattens for the base of the building to suppress the mesh. What are the effects of those on the autogen? Check them without the building object, as well. How big is the flatten under the 'floating' runway need to be ( as long as you're looking at it )?----------I really hope Christain Stock gets his decompiler published soon, as we'll then be able to study BGLC code very easily. I have an earlier version I sometimes have used, but it is much more limited than his current version. I can't distribute what he gave me... it's Christian's, and it's not for general use. He has stated he may have a small charge for it. ( It has been a 2+ year labor for him ).Lately, I don't use it much, as SCASM can handle 95% of our needs... and will even allow us some math shortcuts ( see the text attachment of my runway post... I let SCASM convert meters to feet! )BGLAnalyze does a pretty good job of decompiling most code, as well.If Manfred ever adds TDF polys and lines to SCASM, I doubt I'd ever use BGLC... the output ( actual machine code BGL ) is the same, no matter what is used to make it.SCASM does have some limitations... only one latrange... difficulty creating true macros that pass a variety of parameters....-------------As to where I get time? I'm lucky enough to currently have a paid leave of absence. Kids are grown up. No longer married, but have a very busy girlfriend. At 50, I'm getting a little slower, but I have a great curiosity for scenery design... wanting to know how it's done. I don't care much for TV... 200 channels and nothing to watch.. and NFL football is done for the year!Dick

Share this post


Link to post
Share on other sites

Hi Goran.I don't think texture sheets or AGN sets will have a lot of difference, as long as we don't try to split hairs... like determining exact meters of exclusion, or duplicating screenshots.My system is much like yours, only I have a newer Radeon 9500Pro, so all my scenery sliders are able to be on full, and I keep FPS Lock at 24.----------I'm attaching a BGLPlacer CSV file ( for something different ). It's renamed as a text file, for AVSIM attachment purposes, and that's fine... just drag'n'drop on the last version of BGLC. I double checked with a decompiled SCASM file produced BGL, and it's the same.The area covered is huge. 4 identical Library objects:N50* 0.000' W100* 0.0000'N50* 0.000' W80* 0.0000'N30* 0.000' W100* 0.0000'N30* 0.000' W80* 0.0000'When I activate the scenery, it wipes out a lot of autogen in the Chicago Area.... But if I restart the sim, after activating it, all is well.. and the objects are fine, with autogen surrounding them as expected, and Chicago is repopulated.You may have been bitten by the designer's autogen curse... we have to restart the sim to see how autogen really behaves.Huge areas in the BGL make no difference with autogen.Dick

Share this post


Link to post
Share on other sites

Back Again Dick; RE:>>For example, I know you use invisible runways with helipads, as well as area16n type flattens for the base of the building to suppress the mesh. What are the effects of those on the autogen? Check them without the building object, as well. How big is the flatten under the 'floating' runway need to be ( as long as you're looking at it )?<<**Dick, I've tested these conditions fairly extensively, leading to the following conclusions:-- The Area16 flattens need to be as large or larger than the bldg, else the ivisible rwy literally will 'suck' the terrain up to the altitude of the invisible rwy,

Share this post


Link to post
Share on other sites

Here are my results from last evening.More details with all SCASM code and a lot of screenshot (don't click with a slow modem thus) can be found here:http://home.wanadoo.nl/arno.gerretsen/autogen/oldpoly/I have been looking at the effect of a old style SCASM polygon on the autogen (so not the FP ones).I have found that normally the autogen is excluded in the rectangular shape that just fits around the polygon. v2 value, Poly or StartSurface/EndSurface, ConcavePoly, LayerCall or not all didn't have an influence.Then I added two polygons. When they are both in the same Area and RefPoint then the autogen is excluded in a rectangular fitting around these two polygons.So I tried to add a seperate RefPoint for the second one, surprise, now the autogen is not excluded for the second one. If I give the second one also its own Area then it is excluded again (see the pictures in the link above).So this makes me conclude that, for polygons, autogen is excluded around everything that is in the first RefPoint of an Area block. For all further RefPoints no autogen is excluded.I'll continue more tests (I just think that an empty RefPoint in the beginning might save autogen at all (???)). Also I haven't tested if it is valid for other types of objects. That's for the further tests :).Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Wow Arno!I can say that I am a little bit surprised. I thought that Area() block will make exclusion but using two refpoints and the second will not exclude autogen.. interesting.So I persume, that if FSSC/Airport/Groundmaker would use only one area for groundpolys/roads/rivers and refpoints only to start each of the object, we can see also trees on the roads&polys :)? I must make a test also with roads, I think this test should be quite interesting!Oh Arno, can You please make snapshots by the day so the trees could be more obvious?Best regards,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Hi Goran,They are by day :). Only I forgot to remove the texture folder in my new landclass scenery map, so therefore the texture didn't load. With the forest texture displayed on it they are even worse visible :). So I think this is the best it can get (it was clear enough for my).I know that Airport indeed uses a single Area and RefPoint for each polygon. FSSC and GroundMaker both have an option where you can fit more then one polygon in an Area. For GroundMaker for example if you don't layer the polygons (then the order in the source controls which one displays first) then they all go in one Area with each an own RefPoint. I haven't test it yet, but in principle I think expect the first polygon all others should be covered by the autogen. I'll continue with more tests to see if this is true....Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi Arno.I was surprised to note that autogen appears to be tied to a distance measurement ( so many meters ) rather than degrees of latitude and longitude. Now I am surprised, again, that it uses a simple X,Y rectangular shape for the exclusion.In your example, if a "dummy" refpoint doesn't work, then surely a tiny poly ( perhaps using the same point for all three verticies ) should work. This behavior may also explain why the dummy RotatedCall-TransformCall usage we all discussed earlier may work. And it might be applied somehow to this example.Very interesting, as sometimes we'd want polys to still have autogen.I'm not that familiar with traditional polygons.. but is an invisible poly possible? That could exclude autogen without excluding anything else?Very good topic to study.Dick

Share this post


Link to post
Share on other sites

Hi J.R.Does the necessary Area16 flatten suppress autogen by itself? I'm thinking it doesn't. And, assuming it doesn't, then the autogen suppression is from the elevated, invisible runway.That runway would probably conform roughly to the length-width ratios I found on the ground. But, something else I found, was that a runway of less than 10 feet width had little effect on the autogen around it. In fact, a 1 foot wide runway has no detectable effect on the autogen.What happens if the helipad's invisible runway is 1 foot wide, rather than a square? Can we still land? Does the 'copter "fall through", like earlier "runway-less" tests? Or is a 1 foot wide invisible runway still good for helipads, while retaining the surrounding autogen? ( At least I hope it is! )Dick

Share this post


Link to post
Share on other sites

Hi Dick,>In your example, if a "dummy" refpoint doesn't work, then >surely a tiny poly ( perhaps using the same point for all >three verticies ) should work. Yes, that might be a good thing to try. But are reversing the topic, we were trying to find out why the autogen dissapeared and not why it doesn't :).>This behavior may also explain why the dummy >RotatedCall-TransformCall usage we all discussed earlier may >work. And it might be applied somehow to this example. Yes, might be something similar to the second RefPoint. Maybe these commands also confuse the method that checks for the autogen size and therefore result in no exclusion.>I'm not that familiar with traditional polygons.. but is an >invisible poly possible? That could exclude autogen without >excluding anything else? Possible. I could just force it to draw the other side of the polygon and that was is of course not visible from the air :).I'll continue with more tests like this, this weekend. But as I have no internet on my room in Brussels, don't expect any posts about it until monday.Arno


Member Netherlands 2000 Scenery Team[a href=http://home.wanadoo.nl/arno.gerretsen]http://home.wanadoo.nl/arno.gerretsen/banner.jpg[/a]

Share this post


Link to post
Share on other sites

Hi J.R.I'm going to answer some of my own helopad questions. :)I made a building with helipad in the Chicago area.I tested the Area16n flatten... no bad effects on the autogen.I tested the building I was placing... It does effect autogen, and then I used a dummycall to eliminate the effect. It turns out the dummycall was unneeded, as the invisible runway excludes a larger area than the building.I then played with the pad's runway. But the invisible runway needs to be the same size as the pad, or you'll get "fall through".I even tried the invisible runway alone, and it is the cause of the exclusion that is larger than the building.The rough ratios of 2:1 length and 6:1 width are a little oversized for runway exclusion, as the picture will show.http://www.flatface.net/~rhumba/Pics/ChicagoHelopad.JPGI'm attaching the SCASM code as a text file for reference ( some odd coding you may enjoy there! ... I also borrowed some of your code I found lying around ).Dick

Share this post


Link to post
Share on other sites

Hi again Dick...I think we're proving tht the invisible rwy is definitely an AGN hog and unlike grouped 3D objects, ground polys, etc, the dummy calls don't seem to help that condition. However, for FS2002, the inv rwy is the only game in town (so far) compared with the old Area16 elevated hard surfaces we used in prior sims. You may be happily sitting on an elevated Area16 pad for many minutes and then FS seems to 'hiccup' and there you go -- falling right through the pad.The Area16 poly bgls used for flatten areas seem to be stable in open terrain and useful for local variation of mesh elevations and don't seem to destroy AGN. Beneath elevated rwy helipads, they behave very well until you depart/re-enter your scenery area whereupon they don't seem to always 'refresh' when re-entering the (add-on) scenery area.David Morgan of England (no relation) discovered that placing another dummy (here we go with the dummys again :-) ) helipad at ground level immediately below the elevated one seems to further nail things down when re-entering. That's what I use and it's working pretty well.Yep, I also played with the narrow inv rwys which allow more AGN but as you've discovered, it's pretty hard to balance on 1 (heli) skid on a 1 ft wide rwy :-).About the best combo I've experienced is using a square 86 x 86 ft elevated inv rwy. That size is chosen to be compatible with the Apt26 texture bitmap. Making quick measurements, the AGN seems to be killed equally in all directions around it using the attached macro. You might find some bugs in it or be able to fine-tune it to be better?I'm not sure I'm getting the same AGN destruct areas you're getting, with your code though. As mentioned, as near as I can tell, I think the AGN exclusions are fairly symmetrical around the elevated inv rwys. The top-view pic I posted yesterday is a little misleading because there was actually no native AGN within approx 90 m north of the pad shown in the top-down view (top is north).Unless someone finds a better way, I'm pretty much resigned to use of the elevated inv rwys as elevated helipads and live with the presently known AGN destruct zones. As mentioned, buildings seem to divert the viewer's attention from the loss of AGN, especially when using the FS2000 advanced buildings and dummy calls if necessary; i.e. the below scrnshot shows that one can keep the trees pretty close to the action.The basic macro I used for AGN testing here is atchd.The thing that really has me interested is what's the nature of the FS Engine that lets these 'band-aid' dummy calls work to save AGN :-).CUL -- 'been a long day.. My daughter's coming down from SFO tomorrow to pick up my car (her's is broke and not worth fixing).'Regards;J.R.

Share this post


Link to post
Share on other sites

Hi all.SurfaceType interacts with autogen... dependant upon the v2 setting!

; RussianSurfaceType.sca  N64* 10.923'   E49* 10.277'Header( 1 N65:00:00.0000 N64:00:00.0000 E050:00:00.0000 E049:0:00.0000 )LatRange( N64:00:00.0000 N65:00:00.0000 )Area( 5 N64:10:55.3800 E049:10:13.6200 )	RefPoint( rel :Surface_Fail  1.00  N64:10:55.3800  E049:10:13.6200  V1= 6000 V2= 1000 );	the v2 can control the area of autogen excluded!;	a v2 of 999 will exclude autogen in a rectangle of 500 x 999 (?);	a v2 of 500 will exclude autogen in a square of 500;	a v2 of 1000 will not exclude autogen at all;	so the v2 should be equal to or greater than the surface rectangle;	this also suggests v2 is not a round radius, but square x,y with dimensions dependant on the refpoint scaling.	RotatedCall( :Surface_Area 0 0 0 )	Jump( : ):Surface_Area	SurfaceType( 0 500 1000 0 ); 0 = smooth   1= rough   2 = water	Return:Surface_Fail	ReturnEndA

This code affects AGN buildings in the same way. This is the first time I've actually seen the v2 affect autogen. And now, v2 appears not to be a radius at all, but a square, in this case of 1000x1000 meters.Dick

Share this post


Link to post
Share on other sites

Hi J.R. I redid a 'floating' helipad in the Russian forest...It does seem that generic autogen trees may only be excluded right under the pad. As per your suggestion, I used a flatten, a groundlevel invisible runway, an elevated invisible runway, and a smoothed elevated bitmapped poly.I'll attach the code... and here's a screenshot with the excluded trees marked:

Share this post


Link to post
Share on other sites

Hi Arno."So this makes me conclude that, for polygons, autogen is excluded around everything that is in the first RefPoint of an Area block. For all further RefPoints no autogen is excluded." - ArnoYes, I agree. The first instance of Refpoint usage in a defined "Area" seems to be the only instance that effects autogen, for these polys... and that may have some bearing on "chained" transform or other types of calls.And if you follow your first Poly(), with a Dummy call, none of the autogen is affected in the Area.

Header( 1 41 39 -39 -41 )LatRange( 39 41 )Area( 5 40 -40 35 )LayerCall( :L 8 )Jump( : ):LRefPoint( 7 :R 1 40 -40 v1= 5000 v2= 300 )Points( 0-200 0 -100; 0200 0 -100; 10 0 300; 2)RGBSColor( EF 255 0 0 )Poly( m 0 32767 0 0.0 0 1 2 )RotatedCall(  :R  0  0  0   ) ; dummy call here saves all the autogen in the defined "Area"RefPoint( 7 :R 1 d 300 600 v1= 5000 v2= 300 )Points( 0-200 0 -100; 0200 0 -100; 10 0 300; 2)RGBSColor( EF 255 0 0 )Poly( m 0 32767 0 0.0 0 1 2 ):RReturnEndA

Dick

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this