Jump to content
Sign in to follow this  
wsieffert

TransformCall

Recommended Posts

Hi Gerrish.In a different thread, we had established that an oversized v2 will exclude autogen. But an oversized v2 can be used if the object is called via a TransformCall. I used an exaggerated altitude of 32767 meters for the offset, and a huge v2, and the object placed has zero effect on the autogen.The problem with library objects, seems to be with multiple "chained" TransformCalls... they "pop" in and out of the scenery, at least in my test.Checking effects...I'm attaching the code for multiple TransformCall chained fireworks.Dick

Share this post


Link to post
Share on other sites
Guest JR Morgan

Hi All...Primarily, I just want to thank all you experienced programmers for your test reports, examples of 'better than me' programming and informative comments on this thread. It's been a rewarding, educational experience.I guess My only comment at this point is that I've enjoyed hacking-on 'conventional' SCASM'ese and make no apologies for doing it, since it was inspired by a need and has served a purpose; in this case, retaining AGN previously destroyed by things like hungry added scenery objects, 'possibly oversized' V2 values, invisible runways and on-and-on (even the SurfaceType). For example, the AdvBldg macro that Dick assisted me on appears to be working beautifully on my system, with no detectable (to me) hit on performance. If anything, the frame rates seem equal-or-better than the previous 'long-form' macro I'd started with and actually, frames seem to fluctuate less than before. I intentionally left V1 and V2 definitions out of the RefPt code to see what would happen and so far am pleasantly surprised --- Why? --- I simply don't know. Of course I also don't know why the 'Dummy' rotated and/or transform calls seem to preserve AGN :-).I truly appreciate the views and help of people like Dick, Gerrish, Arno and all who participate here because to me, it's a valuable learning experience. LOL, these topics can get 'so-seriously-toned' but in my case, I try to just remind myself that It's a Hobby, not a paycheck situation :-).I feel I now need to try some floating-point macros and I would like to 'attack' BGLC -- someday, especially if it forces SCASM FP out of the picture in the future. This is still a fairly important 'if', to me. I'll just have to wait and see what develops. I just don't know for sure what's best, unless support of SCASM is discontinued -- Unless someone picks-up-the-ball and continues supporting it. I had some good results using (the first) FSC but it was on very simple macros and later proved unacceptable on more complex macros. However, since it's open source code, things could improve there? If M$ is totally dedicated to use of BGLC then I think our decisions must certainly be weighted by that fact.I purchased the latest Nova release so that I could get some experience with it's FP add-on, however, because of family commitments, holiday activities and being a basic procrastinator :-), I didn't get to it in time before the end of year 2002 limitation on it expired :-(.Along that line I'd sure appreciate it if anyone would advise me if the following applies in writing FP code for SCASM; i.e. do the following 'pre-header' header opcodes: Set( fsvers 0x*** ); For FS version selectivity only (not a FP requsite)? Set( buf 1024 ); Reserves compiler space for the longer FP strings? Set( areamx 1024 ); Gears the Sim to expect FP instead of intergers?suffice to enable SCASM 2.88 for FP compiling things like elevations (%11) and of course other object controls now restricted to interger numbers? Or are there other prerequsites? -- And are the above commented rems correct assumptions? I thought I had seen this info before but for the life of me, I can't seem to find it now.Thanks Again.Regards; J.R.

Share this post


Link to post
Share on other sites

I assume you took these 3 lines from the example I posted above? :)>Set( fsvers 0x*** ); For FS version selectivity only >(not a FP requsite)? This sets SCASM so it uses the code for Fs2002. Without this line it will not work! You'll get an error that the FP code is not recognised.> Set( buf 1024 ); Reserves compiler space for the longer >FP strings? Nope, this is only because I got a buffer overrun error (this is only a small portion of code from a big file).>Set( areamx 1024 ); Gears the Sim to expect FP instead >of intergers? Also not necesairy for FP. It's just that my Area block is bigger then 32 kB and then you need this command to increase it (and don't get errors).I think the rest of my above code shows an example of how the FP commands can work for ground polygons.I know the creator of GroundMaker is also adding this codes to his program.At first I thought BGLC might be the future, but just recently I redesigned my DXF2SCA tool so it doesn't produce BGLC code anymore, but nice old SCASM code again :). The SCASM code is just easier to work with (it has the reference point calculation with an offset for example).I think as long as SCASM is update it will surely have a future. Maybe FSC is even better, I download it (and the source some time ago), but untill now I haven't had the time to look at it and see how easy it is to add new commands like the FP (and mesh?).Arno


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

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

>The problem with library objects, seems to be with multiple >"chained" TransformCalls... they "pop" in and out of the >scenery, at least in my test. What do you mean with pop in and out? You mean that they are visible sometimes and sometimes they are gone?This sounds a lot like a wrong v2 value to me. And looking at the previous examples that makes sense, as there you used a v2 value that was much smaller then the total radius that includes all the transformed objects.Arno


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

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

>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!).Want to say just again that I agree here :). My test have showed that using a correct v2 value can really improve the frames a lot.In my last tests I split a large collection of polygons from all having the same RefPoint into each a seperate RefPoint and that double the frames in certain conditions (with not all polygons visible of course, because then the v2 comes into effect).>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!This is clear. With the FP commands you can only make triangles. So then you'll have to do the triangulation yourself. It's clear that this is the way we have to go.Arno


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

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites
Guest GerrishGray

Hi guysArno: Thanks for your confirmations. I am particularly interested in your test results suggesting that using multiple RefPoint()'s can actually be QUICKER than the use of multiple TransformCall()'s.-----------------Tosh: The end conclusion for your original question about the best alternative to a chain of TransformCall()'s is to use separate RefPoint()'s taking advantage of SCASM's convenient 'relative displacement' syntax to calculate the new Lat/Lon positions. A couple of points to note are:[ol][li]The multiple RefPoint()'s can all be contained in one LayerCall() (OR PerspectiveCall(), as appropriate), as long as one doesn't get too ambitious trying to cover a large area that really ought to be split into separate blocks![/li][li]Setting a new RefPoint() does NOT alter SCASM's internal record of the original reference point location. All displacement calculations in successive RefPoint() calls are relative to the ORIGINAL location, unless you use GRP() to move that location.[/li][li]Don't forget to include the v1 and v2 values in EVERY RefPoint() call - they are NOT remembered from one chained RefPoint() to the next as the example in the SCASM documentation seems to imply! If you are using absolute (type 2) RefPoint()'s, you will also need to repeat the elevation setting each time as well.[/il][/ol]This technique will normally ensure the correct preservation of Autogen as long as one can avoid 'funny stuff' like large 'underground' ground polygons etc. But if you DO still have a problem with loss of Autogen, then make use of JR's discovery of the 'null' RotatedCall().Arno has given an example of how to construct the code using this technique earlier in this thread, and further examples (admittedly a bit difficult to understand!) can be seen in the macros accompanying my Trees Library (see the trees_v3.zip download from this site).-------------------All of this is just as applicable to FP programming as it is to the old style. The only exception is that the apparent speed advantage of multiple RefPoint()'s may not be so great as compared with multiple TransformCall()'s if one uses the more efficient Transform_Mat() structure in place of TransformCall() (but my point about terrain mesh altitudes still mitigates in favour of the RefPoint() method if one is not working on a flattened airfield area). Incidentally, as regards SCASM, FP programming, and 'the future', the only reason that we haven't seen any upgrade to SCASM for some time is that it doesn't need one - it is already fully functional for everything in FS2002 and for the FP command set. All that is presently missing is the facility to do 'section 8' stuff for TMF/LWM/VTP. Contrary to earlier fears, I think we will probably find that Manfred is still supporting SCASM and has every intention of updating it as necessary. If you have looked at the web site recently, it has been updated with a web version of the current documentation, for example ...CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish,>Arno: Thanks for your confirmations. I am >particularly interested in your test results suggesting that >using multiple RefPoint()'s can actually be QUICKER than the >use of multiple TransformCall()'s. That's the only test I didn't make :). I had all my polygon in one source before. Like this:

Area() RefPoint() VertexList()TriDrawList() VertexList()TriDrawList() VertexList()TriDrawList() ....

I think in principle this code is faster then adding a extra TransformCall. I didn't need the TransformCall here, as I just transformed the individual point lists.Now I have changed it in code like this:

Area() RefPoint( d x y)VertexList()TriDrawList() RefPoint( d x y)VertexList()TriDrawList() RefPoint( d x y)VertexList()TriDrawList() ....

When I have the entire airport in view (this are ground polygons, but the theory should be the same) there is no real difference between the two methods.But when I place the aircraft on the apron itself (in this case not everything is visible of course) I get the (big) framerate increase (this is because every polygon has now its optimal v2 value, resulting in all not visible ones not being drawn.>The multiple RefPoint()'s can all be contained >in one LayerCall() (OR PerspectiveCall(), as appropriate), >as long as one doesn't get too ambitious trying to cover a >large area that really ought to be split into separate >blocks!Agree here. This is the same thing I have done. One Area and only a few LayerCalls (2 at the moment in my code) and those had a total of 414 polygons with each an own RefPoint in it.>Incidentally, as regards SCASM, FP programming, and 'the >future', the only reason that we haven't seen any upgrade to >SCASM for some time is that it doesn't need one - it is >already fully functional for everything in FS2002 and for >the FP command set. All that is presently missing is the >facility to do 'section 8' stuff for TMF/LWM/VTP. Contrary >to earlier fears, I think we will probably find that Manfred >is still supporting SCASM and has every intention of >updating it as necessary. If you have looked at the web >site recently, it has been updated with a web version of the >current documentation, for example ...I agree here. At the moment SCASM allows the FP commands and that's enough for the moment. It would be really great if mesh could also be added to it.Arno


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

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

Hi J.R.I'm usually the one guilty of pushing discussions of code to the 'serious' level, as I usually break so many coding conventions, that more experienced programmers just can't let me get away with it!;)But you and Tosh have given us an interesting subject to explore. I'm amazed that stringing TranformCalls, and terminating them with a dummy RotatedCall works at all! But it does work.. and pretty well.Your original example was an eyeopener... I reorganised it to see if there was an easier way to list the TransformCalls, and make the typing easier, and at the same time to reduce the code to a 'nugget' that was as compact as I could make it. I hope you can use that down the road.I don't profess to know why the AGN is preserved with this method either... but it is... and that was Tosh's original problem, and with your help, I think he solved it.I haven't seen anything bad happen in the sim with the use of this technique, and the framerates seem fine. I'm satisfied the technique works with advanced buildings, defined objects, and effects. I think library objects may have a problem with this.The SCASM docs caution about getting too far away from the Refpoint... I haven't pushed that limit, but we may have some surprises there as well... I'm guessing 32767 meters. I also don't know what happens closer to the poles, as the longitudinal widths narrow. That might also be interesting.:)Dick

Share this post


Link to post
Share on other sites

Hi Arno.I found that there isn't a need to fear clouds showing through the buildings... They are quite solid. :)So, we need a warning to use this 'Chained TransformCall with DummyCall' technique on FLAT ground, as the refpoint is set for the first object.Odd how even the shadows are fairly solid from underneath. :-lol Dick

Share this post


Link to post
Share on other sites
Guest JR Morgan

LOL, how much for the penthouse on the right? Yep, there should be a note added to always place on a flattened area --- On the other hand, how're we gonna modify this macro so that the houses will be Mesh-Clinging like the default AGN? J.R.

Share this post


Link to post
Share on other sites

This makes me think that the default buildings are processed different then other 3D objects. I know we had similar problems with our forests (3D boxes) in the NL2000 scenery when one team member had forgotten the PerspectiveCall.Arno


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

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

If you use a seperate RefPoint for each building and set the type to 7 then every building will be at the altitude of the mesh on its RefPoint.Arno


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

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

Share this post


Link to post
Share on other sites

Hi J.R.The attached file works. It's not in API format, but you should have no trouble with the translation.It incorporates some of Arno's ideas. I do believe it could be further 'reduced', and I'll try to simplify the typing further.Here's an abbreviated code:

; ----------------------------------------; Interlaken grouped   N46* 43.39'   E7* 53.97'; ----------------------------------------Header( 1  N46:43:23.53  N46:43:23.53  E007:53:58.30  E007:53:58.30  )LatRange(  N46:43:23.53  N46:43:23.53  )Area(  5  N46:43:23.53  E007:53:58.30   10  )  GRP(  N46:43:23.53   E007:53:58.30  )  RefPoint(  rel  :Fail  1.00  d  0  0  )  Call( :House1 )  RefPoint(  rel  :Fail  1.00  d  0 100  )  Call( :House2 )  RefPoint(  rel  :Fail  1.00  d  0 200  )  Call( :House1 )  Jump(  :  ); Buildings -------------------:House1  PerspectiveCall( :House1Dummy ):House1Dummy  RotatedCall(  :Fail  0 0 0   )  TransformCall(  :House1draw  000 000 000  0 0 0 0 0 0 )Return:House1_90  PerspectiveCall( :House1_90Dummy ):House1_90Dummy  RotatedCall(  :Fail  0 0 0   )  TransformCall(  :House1draw  000 000 000  0 0 0 0 90 0 )Return:House2  PerspectiveCall( :House2Dummy ):House2Dummy  RotatedCall(  :Fail  0 0 0   )  TransformCall(  :House2draw  000 000 000  0 0 0 0 0 0 )Return:House2_90  PerspectiveCall( :House2_90Dummy ):House2_90Dummy  RotatedCall(  :Fail  0 0 0   )  TransformCall(  :House2draw  000 000 000  0 0 0 0 90 0 )Return:House1draw  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:House2draw  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:FailReturnEndA

There is no v1 or v2 defined in the RefPoint(), but I don't think adding it would be harmful, as long as the v2 is small enough so that it doesn't affect the autogen. If the v2 is fine, then you wouldn't need the DummyCall.I know this still breaks some of the rules, but I'm not convinced those rules are necessary here.Dick

Share this post


Link to post
Share on other sites

Hi Dick,Some comments.First I would use a structure like this:

Area()GRP()PerspectiveCall( :L1 ) :L1RefPoint( 7 :F1 1 lat lon v1 v2 )AdvBldg():F1 RefPoint( 7 :F2 1 lat lon v1 v2 )AdvBldg():F2 RefPoint( 7 :F3 1 lat lon v1 v2 )AdvBldg():F3 ...EndA

[ul][li]This way you only have 1 PerspectiveCall[li]Depending on the amount of different buildings it could make sense to put the AdvBldg commands seperate and call them after the RefPoint.On the other hand, I don't know what the effect of those extra calls is on the performance compared to the bit of extra code.[li]The v1 and v2 are very important, so I won't say adding them wouldn't be harmfull, I would say forgetting them is harmfull.[li]If the building needs to be transformed (rotated), a TransformCall or Transform_Mat might even be better, can be added before the actual building code.[li]Last thing, I let every RefPoint point to its own fail label. That way not all objects will disapear when the first one is out of range.[/ul]Arno


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

Arno

If the world should blow itself up, the last audible voice would be that of an expert saying it can't be done.

FSDeveloper.com | Former Microsoft FS MVP | Blog

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  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...