TransformCall

[rhumbaflappy 113]

Hi Arno.Yes, I'll keep looking for alternatives.One reason for the insistance of using the TransformCall, is to preserve the autogen, as J.R. and Tosh first indicated. I know the SDK says to include v1 and v2 or suffer slowdowns, but in this case, with the dummy RotatedCall followed by the TransformCall, the v1 and v2 seem unneeded. Tests by J.R. and I have found that the TransformCall overrides the v2 setting, so it may be unneeded here. That's the reason the autogen is preserved.I'll have to check to see if all the objects disappear at the same distance... but at the default distance ( the same distance runways disappear ), and with the objects grouped rather closely together, it shouldn't make much difference. If that's all true, then v2 is unneeded as well, in this case.That only leaves the possibility of slowing down the sim, and neither J.R., Tosh, or I have noticed that, yet... I suspect that FS2002 has compensated for this.Effects work with this code... simply substitute the effect for the advanced building code, and the separate refpoints keep the effects anchored to the ground as well.DickEDITED:Simply adding v1 and v2 seems to have no effect: RefPoint( rel :Fail 1.00 d 0 0 v1= 20000 v2= 50 ) Call( :House1 ) RefPoint( rel :Fail 1.00 d 0 100 v1= 20000 v2= 50 ) Call( :House2 ) RefPoint( rel :Fail 1.00 d 0 200 v1= 20000 v2= 50 ) Call( :House1 ).............The objects disappear at the same time the surrounding scenery "mips", and the autogen disappears at the same time. The objects and the autogen disappear in bands, at distance. This is not what I had expected, and may be a clue... perhaps the effects and advanced buildings have more in common with autogen than with complex objects?Also, the grouped effects have a large FPS penalty, but the advanced buildings do not. Perhaps, 52 separate effects displays are a bit much!:)Just checked again, and the autogen disappears much before the buildings, which disappear much before the runways... (sigh...)

[arno 1]

Hi Dick,I think that the AdvBldg and GObj (effects) are special commands that are handled differently by the scenery engine.But I think for any other code the v1/v2 values are important. So these comments of mine should more be seen in the general discussion and might not be relevant for these very special cases."One reason for the insistance of using the TransformCall, is to preserve the autogen, as J.R. and Tosh first indicated."But when you set the v2 to an apropiate small value that should also save the autogen, right? And that doesn't included special tricks like extra TransformCalls."I know the SDK says to include v1 and v2 or suffer slowdowns, but in this case, with the dummy RotatedCall followed by the TransformCall, the v1 and v2 seem unneeded."I think that is only because the AdvBldg is treated special. If I have some time I'll try to look a bit into it."Tests by J.R. and I have found that the TransformCall overrides the v2 setting, so it may be unneeded here. That's the reason the autogen is preserved."That sounds very strange to me. I have used TransformCall before in projects and there the v2 was surely needed. I think this is once again because these buildings are exceptions."I'll have to check to see if all the objects disappear at the same distance... but at the default distance ( the same distance runways disappear ), and with the objects grouped rather closely together, it shouldn't make much difference. If that's all true, then v2 is unneeded as well, in this case."True, if they are grouped rather close together the effect is not that big (apart from the effect the v2 would normally have, but that seems not to be the case with these buildings).Arno

---

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

[rhumbaflappy 113]

Hi Arno.http://ftp.avsim.com/dcforum/DCForumID10/1785.htmlThat link was one we participated in a few days ago.That original post by efva2002 described a broad object... the very type that will hurt the autogen, as the v2 must be large enough to encompass the long width.At that time I thought you didn't catch what exactly I was doing with the TransformCall. I had an example in which I greatly exaggerated the v2, and would wipe out the autogen for quite a large radius... then I used TransformCall to relocate the apparent Refpoint to an altitude of 32767 meters. I think that's what threw you. I just wanted to show the v2 no longer having any effect on the autogen.The object displays at the Refpoint ( ground level in that case ), but the TransformCall fools the sim into believing it's really referenced at 32767 meters altitude... that's why the autogen is fine... because there's no autogen at that height. I could have gone NSEW, but instead chose to go vertically... because if I had gone, say North, then at the apparent Refpoint, I might have wiped out autogen there, for that v2 radius. I noted some designers recommending moving the apparent Refpoint to an area of water... where no autogen exists. I wanted to see if going vertical would work, as that wouldn't interfere with anything on the ground... and we should still be able to use the Lat-Long to exclude it, instead of hunting around for the refpoint as we must for some of FS2002's default objects. ( That code worked fine with library objects, as well.)The introduction of the Dummy RotatedCall is now also found to preserve the autogen, when followed by a TransformCall.J.R. Morgan then had a grouped cluster of buildings he had used with the DummyCall/TransformCall combo... and I have just been tweaking this code, so as to make it a little "tighter" and save some typing for J.R., and others, if they like this way of grouping objects.I'm 99% in agreement with you about using a proper v2 to save autogen. But for a cluster of objects, or for long objects, the v2 ( because it is large or round-shaped ) will destroy much autogen that can be salvaged by the use of a TransformCall ( and a Dummy RotatedCall if needed ).I don't really consider this a trick, but as a solution for specific problems involving long objects or grouped clusters. Of course, the question comes up as to why use RotatedCall at all, if the TransformCall guarantees preserved autogen. And I don't know the whole answer to that, or why MS still uses RotatedCall, with the v2, if there is no penalty with the essentially v2-less TransformCall.I've looked for a good reason not to use TransformCall, and the reason I get, is that sometimes we want to exclude autogen... you don't want trees growing up through all your buildings... or default buildings added onto your object like so many tacked-on garden sheds! :-eek =================So my advice to all on this:Unless there is a specific reason for a grouped cluster ( that cannot be easily handled with separate v2's to preserve autogen ), or your object is quite long, then there isn't really a good reason for using the TransformCall at all in this way... just use a proper v2 radius, with a RotatedCall, as Arno has written.If your objects are still killing the autogen, then consider using TransformCalls, and possibly Dummy RotatedCalls. If there are autogen popping up through the object(s), you can do as J.R. Morgan suggests, and move your objects slightly away from the autogen. Or you might be able to add a small exclusion, to suppress the specific autogen, in the code before you place the object or group...Exclude( 01 TopLat BottomLat RightLon LeftLon ).....then the placing code.Dick

[Guest GerrishGray]

Hi guysI seem to have missed something here.An earlier post said "In a different thread, we had established that an oversized v2 will exclude autogen." I don't know what I'm doing wrong but, however hard I try to reproduce this, I cannot get a v2 value in a RefPoint() to have any influence on killing Autogen whatsoever. I place one or more normal 3D objects at or near a RefPoint location that is surrounded by Autogen objects. The only Autogen objects killed are those right up close to the new objects. Changing the v2 value in the RefPoint() has no affect at all - I can set it to 0, 25, 250, 1000 or 32767 and the Autogen objects are still there, within meters of the newly-placed objects, no change whatsoever.I have looked through the recent posts for a report of testing of the effect of v2 on Autogen, but the only reported test I can find at the moment was with a SIZE parameter in BGLPlacer, not with a v2 value in RefPoint() ... can anyone help?CheersGerrish

[Guest JR Morgan]

Hi Gerrish.. The other thread mentioned may have been a comment in Reply #19 to Reading Topic #1785 --- (How do I make links to other archived messages instead of describing it this way? :-) ).The snippet below (part of a taxiway with lines macro) is an example I experienced whereby I had to reduce V2 from 833 to 60 in order to save an AGN pair of houses. Since those houses were your great looking AGN replacments, I had to save them :-). If the picture comes through OK, you can see the houses in it's foreground.; Runway Hold line Rwy Hold for Rwy 18Area( 5 38:59.85295 -089:10.01292 10 ) LayerCall( :TaglayerH 16 ); 16 was 20 Jump( : ):TaglayerH RefPoint( 7 :TagPoly .3 38:59.85295 -089:10.01292 V1= 2400 V2= 60 );60 was 833 TaxiMarkings( ; SD 0 -93.9999962647759; SD 0 93.3333296246 HRWY 0 -93.9999962647759 0 93.3333296246 BREAK ) :TagPoly ReturnEndA'Regards & Thanks;J.R.

[arno 1]

I agree :), nice summary. I think I thought too much about the coding in the end and lost the origional question :D.Arno

---

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

[rhumbaflappy 113]

Hi Gerrish.I went back to that example, in order to prove that the v2 affects the autogen. And failed to prove anything.You are right about the v2 parameter, and I have misled myself and others in that.I also increased the v2 ( RADIUS ), and it makes no difference. What fooled me was the nasty habit of autogen to disappear after scenery containing objects is deactivated through the Scenery Library. And this nasty 'bug' only is affecting scenery designers, as most simmers are not constantly activating-deactivating scenery!I was aware of this, but developed a blind-spot to it, by being convinced the v2 affected autogen. By selecting a saved flight in another area, then reselecting the "Brandonville" flight, to redisplay the building with the huge v2, the autogen now sits there staring at me, snug against the building with the oversized v2!This now is leading me to wonder if Tosh's original problem may have been caused by this same annoying 'bug' of the autogen... had he restarted the sim, or visited another area of the planet, then returned, the autogen may have also returned.=====================Yet, the examples with TransformCall and the "Dummy" RotatedCall don't seem to aggrevate the 'bug' of the autogen display... so there may yet be a connection there.I'm going to spend some time with J.R. Morgan's API example today, and see if grouping objects in a more traditional way will spark an autogen problem... and I'll be more careful to account for the display problems concerning the autogen that have nothing to do with objects.There are some questions that do arise about the odd code J.R. and myself developed here, and if there is any reason NOT to group objects this way, if the designer wants to cluster buildings or effects. According to the warnings of the SDK, the coding I used should cause slowdowns of the sim.. but I cannot detect that it does that in either FS2002 or CFS2... I haven't tried the API with FS2000, yet.I'll also look at advanced buildings again, to see if the v2 makes any difference with those objects concerning autogen loss. ( My "Brandonville" example was a library object... and that object had a size parameter in it ). I would now suspect they don't have an autogen problem connected to v2.======================I do have 2 questions:What is the function of v2 ( RADIUS ) regarding object display in FS2002?Has anyone found an easier method to avoid this autogen 'bug' during the testing phase of design?Dick

[Guest GerrishGray]

Hi DickYou ask about the function of the v2 value in RefPoint(). If it is present, the RefPoint() command does a visibility check to see if any part of a sphere of radius v2, centered on the RefPoint, is actually visible within the bounds of the screen display. Similarly, the v1 value is used to check the range of the RefPoint from the current viewpoint. Both of these visibility checks are executed very quickly and efficiently. If either fails, the code jumps to the :Fail label, which is why that label is supplied in the RefPoint() command. This feature has always been present in the BGL engine as an efficient way of optimising frame rates. The FS2000 SDK suggested that the use of the v1 and v2 checks might be made non-optional in subsequent versions. This wasn't done in FS2002 but it might well be done with FS2004?This is the sole 'official' purpose of the v1 and v2 values. If either or both are omitted, the corresponding visibility checks are not performed, and this can result in a lot of time-wasting with a considerable hit on frame rates in some cases.However, JR's suggestion that the v2 value does affect the culling of Autogen in some cases could indicate that parts of the FS code actually do use the v2 value to determine a 'size' for the following object, e.g. for the Taxiway() stuff, where it is not easy to determine the size from a simple Points / VecPoints / Vertex list. If so, it would indicate that perhaps the programmer who wrote that part of the code was taking an easy way out ;-) but it hasn't been documented in the SDK! (no great surprise!). There might be a similar explanation as to why the dummy RotatedCall() seems to prevent Autogen culling - perhaps there is a 'bug' or over-simplification in the coding of FS that results in the calculation of the object size (which otherwise seems to be very accurate in straightforward cases) being overridden. Who knows - there is only one certainty here: M$ are never going to tell us something like that!CheersGerrish

[Guest GerrishGray]

Hi DickOn the second point about scenery testing, Autogen is correctly re-generated if you force a full scenery reload by going to the Scenery Library dialog and clicking on OK (there is no need to actually change any settings). I know that this causes an annoying delay as everything is rebuilt, but it is the only way to ensure that the test of the revised scenery works correctly because FS2002 otherwise buffers so much stuff in memory caches.CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.I know we're straying from the subject, but my experiences with re-generating the autogen are quite different. And that's how I got a mistaken impression of the v2.I could include screen shots, but it would only waste Avsim's bandwidth... and I think you can trust me here:Cockpit view, slew mode. 1) viewing the default autogen trees and buildings near Brandonville, WV, USA... all is well.2) activate a scenery from the Scenery Library that places one large library object building. Press OK. The sim displays the object and autogen.3) Go back to the Scenery Library and deactivate the placement BGL scenery. Press OK. The sim now doesn't display the autogen or the object.4) Go to the Scenery Library and just press OK. The sim still doesn't display the autogen.5) Go to the Scenery Library and activate the placemant scenery for the library object. Press OK. The sim displays the object, but still not the autogen. The autogen of the area is suburban... neither the trees or the building show. A bit farther away, the tree autogen is fine.. but no buildings... so I suspect the disappearance is tied to the landclass/texture types of autogen. ( Isn't it true we have a vegetation autogen not tied ot the AGN files? )This is exactly how I got messed up. I activated the placement of a library object with a small v2 at step #2 ( it was fine and the autogen was fine ), then deactivated it and activated a placement scenery of a library object with a huge v2 ( essentially, step 3 )... and mistakenly blamed the v2 for the autogen loss that now appeared. I repeated the process over and over the same way.. so I never caught on to the truth.If I add a different step... and now go to a remote airport or select a flight at the far end of the world, then return to Brandonville, the autogen is fine, whether or not any objects ( with any v2 size ) are present.So leaving the area, and returning, restores the autogen reliably. Whereas just refreshing the scenery by pressing OK from the Scenery Library does not always work.And I'm thinking this is causing designers to believe ( as I did ) that their objects are somehow causing this disappearance of autogen. I remember Chris Wright has experienced this as well... and I'll bet many others. ( Tosh & J.R. ? )We might want to start a separate discussion thread to find out what exactly does exclude autogen. Runways? Or runway markings? Or taxi lines? Ground polys? Bitmap types? Photoreal placed ground textures? Long or irregular-shaped objects. Large objects?Dick

[Guest GerrishGray]

Hi DickSorry, I had indeed seen the problems you describe for myself some time last year ... At that time I thought the only way of refreshing anything to do with Autogen was to restart FS entirely, but then I discovered, when playing with Autogen textures, that a full reload via the scenery library dialog would, at least, reload the texture sheets and .agn patterns ... but I forgot about the other issues! My apologies for misleading you. The problem is indeed caused by the way that Autogen is generated and, as you say, the landclasses that use .agn pattern files behave differently to the vegetation-only classes that look up their patterns in a hard-coded lookup table. It is nothing to do with FS 'remembering' non-active scenery, the problem is that it simply doesn't regenerate the Autogen. The only complete cure is indeed to shut down FS and restart it completely - which is very annoying when trying to do some quick testing, eh.I believe that most types of visible scenery cull Autogen. That would be the correct, and desirable, effect. The only things I have seen that don't do so are (a) Autogen buildings and trees can overlap each other, and (:( some objects placed using one of the tricks that fool FS, like your TransformCall() with an altitude setting. But the Autogen culling does seem to work on a simple 'size' basis with some scenery types, taking the longest dimension (or even the v2 value sometimes, it seems?) as the size of the area to be cleared. Yes, perhaps it would be a good idea to start a new thread to try to collate this more precisely ... it was your idea so I'll leave it to you to get it going. You might want to quote the only relevant detail from the M$ documentation, which simply says "Autogen prevents automatically generated objects from overlapping custom-placed objects..." - (from page 12 of the Annotator SDK) - no other information is supplied! 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.Kind RegardsGerrish

[wsieffert 0]

Whew! - time out for a local refreshment!!:-beerchug I'm wooped!*:-*