Sign in to follow this  
wsieffert

TransformCall

Recommended Posts

Can anybody recommend an alternative to the Scasm command "TransformCall".I have noticed that its use seems to obliterate Autogen for some distance around.Regards,Tosh

Share this post


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

Hi Tosh.Check out this:http://ftp.avsim.com/dcforum/DCForumID10/1785.htmlIn that thread, TransFormCall is used to save the autogen... not exclude it.If the parameters of any call are wrong, it can cause autogen problems. Just like the more commonly used RotatedCall can cause problems if the v2 radius if too large, or the shape of a large object forces the radius to be oversized in one dimension. TransformCall is not commonly used, so you may be confusing it with RotatedCall.9 times out of ten, RotatedCall is the proper way to call the object...just keep the v2 radius tight to the object.Here's a large building object actually slicing an autogen in half, using the TransformCall to relocate the apparent RefPoint vetically thousands of meters away from the autogen. In this example, I made the V2 huge... to show how it can be compensated by TransformCall.Dick

Share this post


Link to post
Share on other sites

>TransformCall is not commonly used, so you may be confusing >it with RotatedCall. Just a little addition, this is not true. VOD/NOVA (and maybe also EOD not sure about that), use the TransformCall a lot. In my opinion this is a waste of calls, because you can better shift the points in the point table to the correct coordinates and save the additional call.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 wasn't aware those programs use the call so much!I think you're right, it does seem excessive...why not just use a RotatedCall if the object needs a rotation for the placement? And if it needs no rotation, just leave that call out.If those programs use TransformCall, then they are moving the 'apparent' RefPoint around on the surface of the ground, and could really be messing up the autogen. The primary control we have over the autogen exclusion is the v2 radius, and the TransformCall could be moving that away from the object...causing us to loose control of our v2.Maybe Rafael ( of NOVA ), will see these posts, and help us understand his use of TransformCall.Dick

Share this post


Link to post
Share on other sites

The usage of the TransformCall is not as bad as you say now :D.They are used to transform a certain object around. Let's say you have an object made of two boxes, then for each back a point list is made around some sort of local reference axes (but not a seperate RefPoint) and those are then transformed to the correct location in the scene.Also it is used sometimes to place the same object a multiple of times. Then you just create the source once and then transform it a certain amount of times to the places you want it to be. If this is faster then making more point tables I don't know.And as long as you set the v2 value in the RefPoint at such a value that it covers all the objects (keeping the transformation in mind), then it should not mesh up the mesh that much :).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.But as you describe it, there is a problem with the use of the TransformCall, isn't there?A row of 10 objects, each with a 2 meter radius, placed in a row 100 meters long using TransformCall... But using the TransformCall as you described it, now there would be 1 v2 that is 50 meters in radius, to envelope all the objects, and the autogen effect could be very noticable. In effect, we now have a composite object that is 2x100 meters, and the radius of large rectangular objects is a problem we've discussed before. You can't tighten the v2 any closer then the longest dimension, or you'll get 'flashing' of the objects.If each object were placed sepatately, without TransformCall, then there would be 10 different 1 meter v2 settings... and there would be almost no autogen exclusion.If that is true, then the problem is not TransformCall at all, but the excessive radius of the v2 parameter, needed to envelope all those objects. The solution is to have a separate, tighter, v2 for each object... and not use TransformCall for a large rectangular grouping of objects. ( or just ignore the results on the autogen )This is exactly the problem with runways... their large rectangular size and need for a large, round radius of exclusion kills the autogen for many meters to the sides of the runway. And there appears to be no cure for that.===================Meanwhile, I gues we'd need to see some code from Tosh, to see how TransformCall is causing problems for him.Dick

Share this post


Link to post
Share on other sites

>If each object were placed sepatately, without >TransformCall, then there would be 10 different 1 meter v2 >settings... and there would be almost no autogen exclusion. Yes, I must agree here. But then we are not talking about the TransformCall or not. You could also make the same object without the TransformCall, used by making more point tables and polygon commands. In that case you would still have the same problem.Then the discussion is about splitting a collection of objects bundled into one RefPoint or not and I agree that from the autogen point of view it is then better to use seperate objects. What this does to the performance I don't know, it means more RefPoints.>This is exactly the problem with runways... their large >rectangular size and need for a large, round radius of >exclusion kills the autogen for many meters to the sides of >the runway. And there appears to be no cure for that. Not sure, a Runway has no RefPoint command in front. But maybe something like the v2 value is hardcoded or so.>Meanwhile, I gues we'd need to see some code from Tosh, to >see how TransformCall is causing problems for him. Yes, that should be interesting to see.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'd also be interested to see the effects of one refpoint for a group of objects as you have described them, with one large v2, and many separate objects placed by individual refpoints, and many smaller v2.I have a suspicion it will make little difference to the sim, as the main problem is not the number of RefPoints, but the number of facets displayed.Am I right in then assuming TransformCall is an easy method to allign a collection of objects, that may not allign so easily when placed individually? And the v2 must be large enough to cover the whole group, not just each object individually?Dick

Share this post


Link to post
Share on other sites

>I have a suspicion it will make little difference to the >sim, as the main problem is not the number of RefPoints, but >the number of facets displayed. I think you are right, but I am not sure what the influence of a extra RefPoint is on the overhead workload of the scenery engine. On the other hand, the fact that the v2 value is talormade for the object means that the performance is increased a bit again. I think the total effect will not be that big.>Am I right in then assuming TransformCall is an easy method >to allign a collection of objects, that may not allign so >easily when placed individually? And the v2 must be large >enough to cover the whole group, not just each object >individually? Don't know. If you use the GRP and let SCASM do the calculations you can get offset just as easy with a RefPoint command as with a TransformCall command (only you need a RotatedCall after it if a rotation is needed and with a TransformCall that's all in one).For a TransformCalled group the v2 value must indeed cover all objects in the current RefPoint.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

Tosh, Dick & Arno:Here's a macro I use to place 52 AdvBldg houses without any penalty to default autogen. The reason for this macro is there's only 1 autogen house in the default scenery and since it's a small town, it needs more houses BUT also needs to retain the default trees. The macro is written for SCASM 2.88. The DUMMY RotatedCall at the end of the macro is the feature that retains the native (trees) autogen:3e2ef2ff12e9e412.txt,3e2ef32013bba04c.txtI don't notice any penalty of frame rate. Sureley there must be some, but in my (not state of the art) system it's not at all bothersome. Note in the macro that there's only one Area( and RefPt call and the V2= value is small. 'Will attempt to also attach jpg pic of the scenery result below:3e2ef2ff12e9e412.txt,3e2ef32013bba04c.txt,3e2ef55e229eca67.jpgI think a macro similar to this will help Tosh's problem.The Dummy RotatedCall is your friend !'Regards;J.R.

Share this post


Link to post
Share on other sites

Hi J.R.I understand the code pretty well, I think. :)First object is called via RotatedCall, then a chain of TransformCalls to add objects around the refpoint of the first onject, with a final RotatedCall that doesn't call anything ( the Dummy ).These are nested calls, so the Returns don't get triggered until the DummyCall, near the end of the code.Then the "Returns" cascade back to the eventual Jump( : ), which jumps to the "ENDA".Without the last RotatedCall, the AGN is destroyed? And what about the radius around the first object ( that has the v2 of 45 )... is that autogen destroyed, or is it exempt as well?I think the framerate drag will be not more than the autogen, as these are very simple objects, so not many facets are required to construct them. I don't think it's the number of objects so much as the number of facets in those objects that causes problems with the sim.You might not need the ShadowCall. My crude experiments with these types of objects showed shadows without making any ShadowCall.This does look like a good way to create an autogen-like display in the autogen "death-zone" surrounding our runways.Now I'm starting to think about Gerrish's trees, and dummy calls. ==========On a side note:I looked at how MS called the static planes in the Oshgosh scenery, and they placed each one separately with a RotatedCall in this format:Area( A N43:58:32.07 W088:34:30.86 100 ) IfVarRange( : 0346 4 32767 ) CrashIndirect( :_Library-Object :_Placement :_Orientation 0 0 ) ShadowCall( :_Placement ) PerspectiveCall( :_Perspective ) Jump( : ) :_Perspective Perspective :_Placement RefPoint( rel :_Fail 0.50 N43:58:32.09 W088:34:30.86 V1= 0 V2= 40 ) :_Orientation RotatedCall( :_Library-Object 0 0 270 ) :_Fail Return :_Library-Object CallLibObj( 0 558A197A 459DBD2B 6D53018F 4D84570E ) ReturnEndA============That MS code looks like it would be more difficult to align the objects than using the TranformCall chain that J.R. shows. But they might have a more advanced CAD-like program to place objects... maybe not.Dick

Share this post


Link to post
Share on other sites

Dick.. Yes, this is simple rudimentary SCASM I think, except for the dummy rotated call.>>Without the last RotatedCall, the AGN is destroyed?<<**Definitely Yes without the "Dummy".>>And what about the radius around the first object ( that has the v2 of 45 )... is that autogen destroyed, or is it exempt as well?<<** It is also exempt. Not a single M$ default tree is lost using this macro.**I would urge you and others to test the macro by locating it in a location densely populated with trees and watch the AGN trees "grow" through the houses. The beauty of the TransformCall strategy here is that you can "nudge" houses out-of-the-way-of (but still pleasingly nearby) the default AGN trees:-). Such test should involve commenting-out the DUMMY RotatedCall line of code (only) and see the effects; Then, un-comment the same line of code and watch the trees come back.Yep, I'd bet my bottom that M$ definitely has such CAD-like softwares to assist such placings of lib objects as you viewed at Oshkosh. I've not tried the TransformCall routine on lib objects but it stands to reason that it would work fine.Thanks; J.R.

Share this post


Link to post
Share on other sites

Hi J.R.I think I've found an improvement for your code:

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  )	RefPoint(  7  :S1  1.00  N42:38:01.78  W088:36:33.00   V1 = 0  V2 = 0 )	TransformCall(  :R0  000 32767 000  0 0 0 0 0 0 )	Return	Jump(  :  ):R0	 AdvBldg( PEAKED 40 20; Bldg 1; RefPt 			  LEVEL1 27 5 128 128			  LEVEL2 0 0 256 256 256			  LEVEL3 0 0 256 256			  ROOF 9 256 256 7 256 )	TransformCall(  :R1  100 000 000  0 0 0 0 0 0 )	Return.......

then at the end, for the dummy call:

.......:R52	AdvBldg( PEAKED 40 20; Bldg 52 100 east-1120 south			  LEVEL1 27 5 128 128			  LEVEL2 0 0 256 256 256			  LEVEL3 0 0 256 256			  ROOF 9 256 256 7 256 ); 7 was 2;Use a TransformCall as the Dummycall	TransformCall(  :RR  000 32767 000  0 0 0 0 0 0 ); 	 Return:RR:S1	ReturnEndA

This isn't in API form, as you can tell, but it should be understandable. You don't really need the PerspectiveCall, or ShadowCall, or even the IfVarRange ( but that does no harm ). I eliminated all the RotatedCalls, just for fun. Everything is TransformCalls. Note that v1 and v2 are now meaningless. I used an altitude of 32767 to avoid any possible troubles with autogen. The RefPoint places the objects AGL. No detectable framerate hit.I included a pic to show the effects of not cleaning maple seeds from your rain gutters. :-lol Dick

Share this post


Link to post
Share on other sites

OK, very good Dick. Let me revise my macro as you suggest and report back. As you say, it should take a few op-cycles out of the "engine's load".Thanks;J.R.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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]

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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]

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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]

Share this post


Link to post
Share on other sites

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

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