Jump to content
Sign in to follow this  
arno

Vector autogen bridges in Ground2K scenery for FS2004

Recommended Posts

Guest JR Morgan

Thanks Gerrish... Here's the macro with test report:; Test macro using SCASM TransformCall on FS9 AGN Bridge Library Objects.; uses Terrain.cfg object "Dual Hiway Bridge - gen_bridge07" objects; "AutoObject" and "AutoObjectEnd". Test Result: Only the first; Object in the list of transformcalls is drawn in FS... Apparently, although; TransformCall fails to offset AGN objects in delta_XZY axis from the RefPt,; it does accomplish object rotation around the RefPt similar to a; RotatedCall by using the #_deg parameter of TransformCall. Conclusion based; on this test is that an abs referenced RefPt macro must be used for each individual; object comprising a multi object bridge of this nature. Possibly, a TransformMat; macro could be devised to to display multi-AGN-objects displaced from a single RefPt? Area( 5 %1 %2 %3 ) PerspectiveCall( :P0 ) ShadowCall( :P0 ) Jump( : ):P0Mif( %11 ) RefPoint( Abs :Fail %4 %1 %2 E= %11 V2= 2200 V1= 100 ) Melse RefPoint( 7 :Fail %4 %1 %2 V2= 22 ) Mifend;Trying TransformCall to Displace LibObjs relative to above RefPt:R0; Notes: For this test, X axis offsets are arbitrary and not to bridge object scale.; Obj1 is bridge center span segment; Obj2 is bridge end object. Commenting-out first; TransformCall below displays bridge end segment rotated 180 degrees, proving the first; call works, however, only the first call is ever displayed in FS. TransformCall( :Obj1 000 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj2 -30 %11 000 0 0 0 0 180 0 ); Left end of bridge rotated with #_deg parameter TransformCall( :Obj1 45 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj1 60 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj1 75 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj1 90 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj1 105 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj1 120 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj1 135 %11 000 0 0 0 0 0 0 ) TransformCall( :Obj2 150 %11 000 0 0 0 0 0 0 ); Right end of bridge (#_deg=0) ;:Fail ; Results seem to be the same with this label placed here or as below Return; Library objects:Obj1CallLibObj( 0 18b2918f 497c11d1 f2a2c0b5 65e56362 ); bridge07 main span object Return:Obj2CallLibObj( 0 2d7d189a 43f3f0e5 75d03fb7 6b7a4ef8 ); bridge07 end object Return:Fail ReturnEndA;Regards;J.R

Share this post


Link to post
Share on other sites

This is very strange. I tested it and it does indeed not work. I also tried it with mulitple RefPoint (with the d option to let SCASM calculate the new position) and also that didn't work.Then I changed the library object to one of my objects and tada it works. So it is something in the MS object. I haven't figured out what it is.


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 guysYes, there is clearly something that we don't understand going on here. Thanks for having done the testing Arno. Actually, someone else had suggested to me that there might be something different about some of these objects ...My first reaction is that I can think of two possibilities[ol][li]Perhaps there is some 'interference' between the TransformCall and a Transform_Mat inside the object.[/li][li]And/or these objects actually require some parameters to be passed to 'translate' them and the mechanism for translation is built into the objects[/li][/ol]Tell me, JR, when you comment out the first TransformCall(), does the end segment appear at the RefPoint or at the point -30, 0, 0 ? This will tell us whether x-y translation works at all with these objects.The other puzzling feature is Arno's report from testing that the translation of multiple segments still doesn't work when multiple RefPoint's are used - that is very puzzling indeed and has no obvious explanation.As regards your latest macro code, JR, you are right that it doesn't matter where the :Fail label goes as long as it points to a Return, but you do seem to have a couple of other typos in your coding, which should perhaps look something like this (although it's pretty academic if it doesn't work anyway!!!) :-

Area( 5 %1 %2 %3 )PerspectiveCall( :P0 )ShadowCall( :P0 )Jump( : ):P0Mif( %11 )RefPoint( Abs :Fail %4 %1 %2 E= %11 V1= 10000 V2= 200 )MelseRefPoint( 7 :Fail %4 %1 %2 V1= 10000 V2= 200 )Mifend:R0TransformCall( :Obj1   0 0 0  0 0  0 0   0 0 )TransformCall( :Obj2 -30 0 0  0 0  0 0 180 0 )TransformCall( :Obj1  45 0 0  0 0  0 0   0 0 )TransformCall( :Obj1  60 0 0  0 0  0 0   0 0 )TransformCall( :Obj1  75 0 0  0 0  0 0   0 0 )TransformCall( :Obj1  90 0 0  0 0  0 0   0 0 )TransformCall( :Obj1 105 0 0  0 0  0 0   0 0 )TransformCall( :Obj1 120 0 0  0 0  0 0   0 0 )TransformCall( :Obj1 135 0 0  0 0  0 0   0 0 )TransformCall( :Obj2 150 0 0  0 0  0 0   0 0 ):FailReturn:Obj1CallLibObj( 0 18b2918f 497c11d1 f2a2c0b5 65e56362 ); bridge07 main span objectReturn:Obj2CallLibObj( 0 2d7d189a 43f3f0e5 75d03fb7 6b7a4ef8 ); bridge07 end objectReturnEndA

(Note that the V2 value needs to be large enough to encompass the whole of the bridge. And you don't need to repeat the elevation displacement in the TransformCall's - that would result in the bridge floating up in the air.)It would certainly be nice if we can get the multi-RefPoint version working because this will enable a fairly straightforward macro that works correctly for a bridge rotated to any angle (by using the 'r' displacement option for the RefPoint syntax in SCASM). If the multiple TransformCall's worked this could be taken account of by calculating the correct displaced x-y coordinates using sin and cos functions.... interesting stuff, eh?Gerrish

Share this post


Link to post
Share on other sites
Guest gorchi

Hi!This reminds me on a discussion I had with Arno regarding to placing effects. I also have tried to move the effect around a little bit but TransformCall and TransformMat haven't worked. So I tried using GRP() and RefPoint() with -r and -d instructions and that did the trick, so I could move my effect around, but unfortunatelly I couldn't elevate it. So I persume this is just the same case.And Gerrish, I agree, this is interesting stuff! What a shame that instead of MS giving us some infos about all these tricks etc we have to play two roles: to be a designer and to be a researcher. Bad commercial stand from M$.Anyway, I will try also this macro when I come home and GRP()+RefPoint instructions also :)Until later best regards to all,Goran BrumenFS Slovenija 2002 teamhttp://slovenia.avsim.net

Share this post


Link to post
Share on other sites

Yes, very interesting. I think there is a difference between these libraries and the effects. You can translate the library objects, but it only works once in an Area block. For the effect files it doesn't work at all.About the library objects, I was thinking could it be the MS has maybe some Return commands in their object? Causing it to Return to much after it has been drawn and not show the rest? I have tried this by adding one extra Call command to make it nested deeper, but that still didn't work.


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 JR Morgan

Gerrish: Re: "Tell me, JR, when you comment out the first TransformCall(), does the end segment appear at the RefPoint or at the point -30, 0, 0 ? This will tell us whether x-y translation works at all with these objects."**Always at the RefPt only. As mentioned in the test report, I could never get any XZY offsets, However, rotation centered on the RefPt is possible using transform call's #_degree parameter, as in the example: "TransformCall( :Obj2 -30 0 0 0 0 0 0 180 0 )".**Yes, I was a little "bleary-eyed" at the time of night I was testing this. 'Looks like I really 'honked-up' the V1 and V2 sequences and values. And yes, I would really like to have the single macro per bridge capability.I suspect the key to understanding what's happening in this exercise is for someone fluent in Ground2K to create this bridge in that software and recognize it's interaction with the "//Dual Hiway Bridge - gen_bridge07" MS code. Once that's understood, we might be able to "SCASMize" it into a simple macro?J.R.

Share this post


Link to post
Share on other sites

>I suspect the key to understanding what's happening in this>exercise is for someone fluent in Ground2K to create this>bridge in that software and recognize it's>interaction with the "//Dual Hiway Bridge ->gen_bridge07" MS code. Once that's understood, we might be>able to "SCASMize" it into a simple macro?I have tried placing some bridges with Ground2k, but I don't think it can help us much here. That code only contains a VTP line and internal FS calls the library objects in some way.I think it must be something special in the library, but at the moment I don't think we can decompile the MS libraries yet, to see which code they contain.


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 JR Morgan

OK Arno.. Thanks for that input. I was afraid of that. I just thought that since the Terrain.cfg file's published code looks somewhat similar to "ownlines.txt" formats used in Ground2K that somethng might become obvious. Well I guess until we get some new info (Terrain and/or Autogen SDK's) or learn how to decompile the new stuff, we will just have to use multiple macros to make just one bridge.Thanks...J.R

Share this post


Link to post
Share on other sites
Guest GerrishGray

It is clear from your information, JR, that the bridge objects do not respond to X-Y translation via TransformCall, and I now have little doubt that this is because of some built-in mechanism for X-Y translation that interacts with VTP 'Autobridge' lines. As Arno says, its a pity that we can't yet examine the coding of the objects because of the new RIFF-format BGLs, and it's very unlikely that any VTP SDK is going to reveal the secret!But we shouldn't give up too easily :-)Certainly, there is the 'easy' option of reverting to placement of each segment in its own Area() block, as per the original macro, but that leaves the problem of correctly calculating the position of each segment of the bridge, especially when it is rotated from a simple E-W or N-S alignment, so let's check out two possibilities:1. The multi-RefPoint approach - let's make absolutely sure that it won't work - I really cannot understand why it shouldn't.2. The other possibility, that I haven't tried yet, is whether SCASM will accept the syntax for calculating the Lat/Lon values in an Area() statement as it does for RefPoint() and other statements needing a Lat/Lon pair. Once one has established an initial 'GRP' in any one .sca/.api file from its first Area() statement, it may be that subsequent Area() statements will allow this convenient syntax? I'll explore these two ideas myself if I get some time later in the day (the wife is dragging me out on some errands at the moment !!!), but if one of you has time to experiment before then, so much the better ...CheersGerrish

Share this post


Link to post
Share on other sites
Guest JR Morgan

HI Gerrish: Re: "1. The multi-RefPoint approach - let's make absolutely sure that it won't work - I really cannot understand why it shouldn't."**I had also tried multi-RefPts in it's simplest form by placing offset RefPts in between the transform calls. XZY did not budge! **Re: ".... but that leaves the problem of correctly calculating the position of each segment of the bridge, especially when it is rotated from a simple E-W or N-S alignment,"**The (2) pictures I posted in this thread show 2 bridges made by placing a first bridge center span segnment object in accord with world coordinates taken from the M$ "Streets and Trips" software, which yields Fractional degrees Lat/Lon, so we must convert the fractional degrees to Whole-Degrees and Decimal-Fractional Minutes. IRONICALLY, those locations turned out to be perfectly located in the scenery (yes miracles do happen). Especially interesting is the fact that FS9 default signage and light poles (see picture 1) turned out to be perfectly located with respect to the finished bridge AND with respect to a missing US Interstate Hiway 70 common to this bridge.Note that in Terrain.cfg, it appears (to me) that MS groups objects (signs, light poles, power poles, etc) in a fashion that provides for their being aligned with default AND USER INSTALLED roads. Well, M$ 'blew' the Interstate 70 Hiway! -- At this location, that Hiway is totally invisable in the default FS9 scenery (!), BUT the FS9 default located signs and light poles along a (missing) I70 Hiway are visible and in their correct locations as if the Hiway were visible-- The bridge is certainly in the right geo-location and runs magnetic E & W without need for 'swinging' each segment and it's ends into correct alignment with RotatedCalls.Now: (re original picture attachment 2) - This 2nd. bridge's first center span was also correctly geo-located using world co-ords as described above. However, this bridge was correctly located over an existing (and FS9 default-displayed) minor Hiway complete with Hiway light poles, etc -- so we had the potential for being able to create another perfectly located bridge. This (default) Minor Hiway road is actually approx 3 to 5 meters south of east on the east side of an existing river. This required a few degrees of rotation of the entire bridge, clockwise, using RotatedCall in all of it's segment macros. Not a problem using the AFW GUI and the %5 parameter in a macro.With regard to multi segment %11 elevations, once you find the correct elevation required for the bridge-end(s), all that's needed is to make each and every bridge segment the same %11 value. If a problem arises because of SCASM's 'integer only' requirement for %11, I've found that such elevations can be precisely adjusted by using a calculation within brackets for the %11 value in the RefPt statement.I've not yet encountered the problem, however, one might stumble upon the condition whereby one intended bridge's-end terrain elevation is noticably higher or lower than the other end. In such case, I think a very small flatten area polygon might suffice to 'true-up' such minor terrain alignment if required.**Ah, what fun.. I will be leaving mid-week to drive-to and attend a 56th year (High School) alumni reunion at the area where this scenery is located -- 'No telling what else I'll find there. :-)Regards...J.R

Share this post


Link to post
Share on other sites
Guest JR Morgan

Re: "I think it's great you're attending your Dad's Class reunion" Very Funny... ( I'm gonna get you for that one )--> :-spacecraftJ.R

Share this post


Link to post
Share on other sites
Guest falko

I don't know if it is of interest for you, but to create bridges in SCASM-Code (SCASM 2.89c) you just have to draw a 2-point line and give the right texture number of the bridge.;Example source for adding bridges (road lines). (for SCASM 2.89c) Header( 1 50 47 12 10 )VTPFileHeader:cell00 ; marks the first data cell VTPArea( 1 1 0 0 ) VTPLayer( 32 0 1 0 ) VTPTexID( 0 0 ) VTPPolyCount( 1 0 ) VTPPoly( 2 2 1 ) ; Method 2, 2 points, line VTPWPoint( 7212 10233 0 ) VTPWPoint( 7226 10243 0 ) VTPArea( 1 1 0 0 ) VTPLayer( 32 0 1 0 ) VTPTexID( 1 0 ) VTPPolyCount( 1 0 ) VTPPoly( 2 2 1 ) ; Method 2, 2 points, line VTPWPoint( 7212 10283 0 ) VTPWPoint( 7226 10293 0 ) VTPIndexList( 1 408 118 0 ) VTPTextureList( 2 "1214" 3 0 0 4 "1213" 3 0 0 4 )VTPEnd

Share this post


Link to post
Share on other sites
Guest GerrishGray

Hi FalkoYes, that's really useful, thanks. If I read this correctly, your example actually places two separate, and different, bridges - is that right?The main thrust of the recent posts in this thread was to discover a way of using the bridge objects 'direct', rather than via VTP lines, in order to give full control over the appearance of the finished bridge, including the specific bridge type used - the VTP method seems to allow FS to pick at random from two or more designs for each bridge type, if I understand correctly.By the way, for those following this thread who don't happen to have a copy of the VTP/LWM-enabled version of SCASM (v2.89c), this was a beta version that Manfred Moldenhauer has since withdrawn and is no longer available from his web site - presumably because it was causing him too much trouble. But for those of us lucky enough to have a copy, it offers a SCASM-based method for creating VTP and LWM features ...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  

  • 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...