• 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.

Use cases for 3D model placements

Messages
268
Country
netherlands
As far as I have understood, there is a consensus that 3D model placement is one of the first things we want to support. So I thought I would start by throwing a number of use cases on the table, just to get a feeling what would be required to do this.

I can think of the following use cases:

  • Place default FSX objects
  • Place objects from an object library (BGL)
    Two variants here: a completely external library, or one that is going to be included in the scenery - these are identical with regards to placing the object, but should behave differently when generating the scenery.
  • Place single objects originating from for example MDL files. These must be assembled to a library as the scenery is generated, and should support modifications like Arno's TweakMDL or my AutoLoD in an extensible way.
I consider moving objects as outside of the original scope as I have not investigated how this is done in FSX, but if someone knows better than me that it is possible for a first release I would not object.

Another possibility is to add the posibility to create object libraries - and then place the models as you would any other library. This would force the user to assemble the objects in libraries instead of having the program doing it automatically.

Did I forget something obvious? Or less obvious?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Hi Lars,

Agreed in general. But I have a few points for discussion.

Are we going to support Fs9 or FsX MDL files or both? The format is them is quite different. And from what I now know about the FsX MDL format, most tweaks MDLTweaker can add are not possible. On the other hand, if we support both you need to generate two types of libraries.

The other point is the libraries themself. As you know you don't have to include MDL files in a library, you can also add and place them in the same file. But this results on geo-locking of the objects. I am not sure if we should force the user to use libraries (even if it happens underwater). I would prefer to leave the user some choice there. But if the users choices to use a library, I think we should hide the generation process for him. It is quite simple, you it would not make sense for the user to have to perfrom extra mouse clicks for that.

Another point of discussion is how to use other object libraries? This can be the default MS ones, but also addon libraries created for Rwy12, EZ-Scenery, etc. Do we want to read the information about those objects from XML files or shall we read the BGL file itself directly. The last is probably more flexible, although you loose the naming of objects (for Fs9 MDL objects at least). So in that case we might need to keep a catalog somewhere that matches GUIDs with names. But I would prefer to take that approach.

What do you mean with moving MDL objects? I assume you mean something different than placing them at a certain lat/lon.

The last point is that we should probably also allow the placement of effects, default windsock, generic building and beacon objects. These are all placed with the XML SceneryObject command as well. So we should probably include them here.
 
Messages
268
Country
netherlands
Hi Lars,

Agreed in general. But I have a few points for discussion.

Are we going to support Fs9 or FsX MDL files or both? The format is them is quite different. And from what I now know about the FsX MDL format, most tweaks MDLTweaker can add are not possible. On the other hand, if we support both you need to generate two types of libraries.
Personally I would prefer reading both (I still need to read single object FS2002 BGL files for my scenery - luckily without animations etc) so designers won't have to regenerate their files - yes, correct guess, one of my team members lost his source files. I can send you the code I have for it in C#. You might prefer to do the decompilation in another way (the one I have do not read the transformation table correctly, it is hacked to get the right result from a default export), but it might save you some typing in case you can reuse my BglCommand objects etc unless it has changed 100% for FSX.
Output in both formats would be great, but not worth spending a lot of time on I would say.
The other point is the libraries themself. As you know you don't have to include MDL files in a library, you can also add and place them in the same file. But this results on geo-locking of the objects. I am not sure if we should force the user to use libraries (even if it happens underwater). I would prefer to leave the user some choice there. But if the users choices to use a library, I think we should hide the generation process for him. It is quite simple, you it would not make sense for the user to have to perfrom extra mouse clicks for that.
Agree. It can simply be a property on the object (we can always toss a coin what the default should be later on).
Another point of discussion is how to use other object libraries? This can be the default MS ones, but also addon libraries created for Rwy12, EZ-Scenery, etc. Do we want to read the information about those objects from XML files or shall we read the BGL file itself directly. The last is probably more flexible, although you loose the naming of objects (for Fs9 MDL objects at least). So in that case we might need to keep a catalog somewhere that matches GUIDs with names. But I would prefer to take that approach.
Agreed. We can let the user rename the objects from the Guid in the GUI. As a future solution we might make it possible to supply an XML file mapping the names as well, but I would not worry about that now.
What do you mean with moving MDL objects? I assume you mean something different than placing them at a certain lat/lon.
Ships and cars moved around with SimConnect. Not sure it is possible, just hoping. :)
The last point is that we should probably also allow the placement of effects, default windsock, generic building and beacon objects. These are all placed with the XML SceneryObject command as well. So we should probably include them here.

I knew there was something I forgot :)

I might come with a short draft on a few design possibilities of the GUI and businesslogic in the following days.... now I got the brain started. I'll start it as forum discussions, then move it to the wiki after a few days. It is obviously still open for forum discussion after it is moved to the wiki, but we need to get something a bit more solid. Or is it better I simply write something on the Wiki, and then we discuss it here?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Personally I would prefer reading both (I still need to read single object FS2002 BGL files for my scenery - luckily without animations etc) so designers won't have to regenerate their files - yes, correct guess, one of my team members lost his source files. I can send you the code I have for it in C#. You might prefer to do the decompilation in another way (the one I have do not read the transformation table correctly, it is hacked to get the right result from a default export), but it might save you some typing in case you can reuse my BglCommand objects etc unless it has changed 100% for FSX.
Output in both formats would be great, but not worth spending a lot of time on I would say.

Reading the pre-Fs2004 BGL files (or APIs) is a good point. I want to add a converter that allows people to transform them in MDL objects. So we could use that as well.

The FsX MDL format does not seem to use any BGL opcodes anymore. So from that point of view it has completely changed. I will continue to study this new format (I can almost draw a simple object from MDL file). Once I know more, I'll let you all know. Unless someone else wants to dig in the MDL format of course, we don't need to do double work here :).

About your C# code, I am always interested to have a look at it. Hopefully we can reuse it (or most of it). From coding my MDL reader in MDLTweaker I have learned a few things that I would like to do different this time :).

Agree. It can simply be a property on the object (we can always toss a coin what the default should be later on).

Agreed.

Agreed. We can let the user rename the objects from the Guid in the GUI. As a future solution we might make it possible to supply an XML file mapping the names as well, but I would not worry about that now.

Agreed.

Ships and cars moved around with SimConnect. Not sure it is possible, just hoping. :)

Ah yes. That is something I have been thinking about for some time already. Maybe we can do this by tweaking the MDL later on or maybe with the new AI? But for now I would put this on the wishlist, the other things go first.

Or is it better I simply write something on the Wiki, and then we discuss it here?

I don't really mind, but I guess discussing it here first might be better. Unless you think you can explain your idea better on the Wiki of course :).

I think we also need to start a discussion on how to store the scenery internally in the tool. It should be a format that we can read easily from the BGL and write to XML/BGL afterwards (and also SHP in the future). I'll do some thinking about this and come up with some ideas.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Are we going to support Fs9 or FsX MDL files or both? The format is them is quite different. And from what I now know about the FsX MDL format, most tweaks MDLTweaker can add are not possible. On the other hand, if we support both you need to generate two types of libraries.

My vote is for both

The other point is the libraries themself. As you know you don't have to include MDL files in a library, you can also add and place them in the same file. But this results on geo-locking of the objects. I am not sure if we should force the user to use libraries (even if it happens underwater). I would prefer to leave the user some choice there. But if the users choices to use a library, I think we should hide the generation process for him. It is quite simple, you it would not make sense for the user to have to perfrom extra mouse clicks for that.

I don't see why we shouldn't allow for placement from libraries or placement of individual mdl files. I also agree that compling bgls (if I understand your point correctly) should be hidden.

Another point of discussion is how to use other object libraries? This can be the default MS ones, but also addon libraries created for Rwy12, EZ-Scenery, etc. Do we want to read the information about those objects from XML files or shall we read the BGL file itself directly. The last is probably more flexible, although you loose the naming of objects (for Fs9 MDL objects at least). So in that case we might need to keep a catalog somewhere that matches GUIDs with names. But I would prefer to take that approach.

The way I have done it in Library Object Manager is to create a catalog of objects keyed on GUID and then given the user the tools to either import object information from source such as EZ- Text files, or RWY12 xml files. It seems to me that this is nooed so that the user has easy access to all the objects when using them in Scenery. If I am correct then Object Placer XML has a similar mechanism to catalog user libraries.

The last point is that we should probably also allow the placement of effects, default windsock, generic building and beacon objects. These are all placed with the XML SceneryObject command as well. So we should probably include them here.

The draft description says that the program should be able to place any XML based object. This needs to include the airport objects such as runways and so on. I am mindful that probably one of the most pressing things is to create something to replace AFCAD in FSX.
 
Messages
268
Country
netherlands
...
I think we also need to start a discussion on how to store the scenery internally in the tool. It should be a format that we can read easily from the BGL and write to XML/BGL afterwards (and also SHP in the future). I'll do some thinking about this and come up with some ideas.

I am not sure if you refer to the domain model or the data mappers (file format). The file format I would not worry too much about, that is something the data mappers must deal with once we have the domain model. I would guess we simply go for XML for a start, then we might add SQL Server Express support (specifically for the server).

The domain model should not be too hard. You do not need to serialize the models you load through MDL etc, we can just store the MDL file (we need to store other files like library BGL's, textures, etc anyway) and reload from that... Unless you plan to make the decompiler painfully slow of course :) :)

Basically I am invisioning a tree structure (datamodel and GUI) where each node can store node specific data, including references to one or more binary source files.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
The draft description says that the program should be able to place any XML based object. This needs to include the airport objects such as runways and so on. I am mindful that probably one of the most pressing things is to create something to replace AFCAD in FSX.

Yes, and I also would like to add stuff like approaches, as it is very hard to create them now. But for the initial version I guess we can concentrate on the objects. As long as the structure is general enough, we can add the other stuff to it easier after that.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Basically I am invisioning a tree structure (datamodel and GUI) where each node can store node specific data, including references to one or more binary source files.

I was not yet talking about the file format in which we want to save the data, more about the format we use internally to process the data.

Are you saying that you want to store the BGL files that are read as is and interpret them each time you want to draw or something like that? (I have probably missed your point here). I was assuming we would read the BGL files into some sort of internal format, that we can manipulate more easily.

For the MDL files I don't think we need to keep them in memory all the time. We only need to extract some information from them once (like footprint, etc). And the tool will have some functions to alter the MDL files, but that would only require loading the MDL when the user demands it.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Are you saying that you want to store the BGL files that are read as is and interpret them each time you want to draw or something like that? (I have probably missed your point here). I was assuming we would read the BGL files into some sort of internal format, that we can manipulate more easily.

Yes that was my though as well - pull the data into an object

For the MDL files I don't think we need to keep them in memory all the time. We only need to extract some information from them once (like footprint, etc). And the tool will have some functions to alter the MDL files, but that would only require loading the MDL when the user demands it.

Again I would grab what we need into an object. For 3D objects I tried to speed things up by saving an X file as there is a lot of data. But in LOM I read in the data needed for the objects from the mdl file and save it in an object collection - after that there is no need to go back to the mdl file again
 
Messages
268
Country
netherlands
Yes, we need a in memory object model (as you will se I already did this in the code I send you Arno).

Alternatively to letting the data mapper store the MDL file to be able to decompile again next time we open the project we could simply decompile the MDL when it was first imported (or updated), then serialize this internal memory format as part of the project file - this means we would no longer rely on the MDL file (I do not recommend this - it is the alternative to what I recommend). It would probably perform faster this way, but it would be more code and hence more risk of error.

Reading it all into memory is no problem at all, so what I do is simply having a low priority thread decompiling and transforming my 3D models taking the models closest to the displaycenter first. It is a bit hacked in my current code, but works quite fine, and can easily be designed in from the start.
 
Last edited:

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
I guess the question I have is where the mdl data comes from - does that mean that we need to extract an mdl file from it's library each time we want to use it? I agree in the 3D scenario we need most of the information about the object. In a 2D scenario we only need footprint information to draw a box, and if we want to create a more accurate representation of the object then we would need to extract enough vertex information in the XZ plane to draw the bottom - this could then be stored in the object in the object catalog.

Programs like EZ-Scenery, or LWMViewer2 probably read object data on the fly - but that is because they are constucting 3D objects on the screen

On the other hand maybe I am missing the point :)
 
Messages
268
Country
netherlands
I think we are simply looking at two different use cases, and hence coming up with different ideas. We probably both needs to look a bit close at the usecase the other is considering before we come up with a final solution (which might be to do both depending on said usecase). Or simply do whichever gives us a result fastest (least programming time) and then implement the other later on.

From what I can read you are considering the use case where objects are placed from a scenery library. This could indeed be done with a very limited object model storing the 2D only. There is however the other use case: The one where the model is an export from for example GMax. This model I want to load into the project. I'll then perform a number of transformations on it, for example: Change it so it has seasonal textures, remove the shadow from some elements, create LoD automatically. I'll then place this version of the object 3 times, and another version where I have added an animation (opening hanger door for example) one time. When the scenery is generated a library with the two different objects must be generated automatically (the original MDL file isn'teven included as it is not placed anywhere).

This requires a full blown 3D object model - and so does the 3D viewer of the objects in the libraries. Now, you are completely correct we can generate the 3D model, extract the 2D footprint and cache it. And we probably should (when time permits, it is a performance enhancement I personally prefer to do when we actually have something on screen - and we might simply use Microsoft's caching model and keep it out of our stored files). What we are saying is that we do not need to store the parsed 3D model in the project files - we will decompile it when we need the 3D model.
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Lars we are certainly looking at different use cases here. I will try and make a list of use cases that I can see in the next day or so - hopefully that will help to keep things clear. In any case I can understand that a use case which imports direct from GMax will need different information and approach than using library objects which may already be stored in a persistent collection in the program.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Yes, we are indeed talking about two things here. At first I would concentrate on how we store the XML/BGL data in memory. Storing the MDL files seems less of a problem to me, as we don't need that data all the time. It is not used to draw the 2D map view (maybe the footprint, but we can extract that). All other action we do with the MDL files are more single actions (like changing LODs, textures, etc) and it would not be a problem to read the MDL before such an action again.

Jon, you talked about decompiling libraries to get the MDL. Yes, that is sort of what we need to do, but not by using a stand-alone decompiler. We can just read the MDL files directly out of the library BGL (MDL Tweaker can already do that for most library BGL files). If we make changes to the MDL afterwards, we need to save it to disk as MDL of course.

But as I said at the start of this post, I would concentrate on the data model for the XML data, as we will need that first.
 
Messages
268
Country
netherlands
If we make changes to the MDL afterwards, we need to save it to disk as MDL of course.
I do not fully agree here. I beleive we should store WHAT we have changed so we can reapply the data again if the source model is changed/updated. Of course we might later choose to speed things up by caching it, but that would be a separate cache, not a part of the data model.
But as I said at the start of this post, I would concentrate on the data model for the XML data, as we will need that first.

I am not sure what you refer to as XML data. Is it for example the Airport XML element with runways, taxiways, etc you are referring to, or is it the actual project file we use to hold our scenery package?
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Jon, you talked about decompiling libraries to get the MDL. Yes, that is sort of what we need to do, but not by using a stand-alone decompiler. We can just read the MDL files directly out of the library BGL (MDL Tweaker can already do that for most library BGL files). If we make changes to the MDL afterwards, we need to save it to disk as MDL of course.

Agreed I am assuming that any decompilation we do is as you describe it.

I am not sure what you refer to as XML data. Is it for example the Airport XML element with runways, taxiways, etc you are referring to, or is it the actual project file we use to hold our scenery package?

From my perspective this is the data about airport objects such as runways, buildings, etc. Not the project file.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
I do not fully agree here. I beleive we should store WHAT we have changed so we can reapply the data again if the source model is changed/updated. Of course we might later choose to speed things up by caching it, but that would be a separate cache, not a part of the data model.

Humm, that is an interesting approach as well. So you would like to store that seasional textures have been added, so that it can be re-applied later on. For custom objects that are read in from MDL file that sounds logical.

But I don't think we can use that approach if the information is read from the library BGL directly, in that case we need to save the MDL and add it to a new library. As we can not go and change library BGL files.

I am not sure what you refer to as XML data. Is it for example the Airport XML element with runways, taxiways, etc you are referring to, or is it the actual project file we use to hold our scenery package?

The information read from the BGL files made with BGLComp/XML. But then talking about the actual placement of the data, not really about the MDL files that might be in there.
 
Messages
268
Country
netherlands
Humm, that is an interesting approach as well. So you would like to store that seasional textures have been added, so that it can be re-applied later on. For custom objects that are read in from MDL file that sounds logical.
Yes, this is how my current tool work, and I would not give up on that. When you have spend time ajusting AutoLoD parameters, added seasonal textures, removed some shadows etc, then you do not want go go though all of that again simply because you realized you need to move a vertex a bit.
But I don't think we can use that approach if the information is read from the library BGL directly, in that case we need to save the MDL and add it to a new library. As we can not go and change library BGL files.
I do not think this is a problem - I do not even think we need to write many lines of code to do it. In the domain model we will simply have a 3D object. This 3D object can be loaded for example from a standalong MDL file, an MDL file in a library, or it can originate from transforming an existing 3D object. With regards to placement they are all identical: They render the same way on the map, they can be moved the same way, and they can be used as a base for further transforms.

When generating the scenery the writer will for each 3D object encountered check if it is from a library. If it is, it will not write it again, but take the appropriate action to ensure the library is included (if needed). If the 3D model is not from a library (and this includes 3D objects that are a result of a transformation of a library object) it will take the appropriate action to include the object at that stage (either add it to a library or write it directly in the file).

Obviously when placing etc, we just use the fact that they are all 3D objects, so no special code is needed at all.
The information read from the BGL files made with BGLComp/XML. But then talking about the actual placement of the data, not really about the MDL files that might be in there.
OK, you might want to take a look at the code I send you (if anyone else wants to see the code, please mail me directly on "lars@xs4all.nl" from an email acconut able to receive a bit over 1MB). You will see each 3D model can have a number of ModelPlacements. We would need something better than this, for example a "Placement" base class, with subclasses like "ModelPlacement", "AirportPlacement", "RunwayPlacement", EffectPlacement", etc.

Two hours to guests arrives, place still a mess..... 1 hour 50 minutes until I need to panic :)
 

scruffyduck

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
34,853
Country
unitedkingdom
Am I right in thinking that you guys are talking about placement of 3D objects in a 3D view of the Scenery and not the plan view of a 3D object in a 2D Map View?
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
I am not :), we only want placement on the 2D map for now, don't we?
 
Top