TransformCall

[Guest JR Morgan]

OK Dick --- 'Back from the wars with good news and bad news:The good news is that the scheme you proposed works very well EXCEPT it does not draw the first house object at the RefPt. It appears that the first (RefPt) object needs a direct call of some sort instead of a TransformCall? Anyway, that's the way it seems to be working on this end.Use of TransformCall instead of RotatedCall for the DUMMY works fine.The only thing I don't like about it is that it requires more typing :-).I guess my conclusion, based on this test is that the first object must be placed with a "Firm" call (i.e., RotatedCall), but the AGN saving "Dummy" call can be either a RotatedCall or a TransformCall.Whaddya Think Chief?Thanks;J.R.

[arno 1]

Just some other views.I was working on my Schiphol taxiways and aprons last evening and I was trying to optimize the code. At first all polygons where in one Area and one RefPoint with just all point tables calculated from that RefPoint. This needed a big v2 value to cover everything of course.Then I used a GRP and calculated a new RefPoint for the middle of each polygon. This way the v2 value is optimal for each polygon (I used the SCASM RefPoint d option to let SCASM do the calculation).The framerates with everything on the screen didn't really change, but when I sat on the apron the frames had more then doubled (these polygons where the only thing around there, the rest was ocean :)). So this shows the importance of a good v2 value for the frames.I think when I would have used a TransformCall (haven't tried that) that I would need a bigger v2 value to prevent display problems.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 J.R.You're right about needing a RotatedCall to start the process... but you can start it with a Dummy, then proceed to the TransformCalls.I'm going to post a long piece of code here, because the attachments fade in time, and this might be a good reference for others in months to come.I reorganised your code, ( you'd need to reconvert it to an API Macro for that use..). I also noticed you only had 2 kinds of houses, so I reduced that code:

; ----------------------------------------; Delavan	N42* 37.58*	 W88* 36.39'; ----------------------------------------Header( 1  N42:38:01.80 N42:38:01.80 W088:36:33.00 W088:36:33.00 )LatRange(  N42:38:01.80  N42:38:01.80 )Area(  5  N42:38:01.78  W088:36:33.00  10  ); Setting the RefPoint -------------------  RefPoint(  rel  :Fail  1.00  N42:38:01.78  W088:36:33.00 v2 = 22 ); Calls -----------------------  RotatedCall(  :Fail 0 0 0 ); DummyCall	TransformCall(  :House1  000 000 000  0 0 0 0 0 0 )	TransformCall(  :House2  100 000 000  0 0 0 0 0 0 )	TransformCall(  :House1  200 000 000  0 0 0 0 0 0 )	TransformCall(  :House2  300 000 000  0 0 0 0 0 0 )	TransformCall(  :House1  300 000 -100  0 0 0 0 0 0 )	TransformCall(  :House1  400 000 -100  0 0 0 0 0 0 )	TransformCall(  :House1  200 000 -100  0 0 0 0 0 0 )	TransformCall(  :House1  100 000 -100  0 0 0 0 0 0 )	TransformCall(  :House1  000 000 -100  0 0 0 0 90 0 )	TransformCall(  :House1  000 000 -200  0 0 0 0 90 0 )	TransformCall(  :House2  100 000 -200  0 0 0 0 0 0 )	TransformCall(  :House1  200 000 -200  0 0 0 0 0 0 )	TransformCall(  :House2  300 000 -200  0 0 0 0 0 0 )	TransformCall(  :House1  400 000 -200  0 0 0 0 90 0 )	TransformCall(  :House2  200 000 -300  0 0 0 0 0 0 )	TransformCall(  :House1  100 000 -300  0 0 0 0 0 0 )	TransformCall(  :House2  000 000 -300  0 0 0 0 90 0 )	TransformCall(  :House1  000 000 -400  0 0 0 0 90 0 )	TransformCall(  :House2  100 000 -400  0 0 0 0 0 0 )	TransformCall(  :House1  190 000 -400  0 0 0 0 90 0 )	TransformCall(  :House1  000 000 -500  0 0 0 0 90 0 )	TransformCall(  :House2  100 000 -500  0 0 0 0 90 0 )	TransformCall(  :House1  200 000 -500  0 0 0 0 0 0 )	TransformCall(  :House2  300 000 -500  0 0 0 0 0 0 )	TransformCall(  :House1  450 000 -500  0 0 0 0 0 0 )	TransformCall(  :House2  000 000 -650  0 0 0 0 90 0 )	TransformCall(  :House1  100 000 -650  0 0 0 0 0 0 )	TransformCall(  :House2  200 000 -650  0 0 0 0 0 0 )	TransformCall(  :House1  300 000 -650  0 0 0 0 0 0 )	TransformCall(  :House2  400 000 -650  0 0 0 0 0 0 )	TransformCall(  :House2  000 000 -750  0 0 0 0 90 0 )	TransformCall(  :House1  100 000 -750  0 0 0 0 0 0 )	TransformCall(  :House2  200 000 -750  0 0 0 0 0 0 )	TransformCall(  :House1  300 000 -750  0 0 0 0 0 0 )	TransformCall(  :House2  400 000 -750  0 0 0 0 90 0 )	TransformCall(  :House1  000 000 -850  0 0 0 0 90 0 )	TransformCall(  :House2  100 000 -850  0 0 0 0 0 0 )	TransformCall(  :House1  200 000 -850  0 0 0 0 0 0 )	TransformCall(  :House2  300 000 -850  0 0 0 0 0 0 )	TransformCall(  :House1  400 000 -850  0 0 0 0 90 0 )	TransformCall(  :House2  000 000 -950  0 0 0 0 90 0 )	TransformCall(  :House1  100 000 -950  0 0 0 0 0 0 )	TransformCall(  :House2  180 000 -950  0 0 0 0 90 0 )	TransformCall(  :House1  320 000 -975  0 0 0 0 0 0 )	TransformCall(  :House2  400 000 -950  0 0 0 0 90 0 )	TransformCall(  :House1  005 000 -1050  0 0 0 0 90 0 )	TransformCall(  :House2  100 000 -1050  0 0 0 0 0 0 )	TransformCall(  :House1  200 000 -1050  0 0 0 0 0 0 )	TransformCall(  :House2  300 000 -1100  0 0 0 0 0 0 )	TransformCall(  :House1  400 000 -1100  0 0 0 0 0 0 )	TransformCall(  :House2  007 000 -1120  0 0 0 0 90 0 )	TransformCall(  :House1  100 000 -1120  0 0 0 0 90 0 )  RotatedCall(  :Fail 0 0 0 ); DummyCall  Jump(  :  ); Buildings -------------------:House1  AdvBldg( PEAKED 40 20	LEVEL1 27 5 128 128	LEVEL2 0 0 256 256 256	LEVEL3 0 0 256 256	ROOF 9 256 256 7 256 )  Return:House2  AdvBldg( PEAKED 30 15	LEVEL1 81 4 256 256	LEVEL2 0 0 256 256 256	LEVEL3 81 4 256 256	ROOF 28 256 256 2 256 )  Return:Fail  ReturnEndA

Same effect as your code, but the logic is "tightened" a little. I'm not sure the V2 is even needed, but it does no harm. No ShadowCalls or Perspective Opcodes. And the autogen is fine.So to answer Tosh's original question, the 'DummyCalls' will allow the use of TransformCall, without autogen penalty.I'm going to experiment with Arno's use of GRP(), but I don't know if that has any advantage... but it may be easier to type than all those parameters for TransformCall. :) DickEDITED........Another happy surprise. This coding works in CFS2 and FS2000, as well. But a flatten may be required under the cluster, as the buildings seem to no longer be AGL, other than the first. This doesn't seem to affect FS2002.

[arno 1]

You amaze me with such code, it's against all SCASM logic that with such a dummy RotatedCall the code still works :).Also, where is the PerspectiveCall? I think you can expect strange problems with this code (for example when you are on the ground you see the clouds through the building).And about the GRP, I'll take a piece of example code (from the polygons) with me tomorrow. I think for other objects then such buildings (ground polygons or something like that) you might get a problem with the v2 value you used now (it's to small to cover all of them). In that case it is better to give each object it's own RefPoint. Another bonus of that is that you can give each RefPoint his own range (might be interesting for objects of different importance or so).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.It actually gets much worse than that!I'm attaching some code that uses your GRP() function... It works much better for CFS2, because it defines the AGL for each object... works fine in FS2002, but seems like much more typing than the TransformCall method.The object placement is exactly the same as J.R's original code.

; ----------------------------------------; Delavan grouped   N42* 37.58*   W88* 36.39'; ----------------------------------------Header( 1  N42:38:01.80 N42:38:01.80 W088:36:33.00 W088:36:33.00 )LatRange(  N42:38:01.80  N42:38:01.80 )Area(  5  N42:38:01.78  W088:36:33.00  10  )  GRP(  N42:38:01.78   W088:36:33.00  )  RefPoint(  rel  :Fail  1.00  d  0  0  )  RotatedCall(  :House1  0  0  0   )    RefPoint(  rel  :Fail  1.00  d  0 100  )  RotatedCall(  :House2  0 0 0   )    RefPoint(  rel  :Fail  1.00  d  0 200  )  RotatedCall(  :House1  0 0 0   )..............

then...

  RefPoint(  rel  :Fail  1.00  d  -1120 0  )  RotatedCall(  :House2  0 0 90   )    RefPoint(  rel  :Fail  1.00  d  -1120 100  )  RotatedCall(  :House1  0 0 90   )    Jump(  :  ); Buildings -------------------:House1  AdvBldg( PEAKED 40 20	LEVEL1 27 5 128 128	LEVEL2 0 0 256 256 256	LEVEL3 0 0 256 256	ROOF 9 256 256 7 256 )  Return:House2  AdvBldg( PEAKED 30 15	LEVEL1 81 4 256 256	LEVEL2 0 0 256 256 256	LEVEL3 81 4 256 256	ROOF 28 256 256 2 256 )  Return:Fail  ReturnEndA

Dick

[rhumbaflappy 113]

Hi Arno.I've discovered there is a big difference between the AdvBldg() code, and the code to call library objects. There do seem to be problems with the above examples I've shown!I'm very much leaning towards your idea of SCASM's GRP() to place objects at x,y offsets.The AdvBldg() code places it's objects well, but when we have library objects, there are then scaling and shadow problems... and those may be agrevated by the odd code form I used.It does give us something to play with. :)Dick

[Guest JR Morgan]

Dick... This is a totally 'delicious' piece of work you've done (again). 'Took your last listing and commented it into an api macro as below. Tested it fairly extensively and it works just fine here. I can't be totally sure but I think the frames are a little more solid than before. No visibility problems whatsoever noted -- Shadows work, etc. Obviously, the V1/V2 values are at the mercy of the default (rel) RefPt scaling and they appear to be doing their thing beautifully.The listing below is commented as an api macro for calling in GUI's like Apt. Re-commenting per the 'Note:' below should allow direct SCASM compile into a bgl when Header, Area and RefPt locations are defined for a user's locaton environment.---------------------------------------------------;AdvBld52_RL.api Macro and/or SCASM source code to add 52;Advanced Buildings To Augment Lack Of Autogen Houses;AdvBldg( Type 40 is Brown Ranch/Bungalow House;AdvBldg( Type 30 is White Semi-Colonial Facaded House;Placement of houses can be altered by following the SCASM conventions for TransformCall;%1=Latitude;%2=Longitude;%4=Scale;%5=Heading;Copyright SCASM - Macro by J.R. Morgan Jr. Revised by Richard Ludowise for compactness and effeciency of execution.;NOTE: For direct compile, un-comment lines with "*" suffix and comment-out lines with "**" suffix rems.; ----------------------------------------; Delavan N42* 37.58* W88* 36.39' ; ----------------------------------------;Header( 1 N42:38:01.80 N42:38:01.80 W088:36:33.00 W088:36:33.00 );*;LatRange( N42:38:01.80 N42:38:01.80 );*;Area( 5 N42:38:01.78 W088:36:33.00 10 );* Area( 5 %1 %2 10 );**; Setting the RefPoint -------------------; RefPoint( rel :Fail 1.00 N42:38:01.78 W088:36:33.00 v2 = 22 );* RefPoint( 7 :Fail %4 %1 %2 );**; Calls ----------------------- RotatedCall( :Fail 0 0 0 ); DummyCall TransformCall( :House1 000 000 000 0 0 0 0 0 0 ) TransformCall( :House2 100 000 000 0 0 0 0 0 0 ) TransformCall( :House1 200 000 000 0 0 0 0 0 0 ) TransformCall( :House2 300 000 000 0 0 0 0 0 0 ) TransformCall( :House1 300 000 -100 0 0 0 0 0 0 ) TransformCall( :House1 400 000 -100 0 0 0 0 0 0 ) TransformCall( :House1 200 000 -100 0 0 0 0 0 0 ) TransformCall( :House1 100 000 -100 0 0 0 0 0 0 ) TransformCall( :House1 000 000 -100 0 0 0 0 90 0 ) TransformCall( :House1 000 000 -200 0 0 0 0 90 0 ) TransformCall( :House2 100 000 -200 0 0 0 0 0 0 ) TransformCall( :House1 200 000 -200 0 0 0 0 0 0 ) TransformCall( :House2 300 000 -200 0 0 0 0 0 0 ) TransformCall( :House1 400 000 -200 0 0 0 0 90 0 ) TransformCall( :House2 200 000 -300 0 0 0 0 0 0 ) TransformCall( :House1 100 000 -300 0 0 0 0 0 0 ) TransformCall( :House2 000 000 -300 0 0 0 0 90 0 ) TransformCall( :House1 000 000 -400 0 0 0 0 90 0 ) TransformCall( :House2 100 000 -400 0 0 0 0 0 0 ) TransformCall( :House1 190 000 -400 0 0 0 0 90 0 ) TransformCall( :House1 000 000 -500 0 0 0 0 90 0 ) TransformCall( :House2 100 000 -500 0 0 0 0 90 0 ) TransformCall( :House1 200 000 -500 0 0 0 0 0 0 ) TransformCall( :House2 300 000 -500 0 0 0 0 0 0 ) TransformCall( :House1 450 000 -500 0 0 0 0 0 0 ) TransformCall( :House2 000 000 -650 0 0 0 0 90 0 ) TransformCall( :House1 100 000 -650 0 0 0 0 0 0 ) TransformCall( :House2 200 000 -650 0 0 0 0 0 0 ) TransformCall( :House1 300 000 -650 0 0 0 0 0 0 ) TransformCall( :House2 400 000 -650 0 0 0 0 0 0 ) TransformCall( :House2 000 000 -750 0 0 0 0 90 0 ) TransformCall( :House1 100 000 -750 0 0 0 0 0 0 ) TransformCall( :House2 200 000 -750 0 0 0 0 0 0 ) TransformCall( :House1 300 000 -750 0 0 0 0 0 0 ) TransformCall( :House2 400 000 -750 0 0 0 0 90 0 ) TransformCall( :House1 000 000 -850 0 0 0 0 90 0 ) TransformCall( :House2 100 000 -850 0 0 0 0 0 0 ) TransformCall( :House1 200 000 -850 0 0 0 0 0 0 ) TransformCall( :House2 300 000 -850 0 0 0 0 0 0 ) TransformCall( :House1 400 000 -850 0 0 0 0 90 0 ) TransformCall( :House2 000 000 -950 0 0 0 0 90 0 ) TransformCall( :House1 100 000 -950 0 0 0 0 0 0 ) TransformCall( :House2 180 000 -950 0 0 0 0 90 0 ) TransformCall( :House1 320 000 -975 0 0 0 0 0 0 ) TransformCall( :House2 400 000 -950 0 0 0 0 90 0 ) TransformCall( :House1 005 000 -1050 0 0 0 0 90 0 ) TransformCall( :House2 100 000 -1050 0 0 0 0 0 0 ) TransformCall( :House1 200 000 -1050 0 0 0 0 0 0 ) TransformCall( :House2 300 000 -1100 0 0 0 0 0 0 ) TransformCall( :House1 400 000 -1100 0 0 0 0 0 0 ) TransformCall( :House2 007 000 -1120 0 0 0 0 90 0 ) TransformCall( :House1 100 000 -1120 0 0 0 0 90 0 ) RotatedCall( :Fail 0 0 0 ) ; DummyCall Jump( : ); Buildings -------------------:House1 AdvBldg( PEAKED 40 20 LEVEL1 27 5 128 128 LEVEL2 0 0 256 256 256 LEVEL3 0 0 256 256 ROOF 9 256 256 7 256 ) Return:House2 AdvBldg( PEAKED 30 15 LEVEL1 81 4 256 256 LEVEL2 0 0 256 256 256 LEVEL3 81 4 256 256 ROOF 28 256 256 2 256 ) Return:Fail ReturnEndA----------------------------------------------------For augmenting AGN houses with simple MS advenced buildings in locations neglected by M$, this seems to be just the thing needed as a 'filler-inner' :-).Thanks;J.R.

[rhumbaflappy 113]

Hi J.R.As I noted to Arno, this doesn't work well with library objects... but it does work well as an autogen replacer-enhancer, using the AdvBldg() commands, as you indicated. There may be other types of objects that may be OK, or even effects.And even Arno might come to like it, eventually. :)It would be useful near airfields, and it could be used to populate VTP polys or small CUSTOM-textured areas.You could, in CFS2, use something like this to stamp small cities all over the place, or emulate autogen, with just a few buildings defined, and a dozen macros, for variety.This was a nice thing for you to share J.R. I tried your macro as an API in FSSC, and it works just fine.I hope Tosh got some ideas from all of this... and I hope Arno can still give us an example of his GRP() code, as that may be what Tosh needs.Dick

[arno 1]

Here is the example of the GRP code I used.

Set( fsvers 0x800 )Set( buf 1024 )Set( areamx 1024 ) Header( 1 40.5 39.5 -39.5 -40.5 )LatRange( 39.5 40.5 ) Area( C 40 -40 25 ) GRP( 40 -40 ) LayerCall32( :object_4_scale 4 )Jump32( : ) :object_4_scale RefPoint( 7 :object_0_return 1  d 416.645223999023 -850.31484375 v1= 10000 v2= 124 )MaterialList( 00.500 0.500 0.500 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000) TextureList( 05 FF 128 128 128 0 1.000 "naam.bmp"5 FF 128 128 128 0 1.000 "asfalt.bmp"5 FF 128 128 128 0 1.000 "beton.bmp") VertexList( 0-74.193  0.000 29.079 0.000 1.000 0.000 -18.548 7.270-79.857  0.000 14.865 0.000 1.000 0.000 -19.964 3.716-39.045  0.000 16.741 0.000 1.000 0.000 -9.761 4.185-68.410  0.000 -56.882 0.000 1.000 0.000 -17.103 -14.220-19.702  0.000 -73.710 0.000 1.000 0.000 -4.926 -18.4286.563  0.000 -0.650 0.000 1.000 0.000 1.641 -0.16335.850  0.000 -10.294 0.000 1.000 0.000 8.962 -2.57448.363  0.000 20.760 0.000 1.000 0.000 12.091 5.19092.344  0.000 22.836 0.000 1.000 0.000 23.086 5.70998.089  0.000 37.254 0.000 1.000 0.000 24.522 9.314) SetMaterial( 0 1 )DrawTriList( 00 1 22 3 42 4 52 5 62 6 70 2 70 7 80 8 9):object_0_return RefPoint( 7 :object_1_return 1  d 517.808512369792 -787.654520670573 v1= 10000 v2= 129 )MaterialList( 00.500 0.500 0.500 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000) TextureList( 05 FF 128 128 128 0 1.000 "naam.bmp"5 FF 128 128 128 0 1.000 "asfalt.bmp"5 FF 128 128 128 0 1.000 "beton.bmp") VertexList( 0-123.231  0.000 -34.541 0.000 1.000 0.000 -30.808 -8.635-102.197  0.000 25.245 0.000 1.000 0.000 -25.549 6.31150.695  0.000 32.136 0.000 1.000 0.000 12.674 8.03470.213  0.000 31.020 0.000 1.000 0.000 17.553 7.75562.493  0.000 -26.444 0.000 1.000 0.000 15.623 -6.61142.027  0.000 -27.415 0.000 1.000 0.000 10.507 -6.854) SetMaterial( 0 1 )DrawTriList( 02 1 03 2 04 3 05 4 0):object_1_return RefPoint( 7 :object_2_return 1  d 950.57367960612 -568.414405822754 v1= 10000 v2= 211 )MaterialList( 00.500 0.500 0.500 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000) TextureList( 05 FF 128 128 128 0 1.000 "naam.bmp"5 FF 128 128 128 0 1.000 "asfalt.bmp"5 FF 128 128 128 0 1.000 "beton.bmp") VertexList( 0-153.470  0.000 -143.299 0.000 1.000 0.000 -38.367 -35.825-29.740  0.000 -137.438 0.000 1.000 0.000 -7.435 -34.35952.231  0.000 -20.674 0.000 1.000 0.000 13.058 -5.16890.727  0.000 27.210 0.000 1.000 0.000 22.682 6.80282.995  0.000 33.553 0.000 1.000 0.000 20.749 8.38872.682  0.000 21.096 0.000 1.000 0.000 18.170 5.27423.896  0.000 61.332 0.000 1.000 0.000 5.974 15.33336.805  0.000 77.711 0.000 1.000 0.000 9.201 19.42814.076  0.000 95.627 0.000 1.000 0.000 3.519 23.907-30.741  0.000 38.770 0.000 1.000 0.000 -7.685 9.693-79.731  0.000 -26.944 0.000 1.000 0.000 -19.933 -6.736-79.731  0.000 -26.944 0.000 1.000 0.000 -19.933 -6.736) SetMaterial( 0 1 )DrawTriList( 02 3 40 1 22 4 50 2 50 5 60 6 70 7 80 8 911 10 90 9 11):object_2_return RefPoint( 7 :object_3_return 1  d -780.618804931641 -175.902755737305 v1= 10000 v2= 123 )MaterialList( 00.500 0.500 0.500 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000 0.000 0.000 1.000 0.000) TextureList( 05 FF 128 128 128 0 1.000 "naam.bmp"5 FF 128 128 128 0 1.000 "asfalt.bmp"5 FF 128 128 128 0 1.000 "beton.bmp") VertexList( 0-72.464  0.000 75.224 0.000 1.000 0.000 -18.116 18.806-35.678  0.000 89.365 0.000 1.000 0.000 -8.920 22.34165.920  0.000 -65.848 0.000 1.000 0.000 16.480 -16.46242.222  0.000 -98.741 0.000 1.000 0.000 10.555 -24.685) SetMaterial( 0 1 )DrawTriList( 03 2 13 1 0):object_3_return Return :object_endEndA

This is only a small piece, only 3 of the origional 414 polygons in the source :). Then I also had more LayerCalls (that explains the different structure at the beginning, what seems a bit too complicated now).Also note that you let all the return labels point to the same :Fail label Dick, where I let it point to a label just behind the current objects. In your code all objects will dissapear if the first one is out of its range, where my code will let every object check for its own range.The rest of the code behind the RefPoints is not really relevant here, but in this case it are ground polygons (using the new floating point commands).Arno

---

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

[Guest GerrishGray]

Hi guysI thought I had better throw my tuppence into this one as my trees have been mentioned. My apologies if I am repeating any conclusions that the thread has already reached - I haven't been following it until now and so I may have missed some points in my quick scan of all the posts!I have always used the multiple RefPoint() method for placing my trees, using SCASM's 'displacement' syntax with or without GRP() as necessary. (Remember that GRP() is just an internal SCASM command that alters SCASM's internal record of the current RefPoint() position for use with the displacement syntax in RefPoint(). GRP() by itself doesn't do anything at all.)Any code without v1 and/or v2 values is always going to be slower than code that includes these values. M$ have warned us about this in the SDK, and also warned that code without v1 and v2 values (or zero values) may not even work in future versions. So any 'dirty tricks' that rely on zero v1 or v2 values are NOT a good idea.RotatedCall() and TransformCall() do much the same thing as a Transform_Mat() - they effectively 'transform' all coordinates (and vectors) in the affected code to move the object away from the RefPoint() and/or rotate it - they do NOT move the RefPoint() itself. The process is reasonably well described in their documentation, in fact, although I forget off the top of my head whether it is in the SDK or in comments in one of the BGLC include files ... The purpose of Transform_Mat() is to do the same thing in a more efficient fashion with less overhead than the older commands.Because shifting the RefPoint() eliminates ALL this extra work (unless one still needs to rotate the object about the RefPoint() axes), I don't think code that uses multiple RefPoint()'s is going to be much slower than the other methods (i.e. I agree with Arno on this logic) - who knows, it might even be quicker? And it has many advantages, e.g. (1) one can then use tight v2 values, (2) it minimises any effect on Autogen, so one doesn't need all these dirty tricks, (3) it prevents time being wasted on trying to draw objects that are actually off screen, (4) it's easier to write (and understand) the code.If rotation is required, then RefPoint() + Transform_Mat() is probably the best solution.The suggestion of merely moving (transforming/rotating) the xzy point coordinates manually has a serious drawback in SCASM - you can no longer rely on automatic vector calculation. TransformCall() / RotatedCall() / Transform_Mat() are NECESSARY to keep the vectors correct and get the right shading effects.Omitting PerspectiveCall() is a big NO-NO. This command is absolutely required for all 3D objects that are not part of the ground terrain - the object MUST be added to the radsort list if it is to be displayed correctly without bleedthrough or transparency errors. (The reason that your tests with AdvBldg() may have worked OK, Dick, is either because of the special nature of those objects and/or because the current BGL engine may be spotting the error and adding the object to the radsort list anyway - as we have discussed previously with other 'coding errors' ... but I doubt whether FS2004+ is going to have any such tolerance/correction of coding errors because the trend is to move AWAY from such additional overhead).I think you will probably find that you can place a block of my trees covering a large area with widely-spaced trees without eliminating the Autogen between the trees ... all with one macro in one Area() block, and with the individual trees each sitting correctly on the terrain mesh. But please let me know if this is not the case, because I have to admit that I haven't tested it myself :-) !!!CheersGerrish

[rhumbaflappy 113]

Hi Gerrish.I think you nailed it with the idea that AdvBldg() is of a special nature. I think these newer building types are different than normal objects. They seem to be unaffected by v1 or v2 references.My take on the future is different. I think FS2004 may actually eliminate the use of v1 and v2. Most placement of default objects in FS2002 are made with a v1 of 0, and displayable distance of all objects in FS2002 is already quite limited. I think the newer advanced buildings are not dependant on either value, but that might need some testing. FS2002 is much more forgiving of coding tricks than CFS2 or FS2000, that's for sure.Internally, I don't know if the v1 and v2 are "consumed" by a TransformCall, or if they remain on a stack or as an internal variable, until a Return is used. If that is the case, then the code is OK, and not just a trick, as we're just recycling the variables instead of restating them.For now, this only appears useful for the advanced buildings.The use of TransformCall can be viewed as an improvement of the RotatedCall, in some cases, as it can save autogen for large long buildings, where length is much longer than the width. The v2 ( radius ) would have to be large enough to encompass the object, but would knockout the surrounding autogen to the sides. By using a TransformCall ( even setting it's offset altitude incredibly high ) salvages the autogen, and still allows a large v2 to be used. This is also a trick, but seems to be one reason why MS included is use. I haven't decompiled default examples of TransformCalls, but I believe MS has used them, and may be the reason we have some objects that stubbornly resist exclusion in parts of the world.Dick

[Guest]

Hi Guys,Thank you all for such an interesting thread. I have been following the ideas and suggestions and yes, have come up with a solution.To explain, some time ago I wrote a kinda macro toolbox which allowed me to place taxiway line modules at airports. These modules of predetermined code worked like a model train set in that I could place a straight line followed by a left curve, straight line, right curve etc.This used the TransformCall extensively and before Autogen, worked just fine. My problem arose when I relised that this very same code was removing large areas of Autogen way beyond the airport perimeter.Below is the new code which is very simple but follows the suggestions ( kind of ) made in this thread. And it works just great. Thank you.;ASDesign Compatible Macro;Name=Lines1, Type=ASD, Bitmap=, ;FixedLength=100, FixedWidth=100, autoscale, ;Latitude, Longitude, Rotation, Scale=0.25, Density=3, ;Visibility=0, Range=5, Elevation=0 ;;Area( 5 %1 %2 %7 )IfVarRange( : 346 %5 4 )LayerCall( :L00019 24 )Jump( :L00020 ):L00019PerspectiveCall( :PC01 )Jump( : ):PC01PerspectiveRefPoint( 2 :SubEnd %4 %1 %2 E= %8 v1= %6 )RotatedCall( :B1 0 0 %3 ):SubEndReturn:B1; 80 ; 0 -32 0 -72 ; 1 -56 0 -56 ; 2 -72 0 -32 ; 3 -80 0 0 ; 4 -72 0 32 ; 5 -56 0 56 ; 6 -32 0 72 ; 7 0 0 80 ; 8 32 0 72 ; 9 56 0 56 ; 10 72 0 32 ; 11 80 0 0 ; 12 72 0 -32 ; 13 56 0 -56 ; 14 32 0 -72 ; 15 48 100 48 ; 16)IfVarRange( :y 382 0 300 )IfVarRange( :y 28C 2 4 )RGBSColor( E1 131 116 116 )ShadedPoly( ai 15 16 0 )ShadedPoly( ai 14 16 15 )ShadedPoly( ai 13 16 14 )ShadedPoly( ai 12 16 13 )ShadedPoly( ai 11 16 12 )ShadedPoly( ai 10 16 11 )ShadedPoly( ai 9 16 10 )ShadedPoly( ai 8 16 9 )ShadedPoly( ai 7 16 8 )ShadedPoly( ai 6 16 7 )ShadedPoly( ai 5 16 6 )ShadedPoly( ai 4 16 5 )ShadedPoly( ai 3 16 4 )ShadedPoly( ai 2 16 3 )ShadedPoly( ai 1 16 2 )ShadedPoly( ai 0 16 1 )ShadedPoly( a 15 16 0 )ShadedPoly( a 14 16 15 )ShadedPoly( a 13 16 14 )ShadedPoly( a 12 16 13 )ShadedPoly( a 11 16 12 )ShadedPoly( a 10 16 11 )ShadedPoly( a 9 16 10 )ShadedPoly( a 8 16 9 )ShadedPoly( a 7 16 8 )ShadedPoly( a 6 16 7 )ShadedPoly( a 5 16 6 )ShadedPoly( a 4 16 5 )ShadedPoly( a 3 16 4 )ShadedPoly( a 2 16 3 )ShadedPoly( a 1 16 2 )ShadedPoly( a 0 16 1 )RGBSColor( E4 131 116 116 )ShadedPoly( a 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ):yReturn:L00020EndASo The only change that I made was the additional RotatedCall. I have to admit that I do not fully understand why this works and as Gerrish mentioned is not conventional SCASM code. But I have tested it and it works just fine. Go figure.Regards,Tosh

[rhumbaflappy 113]

Hi Tosh.I'm glad you've got it working.Your code now makes me think that this will work as long as we don't try it with a library object.Perhaps the TransformCall has more differences than just the relocation of the refpoint, and is possible for repeated calling, as well. I haven't seen any problems with the advanced buildings, nor any problems with the sim bogging down using the call this way... apparently non-library objects are also fine, as your code indicates.The final "Dummy" RotatedCall makes it all 'legal', and it works in CFS2 and FS2002, as well.I don't know if placeing multiple effects would be possible with this method, but that would be handy.Gerrish is right about the PerspectiveCall() ( ADDOBJ(0x32) in BGLC ), But it wouldn't be the first time the SDKs were incomplete, or outright wrong about something. :)Dick

[Guest GerrishGray]

Hi guysAs regards the v1 and v2 values, they are used directly at the time of the RefPoint() command and are not used or altered in any way at all by the subsequent code.The RefPoint() (SCALE) command establishes the 'reference point' and scale to be used for the following drawing sequence. Before proceeding to the drawing commands it does two visibility checks:[ol][li]If there is a v1 value, a check is made as to whether the new reference point is within the v1 range from the current viewpoint - if not the code jumps to the 'fail' label and thus does not try to draw the object. However, this process may have been complicated by the new frame rate optimisation code, and has also always tended to be somewhat obscured by other factors that may also affect the visibility of the object, e.g. scaling used to have a severe 'culling' effect on visible range, as we know, although that seems to have disappeared in FS2002.[/li][li]The second check is whether the current reference point is visible on screen, and again the code jumps to the fail label if not. This requires a v2 value because the whole of a sphere centered on the reference point and with the v2 radius is actually checked - the fail jump is only made if no part of this sphere is located on screen. This prevents the extremities of objects being prematurely culled when the actual reference point is off screen but some parts of the object are actually on screen. Omitting this check results in time being wasted trying to draw the object even when it is completely off screen![/li][/ol]These v1/v2 checks 'know' absolutely nothing about the drawing code that follows, and don't need to. The values are not used in any way by following code - they have served their purpose as soon as the RefPoint() command has been executed.IMHO, it is most unlikely that M$ would want to drop this functionality - to do so would presumably slow frame rates severely because the engine would waste endless time trying to draw invisible objects. That, surely, is precisely why they emphasised the importance of these values in the FS2000 SDK. Of course, the eventual release of FS2004 will probably prove me wrong ;-)Tosh, there are, with respect, one or two errors in your example code:[ol][li]The initial IfVarRange() check should read IfVarRange( : 346 %5 5 ) or even IfVarRange( : 346 %5 32767 ) - as you have written it your scenery will not be visible if the user selects 'Extremely Dense' for the Scenery Complexity setting in FS.[/li][li]You should not have both LayerCall() AND PerspectiveCall() for the same object. LayerCall() places the object into a stack evaluated on a layering priority basis for objects lying on the ground (i.e. ground polygons etc.). PerspectiveCall() places the object onto the 'radsort' stack that uses z-buffering to establish the correct drawing order for objects/surfaces above the ground. Remove the PerspectiveCall() and associated Return & label - it is superfluous and NOT appropriate for ground polygons / taxiway lines etc.[/li][li]The Perspective command after the :C01 label is obsolete and completely superfluous these days, it is just ignored as a 'no operation' by the BGL engine. Remove it.[/li][li]You have not included a v2 value in your RefPoint() - this is not a good idea, as I have explained above. Even a fairly large value is better than none at all and will help keep frame rates as high as possible (providing that it doesn't kill the Autogen-preserving effect of JR's dummy RotatedCall() - I haven't checked!).[/li][li]You are making extra work for the engine by having a separate RotatedCall( :B1 0 0 %3 ) after the RefPoint() as well as the subsequent TransformCall()'s. Get rid of the four lines from the RotatedCall() to the :B1 label and modify the TransformCall()'s to include the %3 rotation as well as the other displacements. You will need to adjust the 'fail' label in the RefPoint() to take account of this.[/li][li]The ConcavePoly is unnecessary - the polygon is not concave! It wastes time. If the polygon WAS concave, the SDK advises that it is better to split it into a number of convex polygons rather than use ConcavePoly because you are making the BGL engine calculate the correct 'triangulated' drawing sequence every time it draws the polygon at runtime, when you could do it yourself at design time and save FS all that extra (and repetitive) work![/li][li]And finally ... Yes! :-) the reason why John Morgan's discovery of the dummy RotatedCall( :y 0 0 0 ) works to preserve Autogen is a bit of an oddity - but strangely it does seem to do the trick (as an alternative to separate RefPoint()'s as suggested elsewhere ...)[/li][/ol]Hope this helps a bit :-)CheersGerrish

[Guest GerrishGray]

Hi DickI don't understand why you think that library objects are in any way different as far as this discussion is concerned. I can see no logical reason why this should be the case, and it is certainly not true in the case of my Trees Library - although that is certainly not an exhaustive test of all possibilities. All you are doing with a library object is replacing the direct drawing sequence in the section 9 code with a call to a section 10 'subroutine'. I don't see how this affects the structure of the rest of the code, although I suppose it is conceivable that it might have some effect on the Autogen hit (because we don't know exactly how that is done - M$ say that it is done on an 'object-by-object' basis but it is unclear what exactly they mean by "object" in this context). The 'advanced buildings' are possibly a slightly different case as they use 'built-in' code in G3D.DLL that is conceivably somewhat different to normal BGL code - has anyone disassembled G3D.DLL to see how it works?Incidentally, my remarks about how Autogen-culling actually works are rather fundamental to this thread, I suppose. There has been an implied suggestion that it works from the RefPoint() and the v2 value, but I don't see how that can be the case when the v2 value can be omitted anyway (even if doing so isn't best practice!). I think that the Autogen-culling must be somewhat closer to the actual drawing process than that. This is also born out by JR's odd, but effective, trick with the 'dummy' RotatedCall().CheersGerrishPS (This is an edit!): Sorry Dick, perhaps all you meant was that JR's 'null' RotatedCall() doesn't work if the intervening drawing was done with one or more library object calls? Maybe the null RotatedCall() would need to be within the section 10 library object in this case - which would seem to tie it even closer to the drawing sequence. It is perhaps not insignificant that the header of a section 10 object includes provision for 'range'/'power' and v2 (size) values - I had assumed that these were porbably unused at present, but maybe this is not the case). But the best solution of all is probably to use separate, and correctly-coded, RefPoint()'s anyway, as we have been suggesting earlier.