• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Some Thoughts on a Scenery Objects Class Model

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,850
Country
unitedkingdom
I have been doing some work on a class model for FSX Scenery Objects with the intention that it should support any type of object whether compiled via BGLComp, SHp2Vec or Resample. At the moment I have focused on BGLComp because that is the one I understand. I have used class inheritance rather than interfaces. There are a lot of properties floating about.

I have an Abstract Scenery Base Class which has properties for Name, Type, and Compiler and abstract methods for SourceCode and Draw. These are abstract to force classes which inherit from them to implement them as they will be different class to class. I have also a ToString Method which just returns Type and Name. The Draw method returns something that can be used to display the object in some way (will depend on the display method), and SourceCode returns the XML or whatever needed to compile that object using the compiler specified in the Compiler property.

All the top level Elements that BGLComp compiles inherit from this:
  • ModelData
  • ExclusionRectanngle
  • TimeZone
  • ExtrusionBridge
  • Airport
  • Vor
  • Ndb
  • Marker
  • Waypoint
  • Geopol
  • SceneryObject

There are classes for the sub Elements in objects like airports. I am following the XML Element/Attribute Model from the BGLComp SDK as closely as makes sense

SceneryObject is also an abstract class inheriting from SceneryBase but adding the properties common to all SceneryObjects. This forms the base for:
  • Beacon
  • Effect
  • GenericBuilding
  • LibraryObject
  • Trigger
  • Windsock

I have a class to encompass a complete bgl file. This contains a collection of SceneryBase objects and has methods to DeCompile, Compile and Draw. It should also handle persistence and make sure that the compile process builds separate bgls by Compiler and that the order of elements in the bgl are correct. One of these objects could be created by de-compiling one or more existing bgls or as a container for A scenery design project.
 
Messages
268
Country
netherlands
Jon,

I think you should take a step back and rethink parts of it based on how the user invision his scenery project, instead of how Flight Simulator stores it.

Basically the discussion we are having here:
http://www.fsdeveloper.com/forum/showthread.php?t=3008

The domain model should represent this, then we can simply make a data mapper (in form of a scenery generator) to write the necessary BGL files (and decompile them etc).

I would skip the Draw method as well - that belongs in the GUI layer (which probably means a new feature would require a number of plugins: datamodel, GUI, and DataMapper - they could still be programmed in one DLL (or even one class) but we should think of it as separate plugins).

I do not think we are completely done discussing the project structure - we discussed MDL files (with tweaks) and partly textures and libraries - but I do for example still not know how we should deal with generic FS buildings (treat them as libraries, or as single object nodes where you set the properties on the node and then place it whereever you like)
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,836
Country
netherlands
Jon, Lars,

I agree with Lars on the fact that we should first look at how the user sees the scenery he is making. That does not have to be the same structure as the XML code uses. The translation to the XML structure should happen underwater.

But on the other hand I think that for an airport the structure of the XML code will be very similar to what we come up with. So airport node at the top, runways, aprons, taxiways, etc below that.
But if we also want to integrate non XML style airport elements (like detailed markings, text written on the ground, etc) we might have to define the thing a bit more general. So then an airport could for example have "ground polygons", which can be either XML aprons, ADDCAT style polygons, etc.
I guess it is a good idea to use this thread to discuss further on this model.

For the GenericBuildings, I think we should see them at the same level as MDL models. They also contain a placement for example, but for the rest they can be described with some simple parameters like width, height, texture, etc. Only to generate a preview of the object do we need to know about the vertices and polygons of the object, but these need to be generated from the settings and can not be read from file.

Lars, I think I understand your comment about seeing the GUI, data model and data mapper differently. But on the other hand I can not oversee all the consequences of this yet, I think you are the only one here who has enough experience with all that stuff. I am a bit worried that this is turning out to be too complex for a FS designer who just wants to do a bit of programming in his hobby. We should keep the structure as simple as we can, so that as much people can contribute to this new tool.
 
Last edited:
Messages
268
Country
netherlands
Arno,

Seperation of GUI, model, and data mappers etc has one single purpose: To keep the code simple.
The alternative is to use this pattern which appears simpler when you start, but that will change pretty fast:
http://en.wikipedia.org/wiki/Big_ball_of_mud

Currently I am looking a bit into how much is changing with WPF - it seems the balance is switching towards Presentation Model (or Model/View/ViewModel) instead of Model/View/Presenter, but unfortunately I have not located any decent "best practices" document from Microsoft, only the lowlevel stuff on how you bind to XML files and other irrelevant info.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,850
Country
unitedkingdom
I agree with Lars on the fact that we should first look at how the user sees the scenery he is making. That does not have to be the same structure as the XML code uses. The translation to the XML structure should happen underwater.

I agree but I'm not sure that anything I have done exposes the XML structure to the user. These classes just store the information needed to persist the elements etc. Users create scenery based on a series of elements - none of the classes I am talking about are exposed to the user directly nor do they define any structure to the user, but should relate to the things they create. I would add to the ones that I have mentioned some others which can handle complex objects like Fence Lines and Area Fills. These would inherit off the same simple Scenery Base Class. The XML and the math and stuff is all hidden. I presume we have a tree structure representing the scenery being designed with each element of that tree representing a part of the scenery, be it objects, runways and so on. This is how most scenery design tools seems to work at the moment - are we trying to do something different here? Each node of the tree contains an object describing that node. This could either be some sort of text based file as per SBuilder which describes the project or a collection of objects. Myself I prefer the objects but maybe that is not the best way to do it.

We need to persist the information between sessions - now I would have serialized the object tree but Lars, you suggested before that serialization was not the best and there is a better way....

Maybe I am missing the whole point here but I see users creating or modifying an airport - in doing so they set a bunch of properties that define the elements of the airport be they runways or whatever. I think you are a level above what I am talking about here when you talk about how the users creates scenery or how they look at a project. That would be somewhere like my Overall class that contains the project information. But then, on the other hand maybe I don't really understand this scenery development stuff after all :)

But if we also want to integrate non XML style airport elements (like detailed markings, text written on the ground, etc) we might have to define the thing a bit more general. So then an airport could for example have "ground polygons", which can be either XML aprons, ADDCAT style polygons, etc

Which is why I have the base class define a method which should create the source in whatever form you want it and why it also defines which compiler should be used to turn that into a bgl. That does not have to be XML it could be ASM, BGL Op Codes or anything else that defines that particular thing. Provided the object knows what compiler it needs and the user has it then a correct bgl should appear. I presume this is how SBuilder works - after all SBuilder is the closest thing I have seen to what we are trying to achieve. It lacks Facilities data but can handle most other things. It may not generate the right stuff for FSX and it is not the prettiest tool on the block but it seems to work :)

On the subject of a draw method Lars I am simply saying that the object needs to be able to pass back what it wants to look like, I assume we don't want some other part of the application having to keep that information. At one level that could be a graphicsPath but more likely some other class to be defined which says I want to be shown on the GUI like this. Then it is dis-connected from the GUI which would figure out how to render it to the screen either via GDI+, DirectX or WPF, or all three ;)

I think you are the only one here who has enough experience with all that stuff. I am a bit worried that this is turning out to be too complex for a FS designer who just wants to do a bit of programming in his hobby. We should keep the structure as simple as we can, so that as much people can contribute to this new tool.

I have to agree with Arno on this one.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,836
Country
netherlands
Hi Jon,

But if these classes are only underwater, then we don't have to follow the XML structure here. For example you have included ModelData and SceneryObject. But the user does not care about how that is stored in the XML file, he is just placing an object.

So from that point of view it would make sense to keep our internal model as close to the point of view of the user. Only when we are exporting our project to FS, we need to make sure that the XML code gets the ModelData and SceneryObject commands. But before that we can see it as a "3D model" that has a certain placement.

For other elements that define an airport we can have similar examples I guess. So it is not neccesairy that the classes we use in our tool are the same as the XML structure. It is the export function (or whatever we call it) of our internal models that need to make sure the correct source code (or binary BGL) is written.

Maybe I am missing the whole point here but I see users creating or modifying an airport - in doing so they set a bunch of properties that define the elements of the airport be they runways or whatever. I think you are a level above what I am talking about here when you talk about how the users creates scenery or how they look at a project.

I guess that is right, but should we not use an internal model that matches how the user wants to use the tool? I think that would work better, so we first need to get that picture clear, before we go a level deeper.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,850
Country
unitedkingdom
So from that point of view it would make sense to keep our internal model as close to the point of view of the user.

That is where you lose me, or I am losing myself :)
For Example: Scenery Object, is an abstract class the concrete class is an object or an effect which I assume the user is interested in placing. I agree about ModelData it is irrelevant unless a user want to create his or her own library.

My understanding of classes is that they describe something physical like a building or a car or a runway or a firework display. I'm not trying to be diffucult here just finally get to the point of moving forward.

I think that would work better, so we first need to get that picture clear.

OK Let me know when you get there :)
 
Last edited:
Messages
268
Country
netherlands
Jon,

I am a bit in doubt what you mean with your description of classes as covering something physical. Are you referring to the classes we need in SDSX, or generally how classes are used when programming? Classes are in no way limited to physical objects (a project folder is for example still a class even though it is only used to structure the actual data).

The ModelData object mentioned isn't needed even if the user wants to create his own library. On the abstraction level we are looking at with a domain model, a library consist of a number of 3D models. These 3D models will not be represented in memory by their ModelData, but by a set of objects in the domain model. I outlined a possible domain model for the 3D models here:
http://www.fsdeveloper.com/wiki/index.php?title=SDSX_domain_model_for_3D_models

It will be the responsibility of a data mapper to create the ModelData byte sequence based on the objects in the domain model.

Generally speaking I am not trying to say your model is far off what it should be. Some things will need to be refactored to datamappers etc, and it all has to be build into a larger domain model structure, which means your parent objects like an object wrapping a BGL file will probably not be needed, and we might want to do for example taxiways different than the structure used in the XML files (I do not think so, but can't say for sure - that one is a bit tricky).

PS: I am not sure when I said what about serialization - we need to serialize no matter what, but it can be done in a number of ways.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,850
Country
unitedkingdom
Hi Lars

I am a bit in doubt what you mean with your description of classes as covering something physical. Are you referring to the classes we need in SDSX, or generally how classes are used when programming? Classes are in no way limited to physical objects (a project folder is for example still a class even though it is only used to structure the actual data).

I was referring to classes in general not for SDSX, but as you say classes can represent many other things and do/


The ModelData object mentioned isn't needed even if the user wants to create his own library. On the abstraction level we are looking at with a domain model, a library consist of a number of 3D models. These 3D models will not be represented in memory by their ModelData, but by a set of objects in the domain model. I outlined a possible domain model for the 3D models here:
http://www.fsdeveloper.com/wiki/index.php?title=SDSX_domain_model_for_3D_models

I need to read that a bit more carefully :)

It will be the responsibility of a data mapper to create the ModelData byte sequence based on the objects in the domain model.

I think this is where I run out of understanding a bit as I am just an amateur programmer and things like the term data mapper does not really mean anything to me at the moment. I probably understand the concept but can't connect it to the words.

Generally speaking I am not trying to say your model is far off what it should be. Some things will need to be refactored to datamappers etc, and it all has to be build into a larger domain model structure, which means your parent objects like an object wrapping a BGL file will probably not be needed, and we might want to do for example taxiways different than the structure used in the XML files (I do not think so, but can't say for sure - that one is a bit tricky).

OK I guess I need to wait and see how that turns out.


PS: I am not sure when I said what about serialization - we need to serialize no matter what, but it can be done in a number of ways.

It may have been in relation to binary serialization of object collections.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,850
Country
unitedkingdom
http://www.martinfowler.com/eaaCatalog/dataMapper.html

It is specific for a database, but in reality you can use them for other things (lige BGL format etc) as well.

Binary serialization is indeed dead and burried, but we can always serialize to XML (and if it gets too big, we serialize to zipped XML) :)

Thanks Lars Martin's site seems to contain a lot of useful information.

by XML I guess you mean SOAP? or is there another way now?
 
Messages
268
Country
netherlands
Thanks Lars Martin's site seems to contain a lot of useful information.

by XML I guess you mean SOAP? or is there another way now?

No, I mean XML as in XML - nothing fancy there. ;)

SOAP (Simple Object Access Protocol or something like that) is a protocol used to do remote calls - the things we in old days would do with a proprietary binary protocol over TCP/IP, or using CORBA/DCOM. SOAP is still in use, but luckily we no longer have to deal with such a low level protocol as WCF takes care of the trivialities.
 
Top