Jump to content
Sign in to follow this  
arno

Details of the various Area() / OBJECT_HEADER classes

Recommended Posts

Guest GerrishGray

There has been some discussion of the different types of Area() available. When should we use them?The BGL language provides for 9 (or is it 10) different classes of 3D scenery object in 'section 9' code. We can choose between SMALL (256-byte), LARGE (64kB) and HUGE (unlimited size) code models, and between NEAR, FAR and NEAR-FAR ranges. There was also a special 'LARGE RANGE' or 'ALWAYS LOADED' class in FS5.1 - but I'm not sure whether that still has any real use.The complete list of 9/10 classes is in the FS2000 Scenery SDK, but without a full explanation. The information in the SCASM documentation appears to be somewhat out-of-date and may be a bit misleading. The significance of the SMALL/LARGE/HUGE types is simple and clear enough but the significance of NEAR, FAR and NEAR/FAR is not fully explained. The suggestion is that NEAR objects are 'active' only when they are within 40km (25km ?) of the current viewpoint, FAR objects are active only when outside this 40km (25km) boundary, and NEAR/FAR objects are active at all(?) ranges.NEAR seems to be appropriate for nearly all normal 3D scenery objects, unless they need to be visible/active at 'extreme' visibility ranges, and my guess (but this is a pure guess) is that FAR was originally provided as the means by which FS5 - FS98 switched between 'close-up' rendering of mountains and the bluer, simplified, distant view, now obsolete since the introduction of terrain mesh in FS2000.There is an argument in the object type header that SCASM incorrectly calls 'range' and says it is expressed in kms or 'range units'. This seems to be incorrect. The argument is actually 'image power' (according to MS) and is measured in %age. The BGLC macros actually allow the programmer to omit this value altogether and just set it to 100% if that is the case. SCASM users have traditionally set this value to 22 under the mistaken impression that it is measured in kms, but it seems to work OK anyway!Apparently only FS5.1's class D (13) 'LARGE RANGE' object type actually used 'range units' instead, and the permissible value was 1-255, with a special interpretation based on kms up to 100, but an extended formula for greater values.Does anybody have any more certain understanding/knowledge of the correct use of these different object types and the true significance of the 'image power' argument. Is anyone in any way able to throw any light on the sketchy information in the SDK and the possibly misleading/incorrect description given by Manfred Moldenhauer in his SCASM doc's.I believe that gMax/makemdl.exe always creates objects as type C (12), the NEAR/FAR HUGE model, but I suspect that this is just out of 'laziness' to make sure that all objects work under all circumstances.ThanksGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish.I think the use of HUGE in Gmax is due to the crash code, object code, and placing code being part of the finished BGL. It assumes huge, as most detailed object code coud be huge ( > 65525 bytes ). So the code is probably a lazy solution. I know the actual object code is "included", but that makes no difference in the produced BGL... The HEX BGL code is the same if it is "included" or if it is "in-line" code. So the size of the object and crash-code must be calculated in the Object Header.--------------------If we put objects in a library, then we coud use SMALL... but cautiously, as there may be crash-code in the placement BGL, that would require LARGE if it is greater than 255 (?).Maybe this all makes no difference to FS2002 or CPU load.--------------------But I'm not sure NEAR, FAR, or NEAR_FAR makes any difference at all. I'm seeing all objects ( and runways ) disappearing at around 16000-19000 meters.Like you, I wouldn't know if any advantage were to be gained by anything other than by NEAR_FAR... unless there is ( or was in earlier sims ) some crude "mipping" of objects produced by this. I'll play with that idea ( crude mipping ), and see what I can do.Dick

Share this post


Link to post
Share on other sites
Guest GerrishGray

Hi DickWhen one creates a section 10 library object and a section 9 calling sequence, they are separate 'objects' in the BGL file structure with separate object headers, even when placed in the same BGL. They are also assigned separate memory spaces when loaded by the scenery engine. The section 10 object is retained in a cache for quick re-use in case it is called again, whereas the section 9 object will be discarded from memory as soon as it ceases to be active.You are right that gMax tends to put everything into one big object. I didn't think that it created section 10 library objects anyway unless one uses FSRegen to do so ... surely the standard output from gMax/makemdl.exe is just a single section 9 object?It also seems to be true that most visual objects disappear at a maxiumum of less than 20kms anyway, which is why I see little point is using anything other than the NEAR object types in most circumstances. But perhaps NEAR/FAR objects actually will display at greater ranges if they are physically large enough on screen? FS2002 seems to have a rather more sophisticated way of deciding when to cull or display distant objects than the earlier engines - I think that this is one of the features of the new frame-rate-optimisation code. For example, there no longer seems to be an inherent problem with the maximum visibility of objects that use a small scale, as there was in earlier versions.Any thoughts about what the 'image power' value in the object header (or SCASM Area() command) really does? I certainly get the impression that it has some effect on visibility and texturing effects, because objects stop displaying correctly if you reduce it to too small a value.CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish.'bmolony' had a recent post where he had created a gigantic object "to graphically represent the inbound and outbound traffic patterns surrounding KATL". It covered a 20 mile radius, and he wanted to be able to view it from 60 miles away.It was in GMAX, but he couldn't figure out how to get the ASM code. I was able to hex-hack the NEAR_FAR to NEAR and to FAR , and it made no difference. There's an ALWAYS and a LARGE value, but they crashed the sim.In short, it didn't work. You could view much of the object from within it's radius, but moving out 16000+ meters from the center ( refpoint ), and the object vanishes from around you! POP! and it's gone.So with this version of FS2002, I think it has a 16000-19000 meter limit... But that limit is different N-S than it is E-W, and it isn't equivalent in fractional degrees either... a mystery as to what the bounds are and why. I don't know if the visual limits change as you approach the poles either... but that would support a distance bounded by fractions of degrees, rather than just distance. Maybe this is a trigometric computation, but why? Why not just make it 20,000 meters?The size of the object makes no difference, and runways nearby "pop" at the same distance... maybe it's an LOD13-type measured distance.------------------------------Maybe NEAR, FAR, and NEAR_FAR are a legacy from FS98, or earlier. I noticed that you can select these types for exclusions, but I haven't messed with the possibilities. Page 22 of the FS2000 SDK says ( when speaking of exceptions ) "Beginning with version 7.0 there is no distinction between object types." So why is all that NEAR_FAR nonsense in the SDK? Who knows? DickP.S.I've never made an exception BGL, have you ?

Share this post


Link to post
Share on other sites
Guest GerrishGray

I think you may have uncovered all of the answers here.I had read pages 22/23, but assumed that the reference to the object types having no significance in FS2000 was merely to do with exclusions/exceptions. Now I re-read it carefully I think you may be right - it seems to be telling us that the NEAR, FAR, NEAR/FAR setting no longer has any practical significance. That would explain why page 26 doesn't bother to explain what the difference is - it's because there isn't any!!! And I thought that MS were just being their usual obscure selves - they actually told us all along if, as I have said myself, one read the SDK thoroughly and CAREFULLY enough - a case of the biter bit, eh ;-) Pity they couldn't have made it a bit clearer though and told us on page 26. They also repeat the information about the object types in the code example on page 20/21 as well, and I now realise that the page 20/21 information does not conflict with that on page 26 as I had previously thought - it is just the description of the image power units that is different.Your testing for the guy who wanted the visible flight paths at 60-mile range seems to confirm that there is no longer any difference between NEAR and NEAR-FAR too. So the conclusion is that[ol][li]There are effectively just three types of object, the SMALL model (type 4, 7, or A - completely interchangeable), the LARGE model (type 5, 8, or :(, and the HUGE model (type 6, 9 or C). And Type D is no longer valid at all, from what you say (which explains why there is no separate header macro for it in bgl_header_macros.inc).[/li][li]The 'image power' value really may be measured in the sliding-scale 'range units' detailed on page 20, and not as a %age as expressed elsewhere. Perhaps %age is just a misnomer for the range units? So the habitual use of a value of 22 kms/%/range units is indeed correct.[/li][/ol]Anyway, you seem to have cleared all this up and clarified the information I was seeking. Thanks and well done.Gerrish(By the way, did you try using an image power / range of 100+, combined with a LATBAND range of, say, 2 degrees, when trying to get our friend's flight paths visible at 60 miles?)

Share this post


Link to post
Share on other sites
Guest christian

Hi Gerrish,I think the SDK says somewhere that image power is in nm < 100 and > 100 it's increasing in 5nm steps (101 = 105 nm, 102 = 110 nm ).I think Fs2004 will probably get rid of this concept totally. Using gmax, we can do LOD models now, so I suspect the new scenery format will support LOD models more directly. Of course we can do LOD models with the existing commands, but it looks a bit awkward really and the BGL language isn't really designed with LOD in mind I think...Cheers, Christian

Share this post


Link to post
Share on other sites
Guest GerrishGray

Hi ChristianLOD, or multi-resolution, models have been in use for a long time, well before the advent of gMax with FS2002. The NEAR, FAR, NEAR/FAR object types seem to have been an early way for MS to do this with the mountain objects that preceded terrain mesh scenery, but they have been using the modern type of LOD models in the default scenery for some time now.We seem to have established in this thread that the NEAR, FAR, NEAR/FAR system has now effectively been abandoned and I am sure you are right that it will disappear entirely from FS2004 when they will probably prune the existing command set rather more drastically than has been done in the past. Whether they will give us a new structure / command set for handling LOD models is another question, but it would certainly be nice if they did and would enable them to also prune some of the other commands that we rely on for this sort of thing at present. Although they have only told us so far that the older image-rendering commands will be removed, I suspect that the changes may be more far-reaching than that because many of the other commands still use 16-bit integer values and/or 16-bit offset addresses.Interesting times ahead in our hobby, I think - but there's nothing new about that, eh !?CheersGerrish

Share this post


Link to post
Share on other sites

Great info here :), finally a clear overview of the different Area types and what they do. Nice work.And I think you are right that from the coding point of view we get a nice time ahead :).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...