Sign in to follow this  
arno

Vector autogen bridges in Ground2K scenery for FS2004

Recommended Posts

Has anyone found out how to make the autogen bridges appear correctly when making new scenery in FS2004? I have been trying to use Ground2K to make scenery, have the ownlines.txt provided by Dick in another thread here installed. The bridges appear, but at least two things go wrong...1. The bridges remain too short (might have something to do with LOD area boundaries?)2. For some of the vector autogen bridge types a small piece of bridge appear at some distance from the intended bridge and at 90 degrees angle to the actual bridge. I have tried to make the bridges just as a straight line (same settings in G2K as for roads, expect for the line type number) with a starting point and an end point and also to make the line end with two adjoining points (this cause the bridge to look very complicated, though :) )BamceEFHN

Share this post


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

Hi Bamce.I don't think anyone has done it yet.We need a new macro. In order to get that, we'll either have to wait for the SDK ( and hope it's in there ), or experimentr with a hex editor on a file that has only one or two bridges... and substitute values until we understand the structure ( just like Christian stock and I did for the original LWM code ).Another possibility is to place them as objects. They actually are library objects, with GUIDs described in the terrain.cfg file.Dick

Share this post


Link to post
Share on other sites

I successfully created one by hand, but it took a lot of trial and error.I used my Coast-Line-Maker to lay down a two-point segment, then hand edited the ASM code to change the layer number and texture to that for the appropriate bridge.However, I initially noticed the "spare" bit of bridge some distance away that you mentioned, plus some extra ramps at the ends. The bridge was not only shorter than the segment, its endpoints were quite far from where they should have been.A two-point segment becomes a 5-point segment in the ASM file, and I hand-edited this to a 3-point segment (1st dummy point, 1st real point, 2nd real point) and this got the bridge to look OK, and eliminated the spurious bits.With further laborious trial-and-error, I eventually got the endpoints to where they should be, but it was quite a long way from the expected VTP co-ordinates.Never thought it would be easy ...Cheers,Iain.

Share this post


Link to post
Share on other sites

Gentlemen: I know it's in all our best intrests to develop routines in programs like Coastline maker and Ground2K type programs to do vector bridges and/or other objects. Meanwhile, for us lazier 'SCASMese' types, here are 2 bridges made with simple SCASM api macros (inspired by Dick Ludowise), using AFW 2.95 build 166 as a GUI, allowing quick/easy placement of AGN bridge segments (or any AGN objects with known LibObj code Id's wherever needed:The api macro:;SCASM api Macro to place FS9 Autogen objects using AFW GUI 3D object placement routine.;The 4 (%6-%9) hex 'words' comprise the LibObj ID string. Macro by J.R. Morgan Jr; ;Copyright SCASM by Manfred Moldenhauer;Macro inspired by code examples by Dick Ludowise Area( A %1 %2 %3 )PerspectiveCall( :_object )ShadowCall( :_object )Jump( : ):_objectMif( %11 )RefPoint( Abs :_Fail %4 %1 %2 E= %11 V1= 6000 V2= 100 )MelseRefPoint( Rel :_Fail %4 %1 %2 E= %11 V1= 6000 V2= 100 )MifendRotatedCall( :RO 0 0 %5 ):ROCallLibObj( 0 %6 %7 %8 %9 );CallLibObj( 0 51AA12D6 49E6AE0F BC6D16A9 02F41CD8 ); i.e. Typical resulting format of Call:_FailReturnEndAJ.R

Share this post


Link to post
Share on other sites

Actually, placing the bridges with a SCASM macro as JR suggests is probably a much easier and more reliable approach than doing it via VTP lines. MS developed the VTP method to suit their automatic generation of the default scenery, but it caused them quite a bit of difficulty with bridges that did not appear correctly, just like the problems reported earlier in this thread. In fact there are still a few 'broken' bridges around the default scenery if one searches carefully. Placing the library objects 'direct' is likely to be far less error prone for the individual scenery designer.If you don't mind me saying so, the proposed macro code could do with a couple of tweaks though ... it should actually look like this for maximum efficiency:-Area( 4 %1 %2 %3 )PerspectiveCall( :object )ShadowCall( :object )Jump( : ):objectMif( %11 )RefPoint( Abs :Fail %4 %1 %2 E= %11 V1= 8000 V2= 100 )MelseRefPoint( Rel :Fail %4 %1 %2 V1= 8000 V2= 100 )MifendRotatedCall( :RO 0 0 %5 ):FailReturn:ROCallLibObj( 0 %6 %7 %8 %9 )ReturnEndAAlthough the macro allows for automatic elevation placement in the usual way, it will probably prove better, in the case of bridge segments, to specify the required absolute elevation AMSL in order to make sure that all segments of the bridge are correctly placed at the same level.CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish I noticed that your "V1" value is 8000 meters do you findthat's a good value for things like bridges? Dan

Share this post


Link to post
Share on other sites

Hi DanYes, I would always use at least 8000 or maybe a little more. Features like bridges should be visible from at least 8km away - and should normally be displayed successfully at that range by FS with reasonable display settings - so it doesn't seem sensible to cut them off as close as 6000m. Actually, if the macro is going to be used with programs such as AFW one can use the parameter %10 in place of the fixed 8000 value and allow the user to set the visibility range they prefer. But I would always recommend at least 8000m for objects as prominent as bridges.CheersGerrish

Share this post


Link to post
Share on other sites

Thanks for the tips Gerrish. The thing I usually do is to set V1 * V2 based on testing in the scenery and set the lowest possible values that yield visibility 'typical to the area'. The 2 bridges in the example I posted are not very 'prominent' bridge types, i.e. no high suspension structure, etc. As a matter of fact, I didn't see any such bridges in the FS9 examples with GUID codes published, although I've not tried every example yet.The thing I really wanted to do was to develop a macro using TransformCall so that an entire bridge could be drawn from one Area/RefPt callout instead of having to iterate same for each of a bridge's center spans and end objects. So far, in my testing, that approach is not working -- each lib object is 'paying no attention whatsoever' to X,Z,Y offsets. I know you do this with trees, but I think your trees are your own creation original lib objects. If you come up with a trick to do this with M$ lib objects, I'd sure like to learn that one.Finally (and most demoralizing) is the insatiable desire to create that pylon with the erect middle finger as you mentioned on another post --- But at my age, and with a 'nuked' prostate, I can't seem to get anything erect...J.R

Share this post


Link to post
Share on other sites

I did a little test and I can translate my library object without a problem with a TransformCall. So I guess it should work.

Share this post


Link to post
Share on other sites

Hi Arno... Yes, I can translate "My" multiple library objects also, but the problem I'm having is with (multiple) FS9 default AGN objects i.e. bridge segments, light poles etc. Are you saying you've tested translating multiple FS9 AGN objects and your SCASM transform call code works to do that - or are you saying you're translating your-own non FS9 AGN objects within one macro?I can put the FS9 AGN lib objects wherever I wish using a seperate macro for each object, but so-far, not successful to place an entire bridge comprised of say 12 seperate segments or an array of light poles, etc, using only one transform call macro. Obviously, MS is doing it with bglc -- I'm looking for a way to scasm'ize it...Thanks J.R

Share this post


Link to post
Share on other sites

Hi JR,I tested translating another library object, not a MS autogen object. But if you now the size of the segment you are using it should be a troubled should it?I don't think MS did the bridges with BGLC, as they are generated from VTP lines it is something hardcoded and is not necesairy that they use the TransformCall command.

Share this post


Link to post
Share on other sites

Hi Arno...Re: "if you now the size of the segment you are using it should be a troubled should it?"**The format of the bridge objects in Terrain.cfg file may be VTP lines (I don't know).The Terrain.cfg default size of these lib objects can be scaled with no problem in a user macro. The bridge objects in Terrain.cfg are merely segments of bridges and bridge ends -- not complete bridges.These segments are easily arranged into a complete bridge by using a macro for each segment (See pictures I posted). However, the thing I'm trying to do is to displace these segments with respect to one macro's RefPoint using transform call. It seems to me it should be possible. BUT; so far I've not been able to do it.Rotated calls of single segments (or objects) work just fine but transform calls to place an entire bridge comprised of many segments or the ofsetting of even one segment from the RefPt isn't working for me yet. ---'There's gotta be a way.J.R

Share this post


Link to post
Share on other sites

Hi JRPost an example of the code you are using with TransformCall() and I'll see if I can solve the problem for you ... :-)CheersGerrish

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

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

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

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