Trees and fences

[Guest jlwoodward]

1. What program or macro do you use to add trees?2. Is there a macro or texture to put a chain link fence around a parking lot? Surely, people would not draw the whole fence, would they?I am using FSDS and Airport 2.6Thanks for your help,John Woodward

[Guest]

hi johnAs a novice, going through all the same experiences as you, except wanting realism, suggest you look up Gerrish Gray's tree's at Flightsim.com, or similar. He has a new web site which he is working on at fsgateway.com, your find him under 'home Websites', I should stress that his web site is not fully up and running, yet, but I suspect will be worth the wait!!As to fence, its a case of searching macro's at Flightsim.com Shawn Manners has a fence plugin for Architect2002, at that web site.Hedges and Fences from my experience, is something somebody needs to put a bomb under, to make it happen!!!!There are api macros for Airport and in particular, an Agri fence, which may be inclusive of other macro'sOne just has to keep pluging away, (*.api or *.scm) are the file formats!! (api for Airport)Hope this helps, although you do end up thinking about creating these things that aren't available, yourself!!!Regards Dave

[Guest]

Hi please try to stay away from old style macros for things likefences. I will say it again,old style macros KILL frame rates. Try to make your fences in gmax and not in one of the older tools like FSDS or Architect. Only use,say Architect for things like adding to the airport it's self,(taxiways,runnways and lighting,etc) Plus if you model your own goodies you will get exactly what you need and not a high polly version of some other persons work. Architect is a fine program BTW but for meshes gmax (or 3DSMax if you have it) are light years ahead when it comes to meshes. You now have an industry standard tool for your models as gmax is a subset of 3DS Max 4.0 so if you have bought FS2002 pro you already have gmax. Please feel freeto look back in this forum about the above there is a lot of great info here(and helpfull people too!). BTW If you have any questions just post 'em and I am sure someone will give you the info you need. Danhttp://members.rogers.com/klasik2/danlogo.gifhttp://members.rogers.com/eelvish/flyurl.gif

[jkanold 0]

Till we can get a scenery design program to easily use BGL library files for macros, use Gmax to place fences, trees, etc directly.Example. Sorry for the jpghttp://members.rogers.com/klasik2/fence1.jpghttp://members.rogers.com/jkanold/jimlogo.gifhttp://members.rogers.com/eelvish/flyurl.gif

[Guest GerrishGray]

Hi JohnTo answer your original question, if you do a search of the file libraries here and on other sites for api macros for trees and fences, you will find lots of suitable macros that you can place with Airport 2.6, including my own library of tree objects as mentioned by Dave.With the greatest of respect to the gMax fans, it is NOT true that api macros placed with Airport are inherently slow, although there are indeed problems if you need to use a lot of them because each macro usually creates a whole, self-contained, scenery block ('Area')with a good deal of overhead that can, indeed, hit frame rates. The advantages of gMax are that[ol][li]It uses new DirectX-friendly commands for drawing complex 'wireframe' meshes of polygons and texturing them with bitmaps. These commands are much quicker than some of the older ones, but otherwise the code produced is still 'section 9' visible scenery the same as produced by any other tool.[/li][li]A complete scenery may be coded as a single Area block, avoiding the problem mentioned earlier regarding the use of large numbers of api macros with Airport. This can, however, also be done with other tools - or even with suitably designed api macros![/li][/ol]gMax is indeed a fantastic program and really scores for complex models, but it has no great advantage for simple things like trees (in fact, the gMax tree model is unnecessarily complex anyway and this tends to negate any advantage that gMax would have).One of the keys to minimising frame rate hit from repeated objects such as trees is to use 'section 10 library objects', and trying to call a number of these objects from one single scenery Area block instead of having a separate Area block for each individual object. You will find that my trees library incorporates both techniques.By the way, gMax can be used to produce 'section 10 libraries' via the powerful FSRegen add-on tool, but unforunately nobody seems to have taken advantage of this yet to give us libraries of reusable scenery objects ...Hope this helps answer your original question, and clarifies some of the confusion about the relative advantages of gMax and older tools.Kind RegardsGerrish

[Guest jlwoodward]

Thanks Gerrish,Your trees are great and they are in lots of sceneries I have downloaded, so I will look for the macros. Until you mentioned it I did not know that they could be used with Airport 2.6. There are so many different scenery programs out there, and I'm not quite ready to tackle Gmax. Airport has worked ok so far but it is not that easy to use (it sounds easy but some things just don't seem to work, and the help menus leave a lot to be desired). Once in a while I have put in a macro that locks up FS.I did find a fence macro at Simviation. The ones pictured in the other post look great but don't know if they are available.Thanks,John Woodward

[Guest]

Hey everyoneI hate to be the stupid one, but can anyone direct me to a link to somewhere that tells how to make decent " + " style trees in GMAXCheersJarrad

[Guest GerrishGray]

Hi JarradIt's easy enough to make a simple + tree in gMax and hardly needs a tutorial if you know the basics, which you can get from any of the tutorials. But the old + model for trees does not work well in FS2000/2002 because of the advanced shading effects. The two arms of the + get displayed with different shading, showing up the non-round shape of this model rather glaringly. (The code that is used by Autogen cheats by using a simpler rendering technique that does not have this problem).A better solution is to use a single-plane 'sprite' called via RotateToAircraft(). This has a number of advantages and, because it uses a single plane that always faces the user, doesn't suffer from the differential shading problem. If you want to make some trees of your own, the freeware tool Easy Object Designer (EOD) can create this style of tree for you if you do not want to code your own in SCASM. I don't know whether it is possible to use RotateToAircraft() via gMax (does anyone else out there know the answer?)There are some other complications I should warn you about though, like getting the correct seasonal behaviour for your trees - the Autogen / ground texture seasons cannot be correctly replicated using either the simple seasonal texture flags of LoadBitmap() or the older technique using the global 'seasons' variable. I'm busy updating my own trees library to get a better match ...Hope this helpsGerrish

[Guest JR Morgan]

Thanks Gerrish, for sharing your comments that are based on expert analyses (Re: Reply No. 4) --- and that you're still working on a new library set. I really like your Autogen replacements except in some cases those blooming flowers grow out into some of my polygon based roads and I have to keep moving them :-). I realize that you made them to augment density though and they're great in doing that.I've done a little testing to verify the good graces of minimizing Area and RefPt calls and will certainly vote with you on the merits of doing that to keep frame rates "within budget". Keeping track of all those points with respect to one Area/RefPt is hard on my old brain though :-). Maybe we need to keep a spread-sheet in parallel with objects being developed so their points with respect to Area & RefPt are well recorded during development? I saw a thread where Arno is testing along the same lines, also. Arno, will you please tell us some shortcuts in doing this? :-)Compared to what I had before, this newer computer I'm using now is so much faster that I've not seen a recognizable problem with frame rates using "Hoardes" of macros, all compiled with SCASM. Most of the places I notice frame rates tending to bog-down involve large mesh add-ons.Thanks for your work...J.R.

[Guest GerrishGray]

Hi JohnIt's interesting that you manage to lay down roads without scaring the Autogen trees away :-) ! This is of course thanks to the techniques in Airport that you have described to us in other threads for persuading the 'shy' Autogen stuff to stay put! You can't have it both ways though - if you don't scare the Autogen trees away then they are indeed going to grow out over the roads!!! One fix might be to use wider polygons for the roads rendered with a texture incorporating transparent verges either side of the carriageway. The wider polygon should keep the 'verges' clear of encroaching Autogen trees. Do you think this might work?As regards keeping track of multiple objects in one Area block, I know what you mean! It taxes my brain too when writing my macros for multiple trees. If you look at the code of the macros in my Trees Library SDK you will see that I use a little data table as an aide memoire while I am writing them. In fact, one of the developments I'm working on (ever so slowly I'm afraid) is some even more complex macros to place still more trees in a single macro / Area block. I'm also intending to try some more complex objects that will display rows of trees/bushes (for hedges etc.) and whole stands of trees with a single section 10 library object to further improve frame rates - but it can get really mind blowing for us old codgers!!!CheersGerrish

[Guest luissa]

>>As regards keeping track of multiple objects in one Area >block, I know what you mean! It taxes my brain too when Dear Gerrish and JR,I do not know if this helps but I write my macros (except complex and long ones) without Area() and EndA. An example, for a tree, is: PerspectiveCall( :pcall@ ) Jump( :next@ ):pcall@ Perspective mif( %3 ) RefPoint( 2 :return@ %4 %1 %2 v1= %7 E= %3 v2= 200 )melse RefPoint( 7 :return@ %4 %1 %2 v1= %7 v2= 200 )mifend RotateToAircraft( :start@ 0 0 0 0 0 1 0 0 0 ):return@ Return:start@ Points( 0 [ -0.5 * %8 ] 0 0 [ -0.5 * %8 ] [%9] 0 [ 0.5 * %8 ] [%9] 0 [ 0.5 * %8 ] 0 0 ) LoadBitmap( 0 WFS6 E0 0 200 0 trees1.bmp ) TexPoly( m 0 0 32766 0 0 148 0 1 148 68 2 205 68 3 205 0 ) Return:next@I have a simple Area macro and a simple Enda macro. The Area macro is:Area( 5 %1 %2 %4 ) IfVarRange( : 346 %3 5 ) ;check complexityand the EndA macro is:EndAMy macro files look like:macro( area.scm ... )macro( treeA.scm ... )macro( treeA.scm ... )... more ...macro( enda.scm )The @ that terminates the labels is mandatory and, of course the ORDER should be right. Many GUI tools for scenery design (like ASD) offer an option to set the order of the macros.Regards,Luis

[Guest GerrishGray]

Hi LuisThanks for your input. Yes, that's a good way of reducing the number of separate Area blocks. In Airport, it is easy to check the order of the macros by examining the APT file before compilation. I also suggested to the Airport authors some time ago that they should include a facility in their forthcoming Airport 3 for 'Area-less' macros to be embedded into the main Area block. Until there is a facility like that in one of the GUI tools, I have been reluctant to publish this approach to the 'world at large' because it could create an awful lot of support work trying to explain it to those who don't understand SCASM and/or programming properly, and correcting their errors etc. But perhaps, because you have raised the idea too and there is a fair bit of interest/discussion at the moment about 'correct programming', it could be published as a white paper / tutorial? What do you think?BTW, I know that you love your old ASD, but you really are going to have to give it up one day! Perhaps once we get the FS2002 Terrain SDK (if such a thing is EVER going to appear?!?), because then ASD really is going to start looking out-of-date. Maybe Airport 3 will be good enough to convince you when it comes along!Kind RegardsGerrish

[arno 1]

>I saw a thread where Arno >is testing along the same lines, also. Arno, will you >please tell us some shortcuts in doing this? :-)I am testing it on my Schiphol scenery. As this not made with a tool like Airport or GroundMaker it is easy for me to test such things. The scenery is made using my homemade DXF to SCA converter and I can change the output of that very easy.At the moment I am rewriting the converter a bit, but then I am going to test the differences of more/less Area/RefPoints. Because I think all polygons in one RefPoint is also not the optimum, as this does not allow you to set the visibility range of the different polygons to their optimal values.But when I find something I will let you know :).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]

Thanks (All) for very interesting and optomistic comments. More and more, it's starting to look like the "break-thru's" to more effecient design must come from people like yourselves, likely without "Key" SDK's from MS :-(. It's nice to know that you people are "Festering" with ideas that, I believe, will contribute greatly to (good) future design."If at first the idea is not absurd, then there is no hope for it".- Albert Einstein'All the Best; J.R.

[Guest GerrishGray]

Hi ArnoWithin reason, I think that the more Area blocks and RefPoints one can eliminate the better. It has always been known that there is a considerable overhead to each Area block - this is the biggest reason why people have frame rate problems when they use a lot of api macros. RefPoint also has a significant overhead - I seem to remember that someone once had some figures for the relative overhead of RefPoint, RotatedCall, TransformCall etc. but that was years ago. Obviously it is not always possible to eliminate RefPoints, especially if you have different objects that need to sit on the mesh terrain at different elevations.As regards visibility testing with the V1 and V2 parameters in RefPoint, there are several points we will all need to remember here[ol][li]If the RefPoint covers several different objects spaced out across a zone, the V1/V2 tests will be applied just once for all objects in the RefPoint zone at one go and the V2 value must reflect the 'radius' to the furthermost point/object measured from the RefPoint position[/li][li]The RefPoint V1/V2 test is optional - if no values are supplied the test is skipped. Other methods can be used instead ...[/li][li]A couple of other commands can be used to replace or supplement the RefPoint test[ul][li]SetScale(), if you need to use it for some other purpose, can do the same V1/V2 tests[/li][li]IfVis() (opcode 0x62) checks whether one or more points are visible on screen and has the advantage that it can check whether an object that is located away from the current RefPoint is currently visible[/li][/ul]So, if we are trying to eliminate extra RefPoints by drawing several different objects from one RefPoint, we could skip the V1/V2 test on the RefPoint command (and save a little time!) and then, to make sure that no time is wasted trying to draw stuff that isn't visible, check the visibility of each of the objects by preceding each with its own IfVis(). I'm pretty sure that the net overhead will be be less than using separate RefPoints because we will have avoided the translation and rescaling of the coordinates.[/li][li]Of course, one must try to avoid using RotatedCall()'s and TransformCall()'s as well if one is to get maximum savings from this, but the compilation-time calculation facilities in SCASM can be used to help calculate point coordinates based on the original RefPoint with no run-time overhead. SCASM's new geopt() pseudo-function could also be useful for this.[/li][li]But whether it is worth going to all this trouble in any particular instance will depend on the individual circumstances ...![/li][/ol]All interesting stuff, eh!?!RegardsGerrish