Vector Network (.net) File Format Specification

X-Plane uses a vector definition file (.net as in network) to visually render road networks. DSF files specify vectors by type and subtype. The type indicates what .net file to use for the roads; the subtype indicates a style of road within the .net definition file. The default scenery defines 62 vector types; you may replace the default road artwork by using the same subtypes, or use your own subtype numbers for your own custom scenery. Vector Network definition files are standard X-Plane text files with 3-line headers. Each command then takes one line, with parameters separated by spaces. A vector contains one or more subtypes and uses one or more textures. Each road subtype must use only one texture.

        A
        800
        ROADS

TEXTURE

This command specifies a texture to be used by the vectors. The bitmap should have the file extension on it. The numeric parameter indicates the amount of Z-buffer offseting to use when using this texture. A positive number helps X-Plane draw the vector on top of the terrain mesh without Z-buffer thrash. Zero indicates no offsetting; this setting is good for bridges. The texture command establishes an index number for that texture within the .net file. The first texture command will be texture 0, the second texture command 1, etc. Note: if you need to sometimes use a texture with z-buffer offsetting and sometimes without, simply include it twice with different Z-buffer offsets. This will establish two indices for the texture, but X-Plane will only load the texture into VRAM once.

TEXTURE <z offset> <filename>

TEXTURE_LIT

This command establishes a night-lit texture to go with the main texture for a road network. If this command is used at all, there must be one for each texture command, and they must follow in the same order. X-Plane will not automatically find _LIT bitmaps without this command.

TEXTURE_LIT <filename&ht;

SCALE

Normally texture coordinates are specified fractionally, e.g. 0.2 for a pixel 2/10ths of the way through the texture. The scale command indicates that all texture coordinates are multiplied by a fixed constant. If this command is not included, it is as if the scale is 1.0. The scale is applied to all commands that follow the scale command. Note: This allows you to work in terms of the pixel positions of the texture instead of fractional coordinates. But X-Plane does not take the real texture size into account. You can use a scale of 1024 even if the texture is not 1024×1024 pixels.

SCALE <scale>

ROAD_TYPE

This indicates information about a new road type. Segment, wire, and object commands apply to the previously declared road type. The road type takes seven parameters:

The numeric road subtype. This is an integer defining the road subtype. X-Plane matches this road type against the “subtype” field in the DSF file. (See the DSF spec for more info.) Road subtypes do not have to be consecutive or in ascending order in a road network file, but each road subtype should only be used once.
Segment width (meters). This defines how wide the vector is. All width-related info is relative to this defined width.
Repetition length (meters). This defines how many meters one length of the texture are applied to.
Texture index (zero based). This defines which texture to use, based on the texture commands previously defined.
Red fraction – a ratio from 0 to 1, indicating the percentage of red to use to draw this vector in the map view.
Green fraction – a ratio from 0 to 1, indicating the percentage of green to use to draw this vector in the map view.
Blue fraction – a ratio from 0 to 1, indicating the percentage of blue to use to draw this vector in the map view.

ROAD_TYPE <subtype>  <width> <length> <texture>  <red> <green> <blue>

SEGMENT

The segment command defines one quadrilateral section of a road. Segments are extruded along the length of a road vector. The simplest possible road would have one segment. Segments are defined in terms of their lateral extent, meaning how far across the road they go, and their vertical extent, meaning how far above and below the road they go. Lateral extent is defined as a ratio, where 0.0 is the left side and 1.0 is the right side. (Segments cannot extend outside the width of the segment – if you need ot make a wider segment, define the whole vector type to be wider using the ROAD_TYPE command.) Vertical extent is defined in terms of meters, where 0 is the height of the road, positive is above the road and negative is below. Texturing of segments is performed as follows: the texture’s vertical axis is aligned along the length of the vector and repeats continuously, with length meters of vector (as defined in the ROAD_TYPE command) corresponding to one repetition of the texture. The texture’s horizontal axis crosses the road, or goes up and down vertical “walls”. Horizontal texture positions are normally stored as “S” coordinates, meaning fraction of the distance across the texture, but the SCALE command (see above) can be used to change these units. Segments have associated level-of-detail parameters. You can define at what range/how far out segments are visible, so that small details (like guard rails) are only drawn when close to the vector segment. The segment command takes 8 parameters:

Near LOD (meters). The closest distance at which the segment is visible.
Far LOD (meters). The farthest distance at which the segment is visible.
Beginning lateral fraction. The lateral position of the start of this segment, as a ratio where 0 = the left side of the vector and 1 = the rgiht.
Beginning vertical offset. The height above the road that this segment starts at, in meters, positive means up.
Beginning texture coordinate. The horizontal position on the road texture to use to start drawing this segment.
Ending lateral fraction. The lateral position of the end of this segment, as a ratio where 0 = the left side of the vector and 1 = the rgiht.
Ending vertical offset. The height above the road that this segment ends at, in meters, positive means up.
Ending texture coordinate. The horizontal position on the road texture to use to end drawing this segment.

SEGMENT <near lod> <far lod>  <start lat> <start vert> <start tex>  <end lat> <end vert> <end tex>

WIRE

The wire command instructs X-Plane to string a powerline wire along the vector segment. Powerline wires may be added to any vector type; the “powerline” vector type is simply a vector with powerlines, no roads, and objects forming the towers. The texturing/coloring of the wire is handled by X-Plane. The wire command takes 5 parameters:

Near LOD distance (meters). This is the nearest the wire will be seen.
Far LOD distance (meters). This is the farthest the wire will be seen.
Lateral offset (meters). This is the position of the wire, relative to the width of the vector. 0 = left, 1 = right.
Vertical offset (meters). This is how far above (or below) the vector the wires will be at their endpoints.
Droop Ratio (meters). This is the percentage of the vertical height that the wire droops at its lowest; 0.0 means no droop, 1.0 means the wire is dropping all the way down to the vector itself (e.g. touching the ground).

WIRE <near lod> <far lod>  <lateral offset> <vertical offset> <droop ratio>

OBJECT

The object command instructs X-Plane to place an object (OBJ) at a location along the vector. Objects are positioned laterally along the width of the vector, but unlike segments, can be placed to the left of the vector (using negative ratios) or to the right of the vector (using ratios greater than 1). Objects can be placed at a fixed interval of meters, or they can be placed at every “shape point” along the vector, e.g. each time the vector changes direction. (See the DSF spec for more on shape points.) Objects can be rotated; normally they are placed at a heading of 0 for a north-heading vector. When a vector turns a corner, if an object is placed at that corner its heading is the average of the two vectors touching that corner. Objects may be placed at the height of the vector, or they may be repositioned on the ground. In this case if the vector is above the ground (e.g. a bridge or overpass) the object will still be placed on the ground. The object command takes six parameters:

Object name (with .obj) extension – the filename of the object. The object should be in the same directory as the .net file that references it, or a subpath may be specified in this name.
Lateral offset – a ratio positioning the object, where 0 = left side of teh vector and 1 = right.
Rotation – a clockwise rotation to turn the object additional to the heading of the vector.
On ground – 1 if the object should be placed on the ground, 0 if the object should be placed at the same height as the vector.
Object frequency – how often the object should be placed, in meters, or 0 if the object should be placed once per shape point.
Object offset (meters) – if the object is placed by distance, it will start at the beginning of the vector; with this offset you can start the object n meters along the vector.

OBJECT <name> <lateral offset ratio> <rotation> <force on ground> <placement frequency> <placement offset>

REQUIRE_EVEN

[X-Plane 820] Normally textures are applied to a road by scaling the vertical axis of the texture along the road (longitudinal axis) based on the length of the road, e.g. a “30 meter” road gets one full repetition of the texture every 30 meters. This implies that a 70 meter road gets 2.3 copies of the texure and the raod ends midway through the texture. When the REQUIRE_EVEN attribute is applied to a road type, the length of the road is scaled as it is applied so that the texture will be used an even number of times. In the case above, the road would be rescaled from 30 meters to 35 meters, and would be applied exactly twice. This rescaling is done differently for every segment of the road so that the texture is never chopped. This command affects segments and objects that are placed by distance; distance-placed objects have their distances scaled by the same factor as segments so that the relative relationship of objects and texture is maintained. Objects that are placed as a fraction of the segment and wires are not affected by this command. The command must be after the ROAD_TYPE command and affects the previously stated road-type only; use this command once for every road type that will be scaled.

REQUIRE_EVEN

SEGMENT_HARD

[X-Plane 850] The segment hard command is just like the regular segment command, except that it declares that the road segment will be “hard” (similar to hard polys in an object), allowing the plane to land on them. The hard surface command takes all regular surface commands, plus a surface name, which are the same names as in the OBJ8 format. See the OBJ8 spec for a list of surfaces. The hard segment command takes 9 parameters:

Near LOD (meters). The closest distance at which the segment is visible.
Far LOD (meters). The farthest distance at which the segment is visible.
Beginning lateral fraction. The lateral position of the start of this segment, as a ratio where 0 = the left side of the vector and 1 = the rgiht.
Beginning vertical offset. The height above the road that this segment starts at, in meters, positive means up.
Beginning texture coordinate. The horizontal position on the road texture to use to start drawing this segment.
Ending lateral fraction. The lateral position of the end of this segment, as a ratio where 0 = the left side of the vector and 1 = the rgiht.
Ending vertical offset. The height above the road that this segment ends at, in meters, positive means up.
Ending texture coordinate. The horizontal position on the road texture to use to end drawing this segment.
Surface code. The name of the hard surface type.

SEGMENT_HARD <index> <lod> <lod> <dx1> <dy1> <s1 <dx2> <dy2> <s2> <surf>

CAR

[X-Plane 850] The car command defines a lane of cars. The car command defines how fast and what kind of cars can traverse a lane and also controls the generation of cars.

Reverse – if 1, the car goes in the opposite direction of the road’s natural direction, otherwise it goes with it. Please note that the lateral offset is “from the left” relative to the car direction! So for example in the US (where cars are on the right side), the lateral offset should be greater than 0.5 even if the reverse flag is set to 1.
Lateral offset – a ratio from 0 to 1 indicating how far from the left to right of the road the center of the lane is.
Velocity – the speed of the traffic in that lane in meters per second. Must be greater than zero.
Spawn ratio – a fraction indicating how many cars per kilometer are generated. But this is scaled by X-plane based on user settings, so you should probably copy the existing ratios from existing road types.
Traffic type – an index into the CAR_MODEL commands (see below), 0 is the first command, indicating the type of car to use.

CAR <reverse> <lateral offset> <velocity> <spawn ratio> <traffic type>

CAR_MODEL

[X-Plane 850] The CAR_MODEL command defines an object to be used as a car model. These commands are referenced by car commands – the first CAR_MODEL command defines traffic type “0”, the second one traffic type “1”, etc. The input is an object name. The object name may be a library path – in this case all objects matching the library path will be used, creating a variety of cars. In this way you can create variety in traffic. Each library path should reference multiple objects all of a similar type since all of those matching objects may be sharing a traffic lane.

CAR_MODEL <object path>

TRAIN

[X-Plane 900] The TRAIN command defines a train (a string of objects) to be used as a car model. A train command takes up one index just like the CAR_MODEL command does. (That is, if you use CAR_MODEL, then TRAIN, then car type 0 is the object specified by the CAR_MODEL command and car type 1 is the train specified by the TRAIN command. The train sub-commands that follow help define the train.

TRAIN

TRAIN_VARIANT

[X-Plane 900] A car command points to a single object, but the library system randomly substitutes any of the matching objects for that car type. So with a carefully built library, a lot of traffic variation is possible. However with trains, each object substitution (representing one railroad car) must be the same length as all others that go in a certain “slot” or the train will not connect together properly. The train-variant command is provided to allow for more train variety within this constraint. A train variant is a sequence of object-paths and spacings that defines how a train looks – a train may have one or more variants, and each variant can have a different number of cars or a different choice of train-car object paths.

TRAIN_VARIANT

TRAIN_CAR

[X-Plane 900] The train-car command adds one more train-car to the current train-variant. For each car, two lengths are specified – the first is the length from the center of the OBJ (0,0,0) to the front of the car (along the -Z axis) and the second is from the object center to the back of the car (along the +Z) axis. The object path is a virtual path in the library. Note that every object that matches this path must fit into the “slot” specified by the two lengths, or the train car will not align properly. (The library system is used, so given the length of a train car, multiple variants can be selected.)

TRAIN_CAR <length 1> <length 2> <object path>

Modern and Virtual Road Segment Directives (10.00 and Newer)

These directives provide more control over road segments including draping on the ground and variants based on height above the ground.

VARIANTS

TBD

VARIANTS <count>

ROAD_CENTER

This declares the distance from the left edge of the road’s surface area to the centerline. Normally road types are declared only by width and assumed to be symmetrically extruded off this center line; this directive can be used to, for example, have a road with “extra” area on one side, e.g. for a one way road with certain decorations.

ROAD_CENTER <distance>

ROAD_DRAPED

This directive defines a new virtual road type. The virtual road contains a list of specific road types (via the ROAD_TYPE directive) to be used under varying conditions.

Draping modes define whether the road is to be treated as graded, traped, or both.

0: the road is draped on the ground and will follow the ground’s contours.


1: the road can be draped or graded


2: the road must be graded (drawn solidly in 3-d in its own 3-d space, crashing into the mesh

type is the virtual type ID for this specific road – this is what is referenced in the DSF.

Pitch and roll are pitch and roll limits; these are ignored by the sim.

ROAD_DRAPED <mode> <type> <pitch> <roll>

ROAD_DRAPE_CHOICE

This directive adds a real road type as a possible type for a virtual type, given an AGL constraint – that is, how far above the ground the road actually goes. The idea is to allow different variants for roads on the ground, roads high enough to be on embankments, and full bridges.

ROAD_DRAPE_CHOICE <max AGL> <real type>

BIDIRECTIONAL

The bidirectional directive declares one or more road types (virtual or real) to be fully reversible – X-Plane can reverse this road’s direction to optimize the network.

BIDIRECTIONAL <type> [...<type>]

ONE_SIDED

This directive changes road geometry to not be two-sided. In the original .net spec, all geometry was visibly two-sided (for vertex efficiency), resulting in infinitely thin polygons and incorrect lighting.

A modern road art file can declare one-sided geometry and fully extrude “solid” walls on roads, e.g. for barriers. This directive will then tell X-Plane that the lighting can be calculated for full 3-d meshes.

ONE_SIDED

SEGMENT_DRAPED

This directive creates an extruded rectilinear segment on a road that will be draped on the ground.

material is the zeor-based index of the shader to use for this segment.
lod near/far are the draw distances in meters within which to draw this segment.
t_scale is a multiplier to scale the road along its longitudinal axis compared to the normal expected resolution for the material.
dx1 and dx2 define the horizontal offset (+x = right) in meters from the centerline of the road.
s1 and s2 define the UV map horizontal texture coordinates (normalized) of the texture.
surface, if present, is a keyword for a physics surface type, e.g. asphalt, concrete.

SEGMENT_DRAPED <material> <lod_near> <lod_far> <t_scale> <dx1> <s1> <dx2> <s2> [<surface]>

SEGMENT_GRADED

This directive creates an extruded rectilinear segment that follows the road’s centerline in 3-d space.

material is the zeor-based index of the shader to use for this segment.
lod near/far are the draw distances in meters within which to draw this segment.
t_scale is a multiplier to scale the road along its longitudinal axis compared to the normal expected resolution for the material.
dx1 and dx2 define the horizontal offset (+x = right) in meters from the centerline of the road.
dy1 and dy2 define the vertical offset of the segment in meters (+y = up) from the road’s centerline in 3-d space.
s1 and s2 define the UV map horizontal texture coordinates (normalized) of the texture.
surface, if present, is a keyword for a physics surface type, e.g. asphalt, concrete.

SEGMENT_DRAPED <material> <lod_near> <lod_faR> <t_scale> <dx1> <dy1> <s1> <dx2> <dy2> <s2> [<surf>]

SEGMENT_NORMALS

When present following a SEGMENT_GRADED directive, this defines custom normal vectors for a segment. The X and Y components of the normals are provided for both end-points, with Y = up, +X = right. The Z component is assumed to be zero since the Z axis aligns with the length of the segment.

SEGMENT_NORMALS <nx1> <ny1> <nx2> <ny2>

LOCKED_POWERLINES

[X-Plane 10.30 and newer]: if present, this disables X-Plane’s attempts to reposition powerlines to avoid crashing into other roads; powerlines will appear exactly where there are junctions in the raw DSF data.

Modern Directives for 3-d Clutter

These directives (X-Plane 10.00 and newer) add objects and vehicles to roads.

CAR_DRAPED/CAR_GRADED

This directive spawns traffic on a road segment.

reverse: 0 if the car travels in the direction of the network link, 1 if opposite
dx: the offset of the car from the centerline
speed: of the car in m/s
spawn ratio: defines frequency of car per meter of road
car type: a zero-based index into the traffic definitions of the file

CAR_DRAPED <reverse> <dx> <speed> <spawn ratio> <car_type>
CAR_GRADED <reverse> <dx> <speed> <spawn ratio> <car_type>

OBJECT_DRAPED/OBJECT_GRADED

These directives place 3-d models along a road segment. Draped objects sit directly on the terrain while graded ones are aligned to the road itself. Both can be used regardless of the road mode, e.g. for a graded bridge, a draped object can be used to anchor “footings” for a bridge to the ground.

Most parameters are given in pairs, and a random value between them is picked.

Mode: an enumeration for how the objects are placed.

`SEG` - an object is placed once per segment, based on the distance parameter.


`VERT` - an object is placed at every vertex.


`DIST` - an object is placed at fixed distances along the road, based on the distance parameter.


`BEGIN` - an object is placed at the beginning of the road.


`END` - an object is placed at the end of the road.


`CREASE` - an object is placed at each shaping point along the road that is a ‘crease’ and not a gentle curve. The object heading is the average of the two headings.

dx1/2: defines the range of offsets lateral to the road to place the object from the centerline, +x=right.

angle1/2: defines the rotation of the objects clockwise, zero faces the -Z of the object along the direction of the road segment.

distance1/2: defines the distance between each object or along each segment.

offset1/2: these are defined in pairs from the start and end, e.g. 10/20 would mean the object must be offset 10m or more from the start and 20m or more from the end; this is used to keep objects from appearing at the ends of roads whhere there migt be junctions.

lo hi: if present, defines the x-plane level of object clutter where these start to appear (lo) and fully appear (hi). At ‘hi’ user setting, the object is guaranteed to be present, and below ‘lo’ it will be removed.

OBJECT_DRAPED <mode> <model> <dx1> <dx2> <angle1> <angle2> <distance1> <distance2> <offset1> <offset2> [<lo> <hi>]
OBJECT_GRADED <mode> <model> <dx1> <dx2> <angle1> <angle2> <distance1> <distance2> <offset1> <offset2> [<lo> <hi>]

OBJECT_FREQ

This directive defines randomization for a previous OBJECT_DRAPED/GRADED directives.

The four periods (in meters) and amplitudes (from 0 to 1) shape four random noise fields to provide multi-level fractal noise. If the noise field (as shaped) results in a frequency (normalized) between lo and hi, the object is selected.

Because the noise field base is universal to X-Plane, different lo/hi ranges can be used to select object alternatives by using the same period/amplitude parameters.

OBJECT_FREQ <freq lo> <freq hi> <prd1> <amp1> <prd2> <amp2> <prd3> <amp3> <prd4> <amp4>

OBJECT_ALT

This directive defines alternate model sets from the library for a previous OBJECT_DRAPED/GRADED directive. Each road network chain will pick exactly one alternate set and randomize within it (via the library) for that chain.

OBJECT_ALT <model library path>

Directive for Road Junctions

[X-Plane 10.0 and later]: these directives define road junction artwork.

Road net files for X-Plane 10.0 and later require custom artwork to create the junctions between roads. There are two types of junctions:

Regular junctions fit an exact topology of incoming roads and are customized for this use case.
Composite junctions are small pieces that are stitched together to form a multi-polygon covering N arbitrary roads.

X-Plane will prefer to use regular junctions, and will fall back to composite junctions for unusual cases.

Each junction consists of:

Some meta-data describing the junction’s use.
A bone table, which describes the positioning of a coordinate system (a ‘bone’ in an animation system) relative to the road system. Since each junction can have multiple bones, the vertices can be stretched to fit exact situations.
A vertex table, providing the vertices of UV-mapped meshes.
Material and primitive directives, defining one or more triangles or quads to be rendered. A materials are provided by indices and multiple materials can be used in a single junction.

JUNCTION_DRAPED/JUNCTION_GRADED/JUNCTION_EMBANKED/JUNCTION_BRIDGE

These directives define a new complete junction. The directives are named by how they manage vertical extents:

Draped junctions sit flush on the terrain.
Graded junctions are on the ground but sit in their own coordinate system, with 3-d intersecting the ground.
Embanked junctions are elevated but do not form a bridge
Bridge junctions are clearly above the ground.

The valence is the number of roads that will enter this junction.

JUNCTION_DRAPED <valence>
JUNCTION_GRADED <valence>
JUNCTION_EMBANKED <valence>
JUNCTION_BRIDGE <valence>

MATCH

A match directive provides the topology of road types that a junction can match. Each match directive specifies the roads that can match each slot in the valence; there should be one match directive per valence degree.

Each match directive consists of a list of one or more road types; the road types are annotated by an enumeration specifying the direction followed by the road virtual type. Legal enumerations:

in – the road’s direction must go into this junction.
out – the road’s direction must come out of this junction.
io – the road may go into or out of the junction.

MATCH <direction> <road id> [...<direction> <road id>]

JUNCTION_COMPOSITE_CORNER

This directive defines a corner element for a composite junction; this junction will define only a corner between two incoming roads. The junction will need two match directives to define the two roads coming into the junction. The draping mode is one of

DRAPED – the junction sits on the mesh
GRADED – the junction is “on the ground” but in 3-d colliding with the mesh.
EMBANKED – the junction is in the air but with no passage under it.
BRIDGE– the junction is in the air and there is space under it

JUNCTION_COMPOSITE_CORNER <draping mode>

JUNCTION_COMPOSITE_APPROACH

This directive defines the part of a composite junction just before a single road entering the junction, not the shared space; it needs a single match directive to specify the type of road that it can “cap off”.

JUNCTION_COMPOSITE_APPROACH <draping mode>

JUNCTION_COMPOSITE_CENTER

This directive defines the center area of a composite junction – it forms an N-gon based on its valence. Unlike corners and approaches, composite centers are not matched to any road type – requiring an exact type of incoming roads would defeat the flexibility of the system. (If you know the exact type of roads coming in, you can use a non-composite junction.

JUNCTION_COMPOSITE_CENTER <valence> <draping mode>

JUNCTION_COMPOSITE_STUB

While composite junctions provide a powerful way to build arbitrary junctions for arbitrarily weird road topology, the animation scheme does not cope well with very large angles between roads.

A phantom road type is a virtual road type that will never exist, but that is added to the junction to create a smaller angle between incoming roads. For example, a T-style junction with 180 degrees between the two vectors of the “uninterrupted” road could have a phantom inserted opposite the dead-ned road to make a four-way junction with 90 degree angles.

The expectation is that there will be a composite approach junction matching the phantom road type and its art will “cap off” the composite junction. For example, if the main road has side walks, the phantom road type’s corners and approaches would continue the sidewalk along the composite junction’s “empty” side.

The direction/ID list works the same as. MATCH directive, and defines all road types that can have this phantom road type adjacent to them.

JUNCTION_COMPOSITE_STUB <phantom road type> <direction id> [...<direction> <id>]

BONE_INTERSECTION_EDGE_LEFT/BONE_INTERSECTION_EDGE_RIGHT

This adds a new bone to the current intersection defined by the intersection of the centerlines of the two roads, with an offset.

The bone “index” is the index number of the road going into the junction. (Numbering is established by matching declarations, e.g. index 0 will be a road matching the first MATCH in the file.)
off1 and off2 are positive offsets insetting the bone from the total edge of the roads (defined by their widths).
x,y,z is the rest position of the bone in junction coordinates (with 0,0,0 at the true intersection of the two roads)
dx,dy,dz is the rest direction of the bone, which will be rotated to match the indexed junction

BONE_INTERSECTION_EDGE_LEFT <road index> <offset 1> <offset 2> <x> <y> <z> <dx> <dy> <dz>
BONE_INTERSECTION_EDGE_RIGHT <road index> <offset 1> <offset 2> <x> <y> <z> <dx> <dy> <dz>

BONE_INTERSECTION_APPROACH_LEFT/BONE_INTERSECTION_APPROACH_RIGHT

This directive adds a bone to a junction for a composite approach or center junction. The bone is either on the right or left edge of the road facing into the junction.

The index is based on the matching order of the junction; for approach junctions this is usually 1, but for center junctions this can be used to index each part of the junction.
offset1 is an offset along the road from the nominal center of the plug.
offset2 is an offset parallel to the actual edge of the center, which can be skewed based on the types of roads entering the junction.
x, y, z is the rest position of the road, relative to the junction.
dx, dy, dz is the rest direction of the indexed road.

BONE_APPROACH_LEFT <index> <offset1> <offset2> <x> <y> <z> <dx> <dy> <dz>
BONE_APPROACH_RIGHT <index> <offset1> <offset2> <x> <y> <z> <dx> <dy> <dz>

BONE_CENTROID

This defines a bone at the centroid of the junction. This bone is typically not used because it has no rotation from its rest position. X, Y, Z is the position of rest position of the bone.

BONE_CENTROID <x> <y> <z>

BONE_BEZIER

This defines a bone along the bezier curve of a road, in the direction of the curved road.

The bone is defined by an indexed road into the junction and a number of meters out from the junction to follow the curve. Like previous bones, the position and direction vectors define the rest position of the bone for authoring.

BONE_BEZIER <index> <distance> <x> <y> <z> <dx> <dy> <dz>

BEZIER_OFFSET

This directive moves the origin for a junction in a fixed distance along a particular road, which will bias the amount of road available for junction matching.

BEZIER_OFFSET <index> <distance>

MAX_SHEAR

This directive overrides the maximum amount of “shearing” distortion a junction can be subject to and still be used. The default maximum is 45 degrees. For example, this directive can limit how far a “plus” junction can be distorted into an “X” junction.

MAX_SHEAR <angle>

CUTBACK

This defines how much to cut back roads going into a junction to make more space for junction art. If missing, roads are not cut back at all. If present, there must be one entry for each road in matching order. Cut backs can be numeric distances or none to bypass cutback for a particular road.

CUTBACK <distance> [...<distance>]

JUNCTION_MINIMA

If present, JUNCTION_MINIMA defines the amount of road distance necessary to fit a junction. This presents junctions with large art footprints from being crammed into a very small space. There must be one distance for each road in the junction.

JUNCTION_MINIMA <distance> [...<distance>]

JUNCTION_LEVEL_SET

This directive defines which road types interact with a junction and which pass over each other. Each directive defines a bit-field per junction; the default level set for any road is 1 – if left alone this will make all roads intersect with each other.

This can be used to ensure that powerlines do not need junctions with roads, or to allow some rail artwork to collide with roads.

JUNCTION_LEVEL_SET <virtual road type> <bitfield>

Directives for Junction Meshes and Clutter

VERTEX

This adds a vertex to the vertex table of a junction. The vertex is defined in the spatial coordinates of the rest position of the junction, and will be transformed by its bones. Each vertex can have up to four. bones; the weights of the bones must add up to 1.0. At least one bone must be specified. Texture coordinates are normalized

VERTEX <x> <y> <z> <normal_x> <normal_y> <normal_z> <s> <t> <bone 1> <weight 1> [<bone 2> <weight 2> [<bone 3> <weight 3> [<bone 4> <weight 4>]]]

JUNC_SHADER

This defines the material to be used by the following TRI/QUAD directives for a junction. A shader must be specified before TRI/QUAD directives. The physical surface can be one from an .obj file like asphalt, concrete, etc.

JUNC_SHADER <material index> <max draw distance> [<physical surface>]

TRI/QUAD

These directive add one triangle or quadrangle to the junction by referenced index number.

TRI <index 1> <index 2> <index 3>
QUAD <index 1> <index 2> <index 3> <index 4>

JUNC_OBJECT

This directive adds an object model to a junction.

x, y, and z define the position of the object’s origin relative to the junction rest position.
r defines the rest rotation of the object, where 0 matches the rest coordinates of the junction.
drape is a draping flag: 0 means position in the 3-d coordinates of the junction, 1 means drop the object to register with the terrain mesh (drape).
The bone/weight list provides four bones and weights to blend to move the object. Use 0 weights for unused bones; weights must add up to one.
model is the library path for the model to be used.
lo/hi if present define when to draw the object with X-Plane’s settings; the object will not be drawn when settings are below ‘lo’ and will be drawn when the settings are at ‘hi’ or above.

JUNC_OBJECT <x> <y> <z> <rotation> <draping flag> <bone 1> <weight 1> <bone 2> <weight 2> <bone 3> <weight 3> <bone 4> <weight 4> <model path> [<lo> <hi>]

Example Vector Definition File

This is an example network definition file. (For a more detailed road.net file, see the .net files in the “default scenery” folder.)

A
800
ROADS
TEXTURE 3 roads_legacy.png
TEXTURE 0 roadbridges_legacy.png
TEXTURE 3 trails_legacy.png
TEXTURE_LIT roads_LIT.png
TEXTURE_LIT roadbridges_LIT.png
TEXTURE_LIT trailsLIT.png

SCALE 1024

ROAD_TYPE 0   18 18 0        1.0 1.0 1.0
SEGMENT    0 30000   0 0 0.0 1 0 0.5

ROAD_TYPE 3    24  500 0      1.0 1.0 0.2
WIRE        0 30000   0.15 22.8 0.4
WIRE        0 30000   0.85 22.8 0.4
OBJECT      powerline_tower.obj 0.5 0.0 1 0.0 0.0

ROAD_TYPE 6    3 3 2        0.0 0.0 0.0
REQUIRE_EVEN
SEGMENT    0 30000  0 -3 0.5    0  0 0.625
SEGMENT    0 30000  0  0 0.625  1  0 0.875
SEGMENT    0 30000  1  0 0.875  1 -3 1.0