-
-
Notifications
You must be signed in to change notification settings - Fork 6
i3dMappings
Vehicles and placeables in Farming Simulator are not described by the .i3d alone. A separate config XML (vehicle.xml / placeable.xml) defines the gameplay - which node is a wheel, a light, an attacher, and so on. To point at a node inside the i3d, that XML uses an <i3dMappings> block that gives each node a readable id (for example wheelFrontLeft) and maps it to the node's position in the scene tree. The i3d itself holds no reference back to the config XML, which is why loading it is a separate, explicit step.
The importer can read those mappings back in, assign them to the matching imported objects, and let you view and edit a node's id - which the official Giants exporter currently cannot do reliably on Blender 5.1+ (see why below).
This page only matters for vehicle and placeable mods whose config XML contains an
<i3dMappings>block. For plain assets or maps you can ignore it.
There is a preference setting if you want to import the XML automatically. If this is ON, and there is an XML file with the same name as the imported i3d in the folder, it will import it automatically. The section below is only relevant if you want to import the XML manually.
- Import your
.i3d. - Select any object that came from that import.
- In the i3d Importer sidebar tab, open the Store Config & i3dMappings panel and, in the i3dMappings box, click Load Config XML.
- Pick the matching
vehicle.xml/placeable.xml.
The importer reads the <i3dMappings> block and assigns each id to the object at the matching position in your import. The button stays greyed out until an imported object is active, because the mappings are matched within the import of the selected object - so the correct XML lands on the correct model even when you have several imports in one scene.
As a convenience it also adds the chosen file to the Giants exporter's XML Config Files list, so you do not have to pick it a second time for Update XML. If the file is already in that list, it is not added twice.
If some mappings cannot be assigned, the importer tells you in a warning (with the ids) instead of dropping them silently. In practice this only happens for mappings that point into a referenced sub-i3d that is not imported - see Limitations.
Select an object that has a mapping. The i3dMappings box shows a Mapping ID field with its current id, which you can edit directly. The value is written so the Giants exporter picks it up on the next re-export (Update XML).
Do not toggle the exporter's own i3dMapping checkbox after setting an id. The Giants exporter resets the id to the node name when the checkbox is switched on. Set your id in the importer field and leave the exporter checkbox alone.
On Blender 5.1+ the Giants exporter saves a node's mapping id in one place (an RNA property shown in its UI) but reads it from another (a custom property) when it writes the XML. On Blender 4.x those were effectively the same storage; since 5.1 they are separate, so a value typed into the exporter's field never reaches the export and the <i3dMappings> block stays empty. This has been reported to GIANTS. The importer writes both storages, so editing the id here works either way.
- Mappings into a referenced sub-i3d are not assigned. A mapping whose target lives inside a referenced sub-i3d (a ReferenceNode we do not load automatically) has no object to attach to. The importer lists these in a warning so nothing is lost silently. Mappings that target regular objects - including skinned joints and merge-group members - are assigned normally.
- Use the matching XML. Ids are matched by each node's position in the i3d, so load the config XML that belongs to the i3d you imported. A mismatched file leaves most mappings unassigned (and you will see the warning).