FenceModel subclass

From CSP

As Onsight told me, first will be XML file interface for placing fences and walls on landscape.

Example:

<Object class="FenceModel">
    <Path name="model">fence04</Path>
    <Float name = "x">6</Float>
    <Float name = "y">10</Float>
    <List name = "directions">
        <Float>0.0</Float>
        <Float>1.57</Float>
        <Float>3.14</Float>
        <Float>4.71</Float>
    </List>
    <List name = "lengths">
         <Int>400</Int>
         <Int>200</Int>
         <Int>400</Int>
         <Int>200</Int>
    </List>
</Object>

FenceModel is temporary name for (yet non-existing class) class used for fences. <Path name = "model"> tag is used to get model XML file path. I am not sure but from this file you should be able to get to its model.xml then to 3d model path. Otherwise I think it could be place just for path to 3d model but this forces to make extra tags for model orientation, etc.

Float "x" is the x position on map. Float "y" is the y position on map. List "directions" is list that determines how many straight parts fence will have. List "lengths" determines how long the straight parts will be.

If number of directions is highter then number of lengths, missing lengths should be set to 0. If number of lenghts is greater then number of directions, extra lengths should be ignored.

How it works?

Fence should be placed in straight parts. So (x,y) is position starting point. Then fence should go in direction that is first on "directions" list, this part should have lenght set as first in "lengths". Then second part ...

---

A few comments:

• (x, y) are local coordinates, since the FenceModel will be embedded in FeatureGroup (e.g., an airbase) that is positioned using absolute (lat/lng or UTM) coordinates.
• The model should be defined via an ObjectModel class, but we will probably need to do some post processing so that adjustments applied to individual fence segments can be merged into a single adjustment for the entire fence. This can be done later though, once everything else is working.
• The definition of a segmented line will be useful in other contexts as well, e.g. roads, rivers, taxiways. We should give some thought to generalizing this project, and also to making the line definitions available to AI logic in the simulation. For example, it would be important to know that tanks can cross a shallow river along a particular set of segments, but that bridges will be required along other segments. Similarly, aircraft need to know where the runway is and how to taxi on/off the runway to hangars and parking spaces.
• To make these definitions useful, the layout tool will need to be extended. Hand editing XML of this sort is far too hard for large layouts. Scripts may also be useful (e.g., if we can obtain road and river paths from GIS data). I'm sure vterrain.org has useful information (and code) on this topic.

--Onsight 12:21, 25 Sep 2005 (PDT)