success with replacing fs2002 generic models

[ShezA 176]

Well as usual your inputs and Dan's and Salsa's (and others) are leading us down code optimisation. :)Your observations on the statics are exactly mine when I saw the code. Very complex. However I am not an expert in codes so was left to pointing out this to you experts. ;) Thanks for looking into this.We should of course continue to look into the GMAX/FSDS import as well but will possibly require aircraft designer help for their source files, lest we desing a/c ourselves which I am not too sure scenery designers are good at...or have time for. (-: Your observation on the animation is spot on. Thought it would be an excellent feature. Though the one minute hurdle is an issue as it would restrict vehicles to do repetitive (annoying) movements... :( RegardsShez

[jkanold 0]

Now, that's very good news. Keep us informed please.http://members.rogers.com/jkanold/jimlogo.gifhttp://members.rogers.com/eelvish/flyurl.gif

[Guest]

I'd be interested in the number of polys in a 'low poly' GMax static a/c. Or if this has a significant effect on performance. I have removed a lot of scasm code in a static macro, usually to get rid of unwanted parts like helo rotor animation but have seen no visible effect on performance. jb

[Guest]

jb,it depends on the features of the original aircraft, your positioning of the aircraft in your scenery and how frequently you are going to use it in your scenery. Better to keep the widely used aircraft low poly and position them in less visible places. In the central sections of the airport you may use relatively higherpoly modelsAs far as I remember, I modelled 737 with around 200, cessna172 around 150, hercules 800, concorde 1000 poly's (rough figures).biberwww.LTBA.net

[Guest]

jb, Biber and the rest Hi !There is one test I haven't done but it may be interesting.If you develop large airports with many planes all over you can do it with two diferent methods:- Put the planes in the same bgl file with the rest of your sceneryor- Export each plane in a bgl file of it's own.In the first case the scenery mechanism is forced to deal with all of them and I'm not sure what happens with the ones out of sight.In the second method, it is certain that very early in the bgl execution, the projection engine decides if the whole object is visible, and if not does nothing else with it.There is the possibility that the second method is faster.I have not tried this myself, but it would be interesting to know the results. Altough there is a certain overhead and penalty for each distinct bgl file I think we may be pleasently surprised; specialy if you group 3-4 planes together to cut down this overhead.All the bestGeorge

[arno 1]

As long as you have each object in its own Area block it should make no difference how many objects are in a BGL for the visibility. The scenery engine determines for each area block and for each reference point if it is vissible at this moment and then draws it or not. So I expect it to make no difference.ArnoMember NL2000 Teamhttp://home.wanadoo.nl/arno.gerretsen

[Guest]

Hi Arno.I forgot to say that this goes for gmax modeling, no SCASM.I have no idea about scasm, but I take it that the Area you mention is equivalent with the MASM scale command.If this is the case you are right if you use scasm.But the MASM code from gmax uses ONLY one scale command and a VICALL if rotation is defined in makemdl. At the top of the each bgl file there is a condition if the scenery is visible or not that skipps the whole file. This condition forms a large box around the complete scenery. So in a large "put in everything" file this is most of the times valid and the processing goes on to the internal of projection engine. This is an area we do not know very well...So in the gmax case it makes a heck of a difference in the WAY things are done. What I do not know is if the results favour the individual files or the single file.It's something that in my opinion needs investigation...George

[arno 1]

Hi George,I am getting a bit more familiar with the BGLC code know and I think that the general header is equivalent with the SCASM area command and the scale command is equivalent with the RefPoint command.So that means GMax puts everything into one Area and one RefPoint (I already knew this by the way). So if you are using only GMax it is much better to make a seperate BGL file for each object. Therefore I make an library of my objects (with FsRegen, but you know that :)) and then I place those with the normal design programs. Then they have an own Area block or reference point, so I can control the visibility of each object seperate, which can not be done if you place them all in one GMax file.Another comment, you can also export a selection from GMax (so only one object each time for example), but that is not a very good solution, because all objects will then get the same reference point (the center of the axes in GMax will be used for all) and that also makes it difficult to control the visibility correct (that works much better if the reference point is in the centre of the object).ArnoMember NL2000 Teamhttp://home.wanadoo.nl/arno.gerretsen

[Guest]

Hi Arno.Agree with you 100 %.Also this approach (of actually placing library objects) seems to be faster.And very right with the "export selected" operation.I did a quick test and put the results in a new thread. The subject of this one is a bit different...I think it's important for gmax-only users as the results are impressive.Anyway, nice having intelligent people exchanging ideas. It's the best part of it !!All the bestGeorge