project structure and specification of model placement

[lmoelleb]

Let me first go though the project structure as I see it. it is basically a tree structure, where the parent node determines which child nodes are possible (runways only possible under an airport node for example).

Project Node
|
+-- Project Folder
.... |
.... + -- Airport
.......... |
.......... + -- Runway

The project folder is purely administrative - it can be used to separate by area, scenery designer, or whatever the creators of the scenery desire. The Project Node itself inherits from Project Folder and it is hence not required to make any further project nodes.

Clearly in this example, both the airport and the runway has a position. We can simply store these as latitude/longitude and only at the time we write the scenery we will make the runway location an offset from the airport reference point.

3D models (and effects, but for simplicity I'll just mention models in this) are a bit different. The BGL file specifying the placement simply contains a reference to the object. This allow the same model to be placed multiple times without repeating the data as we all know.

The question is how we should model this in our domain model, and how we should present it to the user. While it is given how we should store the final BGL file, we do have the option to transform it when reading from or writing to BGL from our domain model, and we have yet another option to do so when the vew and presenter shows the data to the user.

The problem as far as I can see is (as usual) that we have two use cases:
1) Placement of generic objects at different locations.
2) Placement of specific objects only used in one location.

Use case 1) suggest a userinterface where the user can maintain his object library centrally, and then place these at various locations. Basically maintaining the reference.

Use case 2) suggest the model should be kept within the location specific project folder. It would still be possible to use library objects - but you would do so by placing an object and specify which library and GUID to use. The same library (or model) could be added several places.

As far as I can tell, use case 2) most closely match how my users are thinking as they are really working on specific airports or areas, then moving on to the next when they are done. It gives a problem for generic objects which must be placed in their own Project Node and then placed accross the scenery.

So far my tool has used method 2), and it works for us - but we are not really using library objects. I would like to see some thougts on how to support both usecases efficently in the GUI. We might even split objects in generic and specific - which would also provide the default for how the object should be stored in the BGLS - in library (generic models) or in the same file as the placement (specific models).

 

[arno]

Hi Lars,

Are those two use cases really different? I don't think so. In both of them the users want to be able to select and object and place it at a certain location. Looking at the XML code to do this, there is no difference either.

The only difference is where the object comes from. Seen from the user it is either a default object, that he can select from some sort of list, or a MDL file he has created himself. The default object links to a GUID already, while for the MDL object the tool would have to create that GUID and use it. This is also how I do it in ObPlacer XML, you can add your own MDL objects to the list of available objects to place.

If we do this by storing the <ModelData> tag in the placement XML file or in a seperate library XML file is not really of interest to the user I think. That is a decision we have to make underwater.

The structure you propose sounds logical, it also follows how the XML works (so runway can only be in an airport, etc). I assume the scenery objects are in the project folder as well (they don't have to belong to a certain airport).

 

[scruffyduck]

I agree with Arno on this - the method and XML code generated could be different but the goal is the same - to place an object in the scenery.

Also the structure looks right to me.

 

[lmoelleb]

There is certainly no difference in what is possible. It is a difference in organization. The problem is that if you have hundreds of specific objects to add (so objects only placed once each) I would create a hirarcy to store the objects according to location. If the library and placement is kept seperately, would I be forced to make the same hirarcy twice? That would not really be smart.

 

[arno]

OK, I understand your point now. I think I would follow the structure of the XML code here, so keep the placement (<SceneryObject>) and the objects definition (<ModelData>) seperate. I don't think this will really duplicate things, we just need two lists, where the items in the placement list point to an object in the available object list.

 

[lmoelleb]

OK, I understand your point now. I think I would follow the structure of the XML code here, so keep the placement (<SceneryObject>) and the objects definition (<ModelData>) seperate. I don't think this will really duplicate things, we just need two lists, where the items in the placement list point to an object in the available object list.

I agree this works for the Domain Model, just wondering if you have an idea about how to deal with it in the GUI?

 

[arno]

Not really sure what you mean here, but for the GUI I see it as two lists as well. We should have one panel that shows all objects available to be placed. And the 2D map will show the "list" of all already placed objects. Maybe we can also have a panel that shows a tree view of the placed objects.

 

[lmoelleb]

Not really sure what you mean here, but for the GUI I see it as two lists as well. We should have one panel that shows all objects available to be placed. And the 2D map will show the "list" of all already placed objects. Maybe we can also have a panel that shows a tree view of the placed objects.

I have been thinking a bit about this as well, and have reached the oposite conclusion of the one you made.

First of all with regards to the domain model. A specific 3D model is being placed at (potentially) several positions. This is a standard one to many relationalship where the placement only makes sense seen from the model. If you for example delete the model, you would delete the placements of it as well - the opposite is not the case. It is hence a composition (if I remember my UML terms correctly), and the standard way to handle that is simply making the placements a collection contained in the 3D model. I know the standards should not always be followed, but we would need a reason to break away from them, and I fail to see that reason here.

With regards to the GUI, I beleive the tree structure should apply to the available models as a number ofthem will be specific to a single location. The generic models can then simply be placed in their own branch in the tree. I do not see the reasons for two panels either. If you select a model, information on where it is placed is simply properties on that model, along with all other properties. I do not see what contextual makes them different?

I am aware this would take the placement of the generic models out of their tree context (for example the specific airport) and I agree that is REALLY bad.... but I do not think it is as bad as separating two things as strongly connected as a model and the placements of the model.

Sorry this got long and probably rather muddy.... I still sucks at explaining this kind of things.

 

[arno]

Hi Lars,

Looking at it from that direction indeed makes it sound logical to have the placement as a property of the object. But I am not fully convinced yet . I still see a lot of causes where we could do the placement without knowing much about the object, so in that case loading the object seems like a waste of time to me. I guess I need to think a bit more about this.

About the GUI. I am seeing it a bit like the VS interface. On one side you have a panel that shows you all kinds of objects you can place. Could be as a tree or maybe with tabs or whatever. From there you can then drag-drop them into the map view to place them.

But as a map view is not always the easiest way to see an overview of all the objects you have placed, I think it would also be nice to offer the user an option to see all placed objects in a tree structure or so. So that are the two parts of the GUI I mentioned.

For the structure, I think we should keep 3D objects outside of the airport all the time. That is also how it is stored in the XML code. SceneryObjects have no link to a specific airport, apart from their location.

 

[lmoelleb]

Hi Lars,

Looking at it from that direction indeed makes it sound logical to have the placement as a property of the object. But I am not fully convinced yet . I still see a lot of causes where we could do the placement without knowing much about the object, so in that case loading the object seems like a waste of time to me. I guess I need to think a bit more about this.

Standard pattern again: Lazy Loading. In short we will instantiale the 3D Model object, but the actual 3D data does not need to be created before accessed.

About the GUI. I am seeing it a bit like the VS interface. On one side you have a panel that shows you all kinds of objects you can place. Could be as a tree or maybe with tabs or whatever. From there you can then drag-drop them into the map view to place them.

But as a map view is not always the easiest way to see an overview of all the objects you have placed, I think it would also be nice to offer the user an option to see all placed objects in a tree structure or so. So that are the two parts of the GUI I mentioned.

When you select an object it should indeed be possible to see all locations (and move the map to their location). Currently I display them on a tab page, but we can probably also show them in a propertygrid - whichever makes most sense when we get to that part of the design.

For the structure, I think we should keep 3D objects outside of the airport all the time. That is also how it is stored in the XML code. SceneryObjects have no link to a specific airport, apart from their location.

Its not a big deal, but I am not fully convinced. I am quite sure people think of some objects (for example a control tower) as part of the airport itself. We would hence force them to make an extra project node to deal with this. Considering how easy it is to support the model both places I think we should do it. I am aware it is not how it is done in FS, but we can easily deal with this when generating the scenery, and with OO design, it is not any extra work to allow it.

 

[arno]

Hi Lars,

Standard pattern again: Lazy Loading. In short we will instantiale the 3D Model object, but the actual 3D data does not need to be created before accessed.

OK, you (almost) convinced me now. If we don't load the actual 3D data before it is needed, that is no problem anymore. So at the beginning the objects are not much more than a placement position, heading and some GUID and footprint info as needed by the GUI.

But what does this mean for all the default objects that are available, would they also have a (basic) object created in memory, even if we do not place them.

When you select an object it should indeed be possible to see all locations (and move the map to their location). Currently I display them on a tab page, but we can probably also show them in a propertygrid - whichever makes most sense when we get to that part of the design.

Agreed, but I think this should also be visible when you don't click on a specific object. FSSC has such a list for example and sometimes I find that an easier and faster way to find an object, than locating it on the map. But for these GUI details I think we should start another discussion later .

Its not a big deal, but I am not fully convinced. I am quite sure people think of some objects (for example a control tower) as part of the airport itself. We would hence force them to make an extra project node to deal with this. Considering how easy it is to support the model both places I think we should do it. I am aware it is not how it is done in FS, but we can easily deal with this when generating the scenery, and with OO design, it is not any extra work to allow it.

Agreed, we can use a different internal model, than the output to FS will be. But would it not be better to make the designers aware of the structure FS uses? I think it would be better to give them a proper idea of how it is structured in FS. Else they might think the tower will be in the BGL of the Airport tag, while it will not be. But this is no big issue to me.

 

[lmoelleb]

OK, you (almost) convinced me now. If we don't load the actual 3D data before it is needed, that is no problem anymore. So at the beginning the objects are not much more than a placement position, heading and some GUID and footprint info as needed by the GUI.

But what does this mean for all the default objects that are available, would they also have a (basic) object created in memory, even if we do not place them.

On demand should be fine first, then we figure out what to do to improve performance when we see how bad it is. Calculations can be done in a background thread so the GUI stays responsive. It means you might get a dummy object at first (however we display that, currently I simply use a small square, but did consider drawing an hourglass), then it will get updated when the processing is done. This is pretty standard (and simple) stuff to do.

Agreed, but I think this should also be visible when you don't click on a specific object. FSSC has such a list for example and sometimes I find that an easier and faster way to find an object, than locating it on the map. But for these GUI details I think we should start another discussion later .

I refered to selecting a model in the tree, not clicking it on the map, so this is provided automatically. This is also how I normally locate objects in my current tool. Clicking the object on the map will obviously also select it in the tree (activatinhg the specific placement to allow movement etc).
If we use MPF we could simply show a small rotating preview of the model inside the tree, but I am afraid computers are rather slow these days, so it might not work out... still worth trying though.

Agreed, we can use a different internal model, than the output to FS will be. But would it not be better to make the designers aware of the structure FS uses? I think it would be better to give them a proper idea of how it is structured in FS. Else they might think the tower will be in the BGL of the Airport tag, while it will not be. But this is no big issue to me.

[/QUOTE]
Personally I do not want to know that kind of details. I want to modify or add scenery, and given how some things apparently must be in some files I would rather not know as a user.

 

[arno]

It means you might get a dummy object at first (however we display that, currently I simply use a small square, but did consider drawing an hourglass), then it will get updated when the processing is done.

Sounds good.

If we use MPF we could simply show a small rotating preview of the model inside the tree, but I am afraid computers are rather slow these days, so it might not work out... still worth trying though.

That is certainly something I would like to do. Show a little preview of the object somewhere.

Personally I do not want to know that kind of details. I want to modify or add scenery, and given how some things apparently must be in some files I would rather not know as a user.

I think a certain level of knowledge about the underlaying scenery engine should be promoted. Putting it a bit black-white, we don't want the tool to generate a bunch of BGL files, while the developer has to guess what has ended up in which file. He should now that the stuff he can edit with AFCAD for example is in this file, while his 3D objects are in that file. So I think that should of stuff should be transparant to the user and not hidden deeply in the software.

If they understand better how the scenery engine works, they will also understand why certain things work (or don't work) as they do.

 

[lmoelleb]

I think a certain level of knowledge about the underlaying scenery engine should be promoted. Putting it a bit black-white, we don't want the tool to generate a bunch of BGL files, while the developer has to guess what has ended up in which file. He should now that the stuff he can edit with AFCAD for example is in this file, while his 3D objects are in that file. So I think that should of stuff should be transparant to the user and not hidden deeply in the software.

If they understand better how the scenery engine works, they will also understand why certain things work (or don't work) as they do.

I guess we disagree on this one. I find it essential that we can change what is written where (and how) without in any way effecting the domain model.

Notice I am not saying it shouldn't be documented how we write the files, but if we find out a more efficent way to generate the scenery files, we should not force the user to rearrange his project.

 

[arno]

Hi Lars,

I agree about the domain model, we should just structure that as we wish. But for I still support what I described above.

 

[tgibson]

Hi Lars,

I understand your desire to hide the file details from users, but when a developer sets up a complex folder system, how is he/she going to know how to package multiple libraries that share objects between projects?

If you don't have a sophisticated packaging procedure in your program, I will need a detailed list of which bgl files are actually needed for this particular project, and their locations in my file system.

For example, I have four projects (Las Vegas, California, Southern States, and Honolulu) that share library objects found in a fifth folder (CalClassic Core). I will need to know which files in that fifth folder are required for each scenery so I can pack them into the proper install files.

Hope this helps,

 

[lmoelleb]

Hi Lars,

I understand your desire to hide the file details from users, but when a developer sets up a complex folder system, how is he/she going to know how to package multiple libraries that share objects between projects?

This is not what I am talking about. I am talking about the need to generate for example runways in one BGL file, and MDL files in another. I - as a scenery designer - do NOT want to know how this should be done. And I certainly do NOT want to have to tell the desigers I work with.

If you don't have a sophisticated packaging procedure in your program, I will need a detailed list of which bgl files are actually needed for this particular project, and their locations in my file system.

Hmm, we are talking about creating an advanced scenery program able to do preview of 3D models, map placements and what-not. I think we will be able to come up with such a list without increasing the complexity too much.

For example, I have four projects (Las Vegas, California, Southern States, and Honolulu) that share library objects found in a fifth folder (CalClassic Core). I will need to know which files in that fifth folder are required for each scenery so I can pack them into the proper install files.

Hope this helps,

If importing a library, you will see the library in the project tree, including the individual models. You can then select to simply copy the library to the generated scenery (if a model from it is placed, else it can obviously be ignored), or to have it copied to a separate location. This should solve your problem.

 

[scruffyduck]

If importing a library, you will see the library in the project tree, including the individual models. You can then select to simply copy the library to the generated scenery (if a model from it is placed, else it can obviously be ignored), or to have it copied to a separate location. This should solve your problem.

One thing to be aware of here is that the majority of designers placing objects will use 3rd party object libraries (of which there are hundreds). In this situation the generally accepted way of doing things is not to package the libraries with the scenery but tell the end user which libraries are needed - they may have them, and if not then they can get them from source. For example I mentioned in the original spec the need for the program to be able too 'analyze' a scenery project - I do this with LOM and it returns a list of libraries used by the scenery project, and details of that library so that the designer can pass on the information in the installation instructions.

On the other hand if we are talking about special libraries or objects only for one scenery then we can either distribute that library with the scenery, or if the objects are Geo locked then they can actually be in the scenery placement bgl.

 

[lmoelleb]

One thing to be aware of here is that the majority of designers placing objects will use 3rd party object libraries (of which there are hundreds). In this situation the generally accepted way of doing things is not to package the libraries with the scenery but tell the end user which libraries are needed - they may have them, and if not then they can get them from source. For example I mentioned in the original spec the need for the program to be able too 'analyze' a scenery project - I do this with LOM and it returns a list of libraries used by the scenery project, and details of that library so that the designer can pass on the information in the installation instructions.

On the other hand if we are talking about special libraries or objects only for one scenery then we can either distribute that library with the scenery, or if the objects are Geo locked then they can actually be in the scenery placement bgl.

Yes, hence the option of not including the source library when generating the scenery - and we already discussed that an option should be available on non-library objects allowing the user to specify if they are written to separate library files or included in the same BGL as the placement.

This is all extremely simple and can't give any problems. What I wonder more about is how to deal with the texture files. After all, these can be shared across models - not just models from the same library, but custom "one use only" models can share for example a roof texture.

 

[scruffyduck]

This is all extremely simple and can't give any problems. What I wonder more about is how to deal with the texture files. After all, these can be shared across models - not just models from the same library, but custom "one use only" models can share for example a roof texture

It's easy to identify the textures used by a scenery project. So we can generate a report. It's also easy to identify if textures are missing on the users machine (a small utility could do it - the texture information is in the MDL file as you know)

If we specify a library then that will include either the textures it needs or contain them in the distribution package.

One thing I have been trying to standardize for a long time is where people put their addon object libraries. In my tutorials I recommend creating a single location in their Addon Folder. I call mine Static Objects Library (same as the RWY12 one). This as the advantage of not duplicating textures all over the place.