Sign in to follow this  
Guest cwright

Question about Autogen, Coding and View Distance

Recommended Posts

Help AVSIM continue to serve you!
Please donate today!

Hi GabrielThanks for that. The discussion on this topic belongs in this forum, not the General one - I for one just don't have the time to read all the stuff that gets posted there!Autogen in FS2004 uses two different types of object - the 'automatically generated' ones created by built-in code, and the library objects listed in default.xml (and also as 'Vector Autogen' objects in terrain.cfg in some cases). I suspect, as some people have already suggested, that the reported performance problems are associated with the second class, the library objects.Section 10 library objects DO have a setting for 'visibility range' in their header - known as 'image power' in MS terminology. This is the same parameter as the image power (range) in the normal section 9 object headers. Image power determines the range at which the object is placed into, and retained in, the active database. This is NOT the same as the visibility range, which is usually set lower. Once an object is in the active list, its position and visibility range are continually checked to see if it is actually visible and should be displayed. Image power needs to be set to a greater range than maximum visibility to ensure that objects WILL be displayed when 'visible', but the image power range should not be excessive, so that the visibility of individual objects does not have to be checked when they are far away from the current position.Prior to FS2004, the image power of a library object was probably ignored because they were always called via section 9 code which had already set an image power / range before calling the object. But with the Autogen in FS2004, these library objects are called direct by the Autogen mechanism in some way rather than via section 9 scenery, so it is quite possible that the image power parameter in the object header is being used to determine how long each instance of the objects should be retained as an 'active' object that might need to be redisplayed. As has been stated, we cannot presently decompile these objects because their BGL's are compiled in the new format, but I do know that it has previously been MS's habit to set this parameter to a default value of 100. In fact, BGLC does this automatically if no image power is specifically set in the source code. If this practice has been continued in FS2004, this could have the undesirable result being described, because it would mean that the objects remain 'active' within a 100km radius, with a resultant drain on resources. This seems entirely consistent with the observations made, including the surprisingly high visible range of some of these objects, and the increase in memory usage. If this diagnosis is correct, the cure will be, as suggested elsewhere, to replace these objects with ones with a more realistic image power (about 20kms is the normally recommended value for 3D objects) once suitable tools are available.So roll on the SDK's!RegardsGerrish

Share this post


Link to post
Share on other sites

Gerrish, that sounds very interesting. The concept of 'image power' is new to me and I'm still trying to digest it. It may explain something that appeared odd. On my test area, which consisted of a large flat plane with just a single city land class, I removed the default.xml file. There was now no measurable frame rate fall - and yet the memory fell in just the same way. It may have been because, although all the objects had more reasonable visibility distances, the sim was still keeping them in memory and checking to see if they might come back into range. By the way, I decided to post originally on the 'other' forum because I knew many people have experienced this problem and many of them probably don't regularly visit this forum. I have some more measurements that throw more light on the problem and I'll be posting it here soon. Hopefully the experts here can come up with more solutions - but I have a nasty feeling that, as you say, we'll have to wait for the SDK's, which may not be until well into next year.... Best regards, Chris

Share this post


Link to post
Share on other sites

Hello Gerrish,did you fint the Library BGL file?If yes could you mail me the name.I guess we didn't need to fully understand the new BGL-Library code to change the power setting. I would like to start my HEX-Editor and maybe the debugger to take a indeep loock at the new Library file format.I guess that if MS didn't compress or decrypt the files, we should find the power value out.ByeMarkus

Share this post


Link to post
Share on other sites

Markus, good luck! If you could find how to change the power value that would be great.... Best regards, Chris

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