Use cases for 3D model placements

#21
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.
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
#22
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

Administrator
Staff member
FSDevConf team
Resource contributor
#23
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.
 
#24
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.
 
#25
draft description reply

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

Administrator
Staff member
FSDevConf team
Resource contributor
#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 :)
 
#27
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.
 
Top