TransformCall

[Guest]

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

[rhumbaflappy 113]

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

[Guest]

Thanks Dick, I will give it a try.Regards,Tosh

[arno 1]

>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]

[rhumbaflappy 113]

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

[arno 1]

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]

[rhumbaflappy 113]

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

[arno 1]

>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]

[rhumbaflappy 113]

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

[arno 1]

>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]

[Guest JR Morgan]

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.

[rhumbaflappy 113]

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

[Guest JR Morgan]

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.

[rhumbaflappy 113]

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

[Guest JR Morgan]

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.