Ideas for a new scenery design tool

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#1
As discussed in the thread about a new AFCAD like tool for FsX, there are some ideas to make such a new tools as a community effort. So let's use this thread this generate some ideas for such a tool, so that we can turn that into a plan.

I'll start with my own ideas of the next scenery design tool I would like to create. On the long run I would like this tool to become the "ultimate" scenery design tool. At the moment there are too many tools a designer has to use to create his scenery. So I would like to have one tool that can be used for both the mesh elements and the XML-style elements of the scenery. But I also know that this will be a big effort, so my ideas are to start with the XML-style elements. If we keep the design of the GUI general enough, it should be possible to add mesh scenery elements to it later without too much effort.

So this means that I would like the GUI in such a few that it has functionality to edit polygons, lines, point features, etc, without being tied directly to a certain type of scenery. And besides that it should of course have the basic features like showing maps and photos on the backgrond and stuff like that.

I have not really thought about the rest of the GUI yet, but I would like something like the Visual Studio environment. Where you have the map view in the center and have different panels on the side to show the properties of the currently selected object, a list of available objects that can be placed, a list of the objects you have already placed in this project, a 3D preview of MDL objects, etc.

Of course such a tool also needs a connection with FS (using SimConnect) to be able to read the position of the aircraft or to position the aircraft at the position of a certain object.

Besides the object that are available directly in the XML format, I would also like to add things like a line of objects or a polygon filled with randomly placed objects. This can be useful to make tree lines with some variation and stuff like that. So things to make the life of a designer easier :).

If suggestions like I mentioned above are implemented, it is probably needed to determine a save format as well. As you can for example not read back the line from all the object placements in the XML code.

Another things I have been thinking about recently is to use plugins for the tool. That way the functionality could be split from the GUI and maybe people can add new functionality easier as well.

This are the ideas that I can think of at the moment (should be enough to get a discussion started :)). If I remember some more, I will let you know.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#2
Well I agree with that Arno. I have been thinking that the GUI be implemented as a custom control with the ability to draw whatever shapes we need using simple line and polygons. The control would have a set of shape primitives built in that could be used by different objects.

It should be as independent of the things that we want to display on it as possible. It is almost certainly something that could be developed alongside the design, compiler and data handling functionality. I think each different object in the scenery is a class which can describe itself and the XML code or otherwise needed to generate it in FS. If all the classes inherited from a base object class then it could be possible to have different people work on the implementation of different elements - obviously easier with XML based objects.

I am working on the principle that each different element inherits from a base class and has it's own property window so an element could be developed as a package. These could be grouped in dlls to make the group development process simpler

As you probably know my Scenery Maker program can already create fences, polygon fills, lines of trees, bridges and so on and I'd be happy to make those classes available for the project.

As far as file format is concerned I have tended to make object serializable and use binary serialization - it is very quick.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#3
I am working on the principle that each different element inherits from a base class and has it's own property window so an element could be developed as a package.
I was more thinking along the line of the properties window being generic as well. For example some sort of table view (a bit like the properties I tried to implement in ObPlacer XML). The different objects should then have defined which kind of properties they have, but the editing and display should be in one generic object. I don't really fancy to generate a new properties GUI for each type of object (that can be dozens in the end).
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#4
I don't really fancy to generate a new properties GUI for each type of object (that can be dozens in the end).
Good point - makes a lot of sense. I have seen some stuff somewhere which uses reflection to create a properties table from the class itself.
 
#5
Binary serialization is my favorite approach also, but the question is: Isn't the XML specified in the SDK enough? That would mean a object <-> XML translation but could also provide the possibility of manually change the saved file.

Jon
If you have the objects I think that it will be a good starting point. If you all agree with XML saved format I could start with that.


José
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#6
I don't think the BGLComp XML format is enough to store all are objects. For example a row of trees can only be stored a seperate point features (one for each tree). But that means you can not go back to the line object if you read in the XML code.

So that means we either have to create our own XML format or choose something else. Also looking at the future, I think the tool should be able to export shapefiles for example (for the new mesh tools). So I am not sure if the XML format would be the best choice.

Also, would it not make sense to have a few more discussions about the direction we want to go and how we want to implement that, before we start coding? I prefer to do a little more thinking, so that all the classes and objects are thought about correctly.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#7
Binary serialization is my favorite approach also, but the question is: Isn't the XML specified in the SDK enough? That would mean a object <-> XML translation but could also provide the possibility of manually change the saved file.
Well I have found serialization much faster both in loading and saving but I don't see why XML could also be an output format. Also it is possible that we would want to save information about an object which is additional to the xml.
 
#8
Serialization could have the disantage of rendering the save format in one version unusuable for the next. Learned that recently in the hard way
 

rhumbaflappy

Moderator
Staff member
Resource contributor
#9
Hi all.

One of the amazing features of AFCAD was that it read the default BGLs and displayed the airport components accordingly.

To do this it is first necessary to read the BGL format. This is, in essence a BGL/XML decompiler. Lee never took AFCAD that way... he stopped work just short of this step. Lee read the bgl and translated it to his own intenal format.

I guess I'd suggest both ways. XML decompilation, and a representation internal to the program. This could produce a binary BGL directly from the internal representation, and offer it's XML decompilation as side benefit.

AFCAD + XML Decompiler.

At any rate, reading the BGL comes first... before any CAD operations could be performed. Does this make sense? Pete Dowson also expressed interest in some type of decompiler for the XML BGLs.

Dick
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#10
I agree with that Dick.

Arno you are right. If we are to do the job properly then we should start with a 'requirements statement' of some sort that will fit on a single page. I'm happy to put something rough together as a starting point for discussion. If you guys can give me 48 hours (the day job is going to get in the way today :) )

Oh and would someone like to come up with a working name for the program??? :)
 
Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#11
Hi Dick,

Yes, being able to read the BGL files is an important feature. But I don't think that is the only thing we should start with. Having an idea of what kind of tool we want to create is more important at first I think.

As we have quite some interest already, I think we are with enough people to start on the GUI (which should be independant of the scenery format anyway), while others work on the BGL reader.

Storing the BGL in some sort of internal format sounds like a good idea to me. That is also how I do it in my MDL Tweaker tool. From that internal memory format I can then save it in any format I wish (eg. MDL again, ASM code, OpenFlight, etc). I think this would be a good approach for the BGL format as well.
 
#13
Hello,

I'm new to the fs developer community so perhaps I have false thoughts about it. Does anyone have the source code for AFCAD, or at least can contact Lee Swordy ? Considering the minor changes in the BGL format, I'm sure the current AFCAD can be made compatible pretty quickly (even for the final release in 3 weeks).
If you consider adding new features (fences, jetways and a simconnect interface), it can be very small developments, maybe 2-3 months with testing.

Making a new AFCADish software is of course a great idea, and is a very long-term project. There is a logical step with this: afcad 1 was only about "logical" invisible infrastructures (gates, taxiways, runway), which can be though as '1-dimensionnal'. Afcad 2 added polygons capabilities, making it "2D". What we need is an AFCAD3 with full 3D capabilities, ie adding/editing buildings, signs, jetways and so on.
 
#15
I already have a tool that can do some of this work (I can't edit AFCAD stype stuff, only display it though).

I am considering updating it, but won't do it before we have WPF.

Currently the status is as follows:
1) Server client based. Sceneries are done by multiple persons. It must be able to run of a central server and automatically distribute the files to all developers.
2) The view must present a background items can be places on. Currently I get this from GIS data, but it really should come from FS.
3) Placing of 3D models using plugable transformations (repeaters to make fences, AutoLoD, seasonal textures, ground polygons, shadow on/off etc). A lot more usefull things could be added if time permitted (think flags turning to the wind, animation added depending on windspeed etc).

The MDL decompiler is obviously already in place, but needs a clean up a few places (support for animations mainly).


As a side notice I did a small utility to create simple buildings simply by drawing lines (as seen here: http://www.copenhagenscenery.com/Screenshots/Copenhagen Center 03.jpg) - they are a bit ugly as I am not good at textures, but besides this they are pretty easy to do. Unfortunately this use DirectX, so it would also have to wait for WPF before I can integrate it into my main tool.

I would be happy sharing my code with anyone working on such a project - and I can also contribute to development as time permits (as long as it is .NET 3.0 obviously, I will not waste my time with anything else). So a client using Windows Smart Client Factory running up against a WCF server. This will provide a decent base archetecture, and allow several people to work on it (specifically if it is put on www.codeplex.com).

PS: Binary serialization is dead - gone - over. No need to have a discussion at all, if it is too big, just zip it up like everyone else is doing. :)
 
Last edited:
#16
Good point - makes a lot of sense. I have seen some stuff somewhere which uses reflection to create a properties table from the class itself.
It is a part of the .NET Framework (a propertygrid).

You can also make custom types (I have latitude/longitude) and add you own dropdown controls - or if needed a modal dialog launched directly from the propertygrid as displayed here:
http://www.fsdeveloper.com/forum/attachment.php?attachmentid=1078&d=1147122754

The best known example of this being used is Visual Studio itself.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
#17
Hi Lars

Yep that is what I was thinking of. I saw that you are using it in your program and that looks pretty good. I have just gotten into custom control design and can see a lot of potential there.
 
#19
This person (Lee Steffensen) here

http://forums.avsim.net/dcboard.php?az=show_mesg&forum=126&topic_id=6993&mesg_id=6993&page=

says he has contacted Lee Swordy recently and was given the source code for TTools. I don't know why he had to contact Lee since the TTools Source code (unlike AFCAD code) has been available for several years.

The AFCAD program has many benefits but also causes other problems in many different areas if used as a stand alone utility.

There are numerous unseen element tags in the XML bgl files that AFCAD works with that causes additional problems and if a tool is going to be designed these issues need to be addressed.

AFCAD also decompiles and reads other XML bgls not just the airport facility information in the AP*bgl. This is so AFCAD can show the default NAVDATA on the grid even though it is not editable. By design the AFCAD program did not allow for any type default NAVDATA to be deleted/changed because this destroys all the Approach data that is part of the AP*.bgl.

There are Navaids as seen with AFCAD that can be moved (not deleted) because these are owned by the airport scenery data (embedded as TERMINAL_type navaids) and not stand alone Navaids which are in additional bgl's. AFCAD does have the ability to add either a TERMINAL_NDB or non-terminal NDB but all new VOR's (when added with AFCAD) are always nested above the airport header which FS9/FSX reads has non-terminal type VOR's.

Lee also by design used the deleteAllApproach=FALSE statement when he compiles back to a bgl so the enduser could not destroy any of the unseen airport scenery that applies to both the User and AI Plane behavior.

There are many other reasons why the FALSE statement is used which keeps the Approach data out of the 3rd party type AFCAD airport. One of which is that most payware designers place AFCAD type airports into their own folder or the FS addon scenery folder is used. This is ok as long as certain XML element statements are not part of that compiled bgl. However, AFCAD or any other designed utility airport tool does not read down through or understand the FS Generic scenery folder. If the Airport Facility Data includes the Approach data as per MS then this type bgl must reside in the Generic Scenery folder. Any additional AFCAD type bgl that is used to change parking and taxiways ends up as a duplicate which includes the Start Location element tag and that causes CTD. Start Locations are read by many parts of the FS code and used for many different aspects including the "Go To" as seen in certain menus.

AFCAD could have added the XML taxiway signs like so many wanted but how would we have edit/deleted exsisting signs without exclusions. Also the current exclusions only worked if the taxi sign was written in XML format. Some FS9 airports have multiple signs with just one reference point. Try to find that one. There is no element statement that says deleteAllTaxisigns=TRUE in FS9/FSX. Even to this day no decompiler can read taxiway signs correctly that are coded in XML due to certain characters that are used. Lee tried to explain this to some of the beta testers but was always bombarded with resistence.

One of the problems with most 3rd party airport scenery designers is the lack of understanding that Approach data in the AP*.bgl is unseen airport scenery data. If a 3rd party airport adds or changes an exsisting ILS using any of the tools that already exsist, this corrupts the approach phase that the ATC system uses which is based on the FSX "reality bubble". FS2002 used a 9 rectangle block matrix that was a 55 NM in all directions from the User Plane. FS2004 increased the bubble to 110 NM's in all directions from the User Airplane for many different reasons.

Lee Swordy mentions this "reality bubble" in is documentation for TTools but he called it the AI Active Zone which divides the world into a grid of sectors.

I am not a tool designer but have been writting XML code (long hand) for the past 3 years to help keep the Jeppesen Approach data in FS9 current.

On one of the other forums here at fsdeveloper Reggie Fields made some comments about AFCAD's compliance but it appears to have been overlooked and not questioned by anyone.

I could list a host of issues that need to be addressed including the simple segmentation of taxiways that FS2004/FSX uses that most designers destroy with different utility tools. Again, these are unseen and unexplained tags in XML coding that MS uses like so many other areas.

The original design of AFCAD (FS2002) was to add parking spots to accommodate additional AI Planes and also control those planes once on the ground. This did not change in FS2004 but Lee had to tweak AFCAD so it would work with certain portions of the XML code.

AFCAD is a 2 part program when you look at the grid. The first part is for the control of the User Plane and how NAVAIDS are used. The ILS that AFCAD displays is owned by the runway properties in the bgl's and only affects User Aircraft flyability.

The second part of AFCAD controls the AI Plane once it reaches the target point for touchdown and then ground movement to a parking spot. Embedded in some of this code is the 3 different elevations used by FS2004 and FSX. The AI Plane approach part of FSX has nothing to do with AFCAD but any type airport utility tool has the ability to corrupt that approach phase and ATC. This area of code is also weather related in FSX which is used by both type planes and must be considered when tools are designed.

In many cases I have started tutorials on how to write proper coding but the varibles change based on what a designer wants to accomplish with all the unseen scenery for a airport. All the XML coding that the User Aircraft is based on (behavior) must always be first and then if it is written correctly the AI Planes extract certain tags of this code for their behavior.

Once all the code is passed on to the dll's then MS combines additional ATC code for proper instructions including what is seen in the GPS receiver for both FS2004 and FSX.

My post is for awareness and certain issues that I do not see being discussed when designing tools. If a AFCAD type tool is designed with no thought process on how and why certain XML elements are added or left out (purposely) the core coding of FSX will become corrupt.

Rather then trying to design a tool that duplicates AFCAD, the new tool could remove most of what AFCAD does in its current state. The objective should center around a AFCAD type tool that does have the ability to add more parking spots, parking spot radius/codes, changing taxiways including taxi letter/number with segmentations, aprons, lights, freq's etc. BUT not be able to edit any portion of runway properties or Navaids for that runway.

Runway properties should be in a different tool that must contain additional appropriate Approach XML coding that coincides with all the runway properties. This type tool will encourage designers to learn how FSX uses different element statements (in bgl's) so airports will continue to work both when visibilty is greater/lesser then 3 miles. Weather is just one aspect that causes FS9/FSX to use 2 different approach codes for proper runway usage in FSX.

If I was a tool designer I could invision a base platform tool that resembled a AFCAD type tool with basic type changes that I listed above. Then add additional tool windows/panels if I wanted to do more complex coding.

One sub tool would first be used for any type XML data that does not require the Airport Header which FSX calls Scenery Objects (effects, generic buildings, triggers, fuel, model data, exclusion rectangles, etc.).

Another sub type tool would be for the Facility Airport data that must have a airport header and includes those areas that are not part of the base platform. Due to the complexity of the Facility Airport data there may have to be additional tools or panels which could break down certain areas so Taxiway signs could be added, Approach data written though the use of a standard ARINC document template, Boundry's, Navaids both terminal and non-terminal, Markers, Waypoints, Routes and Geopols. Another panel could address the Time Zones and Extrusion Bridge.

Various tools added to a base tool could also keep the proper XML elements together that FSX uses for different parts of the core coding (ie Runway properties/Approach data). When the base tool compiles it would sort/list both above and below the Airport Header and place some of the XML in its proper order as per the FSX BGLComp SDK. There is a pecking order for certain XML elements or the data will not be read correctly.

I hope some of this has merit
 
Last edited:

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#20
Hi Jim,

Thanks for your detailed post. It contains a lot of interesting food for thought.

You also explain very well how AFCAD has developed from a tool meant mainly to allow changes for the AI (parking spots, routes, etc). Unfortunately the same XML code is now also used for the visual aspect of the scenery, so that means the AI and scenery demands sometimes collide. The challenge is to find a good way out of that :).
 
Top