View Full Version : Use cases for 3D model placements
lmoelleb
29 Sep 2006, 16:10
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?
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.
lmoelleb
30 Sep 2006, 04:23
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?
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
30 Sep 2006, 06:33
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.
lmoelleb
30 Sep 2006, 10:04
...
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.
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.
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
30 Sep 2006, 11:53
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
lmoelleb
30 Sep 2006, 12:37
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.
scruffyduck
30 Sep 2006, 13:08
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 :)
lmoelleb
30 Sep 2006, 13:40
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
30 Sep 2006, 16:10
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.
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.
lmoelleb
01 Oct 2006, 04:57
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
01 Oct 2006, 05:15
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.
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.
lmoelleb
01 Oct 2006, 06:05
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
01 Oct 2006, 06:38
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?
I am not :), we only want placement on the 2D map for now, don't we?
lmoelleb
01 Oct 2006, 06:55
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?
No, we are talking about using a 2D map to place 3D objects in Flight Simulator, seing a 2D outline of the object as it is being placed.
We do however also want to change (transform) these 3D objects (seasonal texture, AutoLoD etc), hence we need them loaded in full 3D to change them and write the changed object to the scenery as it is being generated.
OK, you might want to take a look at the code I send you. 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.
OK, as C# is still a bit new to me, I need to study that code a bit more to fully understand it.
But I don't think that our read in MDL file should have a placement. When doing the object placement we are only seeing the 3D object as a point feature, that has a lat/lon/alt/heading, etc. And of course a GUID that links it to a certain 3D object. But none of these actions require us to know more about the object we are placing.
Only for certain objects you want to do more (like the LOD, seasonal textures, etc). For these we would have to read in the MDL and do something with it. But when a user just places a default FS object, this is not needed.
So I would not put the placement together with the MDL object, but more the reverse.
scruffyduck
01 Oct 2006, 07:54
We do however also want to change (transform) these 3D objects (seasonal texture, AutoLoD etc), hence we need them loaded in full 3D to change them and write the changed object to the scenery as it is being generated.
OK - sorry i am being so slow here but I am not sure why we need to do that for a top down view unless we are planning to show the object as seen from right overhead. My though was that it would be a shape either in line or filled with a color. I can see that if we wanted to show a top view of the object we would need to transform the 3D object to get that effect.
lmoelleb
01 Oct 2006, 08:10
So I would not put the placement together with the MDL object, but more the reverse.
I am aware of what you mean, and you might very well be right. I am however not yet convinced as there are pros and cons of both methods. I'll post in more detail when time allows. It might be today (might even be in half an hour, I do not know). Probably in another thread to get a seperate discussion on this.
OK - sorry i am being so slow here but I am not sure why we need to do that for a top down view unless we are planning to show the object as seen from right overhead. My though was that it would be a shape either in line or filled with a color. I can see that if we wanted to show a top view of the object we would need to transform the 3D object to get that effect.
A transformation might change the appearance of an object (I do for example have a repeater transformation used to make fences etc that will do this). But besides this you are completely right, we do not need to do this to place objects on the map. But please bear in mind, that placing objects on the map is not the use case here. It is the mean to achieve the goal: Placing 3D objects in FS. Creating a FS scenery requires the transformation.
what if you keep things simple in regard to the file format saved as to being xml? or would it have to a container of some sort allowing other data to be saved at the same time?
regards
Gary- vads
Virtual Aerospace Design SA
scruffyduck
10 Jan 2007, 10:26
At the moment I working on the basis that xml is the preferred way to go. Right now the Scenery Design Engine generates straight xml for use with BGLComp. I am thinking about either
Using comments to persist information needed by the designer which are not stored in the required xml
Adding some additional element tags for this purpose which get stripped out by the compiler before the xml gets sent to the compiler
I cannot decide which is best as they both have advantages and dis-advantages :)
lmoelleb
11 Jan 2007, 02:26
Gary,
Please be careful with what you refer to when writing "XML". XML as a format can save anything, hence your questions reads a bit like "Should it be a bucket, or something that can hold water?". :)
I see Jon read your question as "should it be the FSX XML format, or something else", which is how I would choose to interpret it as well, but it does become a bit unclear when using the general term "XML" to cover a specific XML format.
John,
Do not use comments for anything but comments. No tool can operate efficiently on comments (think XSLT etc).
As far as I have seen Jon, your work is a good object wrapper of the FSX structure. I do not see it used as the SDSX project structure for a number of reasons:
1) It would make your library less generic - other tools will also need to read and generate FS scenery, without being hooked up to an SDSX specific structure.
2) It would tie the scenery file structure to the logical structure. For large parts of it, SDSX needs to handle what goes in which scenery files, I certainly can't be bothered as a user... and I can even less be bothered sitting moving things around manually because preferences change later on.
3) The saving of a project (as opposed to generating a scenery) is up to a data mapper. A datamapper saving to a XML format is an obvious choice, but we might also provide an SQL datamapper later on, specifically on the server side.
4) As you mention, no logical place to handle the extra structure we need (folders used to organize large sceneries, readme information, position information for KML generation, internal work model or ready for release etc). Some of your classes are provably so generic we can use streight mappers in the SDSX domain model, but still we should use a wrapper class allowing later diviation.
vBulletin® v3.8.3, Copyright ©2000-2013, Jelsoft Enterprises Ltd.