Engineering Dynamics Company

HVE Toolkit™

Simulation & Workflow Tools for Blender

HVE Toolkit — User Guide

A hands-on guide to using the HVE Toolkit add-on for Blender: HVE simulation setup, H3D export, and result import.

This guide walks you through installing the add-on, finding its panels, and completing the most common tasks step by step.

Contents

1. What this add-on does
2. Install and find the panels
3. How the sidebar is organized
4. Choosing which tools appear
5. Task guides
   • Pre-Simulation Setup
     • Prepare objects for HVE export
     • Export H3D files
   • Post-Simulation Processing
     • Import post-simulation results
     • Choosing what gets processed
     • Place a run's time zero
     • Match a run to the scene's frame rate
     • Show imported data in a display box
6. HVE Configuration
   • Set HVE's output precision
7. Units and scale
8. Troubleshooting
9. License & support

What this add-on does

HVE Toolkit bridges Blender and HVE (Human Vehicle Environment) simulation workflows: set up and export scene objects (vehicles, environments, GATB surfaces) as HVE .h3d files, and import simulation results back into Blender (variable-output CSV/HVO, HVE FBX, RaceRender conversion).

The add-on gets its own sidebar tab in the 3D View (EDC Toolkits by default).

Install and find the panels

1. Install Blender 4.x or later.
2. Download HVEToolkit-<version>.zip from the latest release (or clone this repository and run python tools/build_release.py to build dist/HVEToolkit-<version>.zip).
3. In Blender: Edit → Preferences → Add-ons → Install…, then select the add-on .zip.
4. Tick HVE Toolkit in the add-ons list to enable it.
5. In the 3D View, press N to open the sidebar, then click the EDC Toolkits tab.

Tip — rename the tab. The add-on's preferences (Edit → Preferences → Add-ons, expand the add-on) let you choose the sidebar tab name: the default EDC Toolkits, HVE, Human Vehicle Environment, or a custom name.

If you don't see the tab, confirm the add-on is enabled and that you are in the 3D View (not, say, the Shader Editor).

How the sidebar is organized

Everything sits inside one HVE Toolkit dropdown in the tab (so other EDC add-ons can share the tab, each under its own heading), with these panels:

Most panels are collapsed by default — click a panel header to expand it. The task guides below follow this same order: Pre-Simulation Setup, Post-Simulation Processing, then HVE Configuration.

HVE Configuration is separate from the other two because it does not touch this scene at all — it edits HVE's own Language.rsc, which HVE reads when it starts. It is also not a post-simulation step, despite being where you notice you need it: the precision it sets governs what HVE *writes*, so it has to be changed before the export, not after.

Choosing which tools appear

If you only use part of the toolkit, you can hide the rest. Open Edit → Preferences → Add-ons, expand HVE Toolkit, and use the Features checkboxes:

All eight are on by default. Unchecking one removes its panel from the sidebar immediately — no restart needed. Turn off every tool in a group and the group heading disappears too, so hiding both Pre-Simulation tools leaves just the Post-Simulation panels. Documentation always stays visible.

Nothing is uninstalled: the tools are only hidden, and re-checking a box brings the panel back with its settings intact.

Click Save Preferences (or enable Auto-Save Preferences) so your choices persist the next time you open Blender.

Task guides

Each subsection below is a self-contained task, ordered to match the panels in the sidebar.

Pre-Simulation Setup

Prepare objects for HVE export

Open Pre-Simulation Setup → H3D Setup, then:

1. Add Materials — expand and click Add Materials to create the generic, standard, and HVE light material sets. Classifying an object as Vehicle (step 2) does this for you, so you only need this button for an environment or to restore a set you deleted.
2. Object Type — expand and classify the selected object as Environment, Vehicle, or GATB Surface. If you selected several objects of mixed types, use the one-click reclassify buttons shown in the warning. Choosing Vehicle — from the dropdown or the reclassify button — also adds the HVE material library if it isn't in the blend yet, since a vehicle needs the body/glass/trim palette and its lights need the lamp materials. Only missing materials are created, so materials you have already edited are left alone.
3. Vehicle Lighting (vehicles only) — tag light objects (headlights, brake, turn, fog, reverse, tail, etc.) so HVE knows their function.
4. Terrain Properties (environments only) — set:
   • Surface: type (Road / Friction Zone / Curb / Water / Other), overlay label, material name, friction multiplier. The Copy Type + Overlay to Selected button pushes surface type and overlay from the active object to the rest of the selection.
   • Water: depth and static-water flag.
   • Soil: Bekker exponent, frictional/cohesive modifiers, moisture, macrotexture.
   • Forces: constant, linear, quadratic, cubic, unloading, damping.
5. Optionally Save Preset / Load Preset, or pick one from Apply Preset, to reuse terrain settings (presets live in hve_presets/).

Export H3D files

1. Select the object(s) to export and confirm their HVE type in H3D Setup.
2. Open Pre-Simulation Setup → Export to HVE. The button adapts to the selected type:
   • Export Vehicle → .h3d
   • Export Environment → .h3d
   • Export GATB Surfaces → .csv
3. If a mixed selection is detected, classify everything as one type first (the panel offers buttons to do this).
4. In the file browser, set options (selection-only, hierarchy, normals, compression, axis conversion, global scale) and save.

Any material texture is copied into a VehTextures/ folder (for vehicles) or EnvTextures/ folder (for environments) next to the saved .h3d and referenced with a relative path. This allows you to move the .h3d and its texture folder together while keeping the links working.

Post-Simulation Processing

Import post-simulation results

Open Post-Simulation Processing and pick the matching importer:

• HVE FBX Importer — click Import FBX and choose the .fbx. On import, the HVE hierarchy is renamed into cleaner labels, the scene timeline is extended to cover the animation, and objects are organized into HVE collections by event, vehicle, wheels, and body. Then set Max Shape Key Samples (the cap on shape keys kept per mesh; 0 = no cap) and use the Process section to run the Reduce Keys → Merge Meshes → Smooth cleanup pipeline — see Choosing what gets processed for the three scopes.
• Variable Output Importer — import an HVE .hvo/.csv of time plus variable-output columns. Choose feet or meters, optionally override the scale factor, and optionally save separate vehicle CSV files.

Two-dimensional reconstructions import. A planar run carries no height, roll or pitch, and those three columns are filled with zero rather than the file being refused — zero is what they would have held had the program written them. What a file must carry is where the vehicle is on the ground and which way it points; without those there is no animation to build, and the importer says which columns are missing instead of failing partway through with a KeyError.

• RaceRender Converter — convert HVE variable output into RaceRender-ready .csv files.

Missing FBX textures are relinked from the HVE support files automatically, so a scene imported on a machine that does not share the original's paths still comes in textured. The folder searched is set in the add-on preferences and defaults to HVE's own install location.

Choosing what gets processed

All three buttons run the same pipeline — Reduce Keys → Merge Meshes → Smooth — and differ only in *which vehicles* they touch. They sit in the HVE FBX Importer → Process box, widest scope first:

The last two grey out until you have made the matching choice — a collection in the Collection field, or a row in the Imported Runs list.

This matters once a .blend holds more than one run. Process All Imported FBX really does mean all of them, so if you have imported two crashes and only want to work on one, use Process Selected Imported Run and the other is left exactly as it is.

Max Shape Key Samples applies to whichever button you press (the cap on shape keys kept per mesh; 0 = no cap).

Runs with the same vehicle names. Two imports of the same vehicles — a baseline and a variant, say — stay separate. Processing works one run at a time, so a Freightliner in one run is never merged into the Freightliner in another, even with Process All Imported FBX.

Place a run's time zero

By default an imported run starts at frame 0, with the vehicle's setup pose on frame -1. To leave room ahead of the crash — matching video, or staging two runs against each other — set Time Zero Frame in the importer panel before importing. Setting it to 300 puts t=0 on frame 300.

The setup pose stays on frame -1, and the add-on writes a hold key on the frame just before t=0 (frame 299 in this example) carrying that same pose. That span is therefore flat: the vehicle waits at its starting position instead of drifting slowly into place across the pre-roll, and the only motion is the same one-frame transition into t=0 that an unshifted import already has.

Changing it after import. Open Post-Simulation Processing → Imported Runs. Every imported FBX and variable-output file is listed by filename with its current time zero. Select one and edit Time Zero — the run moves immediately, hold key and all.

Each run is independent: re-timing one leaves every other import exactly where it is, so you can hold run A at 0 and push run B out to 300. All the vehicles from a single file share one time zero and move together, since a run is one synchronized event.

To process just this run, highlight it here and use Process Selected Imported Run in the HVE FBX Importer → Process box — see Choosing what gets processed.

Three actions sit under the list:

Delete asks for confirmation first, and touches only that run: other imports in the file are left alone. Use Forget when you want to keep the result but stop tracking it — after that it can no longer be re-timed as a group.

Re-timing moves everything the run animates, including vehicle damage (shape-key animation, which lives on the mesh rather than the object) so the crush stays synchronized with the motion.

Skids are handled too, but by a different mechanism. A skid is drawn progressively by a Geometry Nodes group that compares each vertex's index against the current frame, so no amount of keyframe shifting would delay it — re-timing therefore also writes Time Zero and Time Scale into that modifier, and the skid starts laying down when the run does and at the run's pace. Tire paths and vehicle paths are drawn in full rather than progressively, and their keyed values move with the rest of the run.

A .blend saved before this existed is upgraded in place the next time a variable output is imported or a run is re-timed — the node group gains the Time Zero and Time Scale inputs rather than being replaced.

The scene frame range is not changed when you re-time a run, so your own start/end stay put. Extend the range yourself if a run now ends past it.

Set the time zero before running Process Imported FBX where you can. Processing bakes and merges shape keys, so doing it in that order keeps the damage timing unambiguous.

Match a run to the scene's frame rate

An import lands one key per data sample, so the run plays at the rate it was exported at, not the rate the scene runs at. That is fine when the scene exists to show the run, and wrong in two common cases:

• HVE writes the FBX at the simulation's output interval, while the variable output is exported at whatever interval you pick. The two halves of the same run then arrive at different rates.
• You want to compare a run against video — the footage sets the scene to 30 fps, and a 100 fps simulation plays at a third speed.

Both importers set the scene's frame rate from the data by default. Tick Keep Scene Frame Rate in the importer panel to leave the scene alone and have the run scaled to suit it instead.

Tell it what rate the FBX was written at

An HVE FBX does not carry its frame rate. FBX has somewhere to put one — GlobalSettings holds a TimeMode, plus a CustomFrameRate for rates outside the standard list — and Blender reads it. HVE writes neither, so Blender substitutes its own default of 25 fps and nothing downstream can tell that apart from a file that genuinely says 25.

That number is not cosmetic. Time Scale, the speed bake and the acceleration bake are all derived from it, so a 100 fps run read as 25 fps has every derived speed wrong by a factor of four.

So the FBX importer asks, and the number it asks for is one you already have: HVE's Output Time Interval. An interval of 0.01 s is 100 fps.

There is no "read it from the file" option, because there is no case where that would be right — this importer reads HVE's FBX and nothing else, and HVE declares no rate. If a file *does* declare one, the import says so: it did not come from HVE, and the rate you entered is used anyway.

Frame Rate describes the data, not what you want. It is a fact about the file and never changes to suit the scene. Rescaling is a separate decision, below.

The panel echoes the interval back (= 0.01 s between samples in HVE) so you can check it against HVE without converting in your head, and says what the rate will do in *this* scene — either "Scene will change from 25 to 100 fps" or, with Keep Scene Frame Rate on, "Scene stays at 25 fps; run scaled to 0.25 frames per sample".

Both of those play at real speed; the toggle only decides which of the two gives way. What does *not* play at real speed is a wrong rate: 100 fps of data left in a 25 fps scene at a Time Scale of 1.0 runs at a quarter speed.

This is the difference from the Variable Output importer. A variable output file has a time column, so its rate is measured from the data and nothing needs entering. An FBX has neither a time column nor a declared frame rate, so the rate can only come from you. Imported Runs says which a given run used — *Entered at import* or *Read from the file's time column* — and lets you correct an FBX's rate afterwards without re-importing. Everything downstream is the same either way: Time Scale and Match Scene Frame Rate work on both.

Playing a 100 fps run at 30 fps

Leave Frame Rate at 100 — that is what the data is, and it does not change. Then choose which side gives way:

Both play at real speed. The first keeps 30 fps for footage or rendering and costs nothing but the scaling; the second is simpler when the scene exists only to show the run.

Already imported at the wrong setting? Set the scene to 30 fps, then press Match Scene Frame Rate in Imported Runs — same result, no re-import.

Every import reports which rate it used and where it came from. A file that declares nothing is reported as a warning rather than used quietly, and overriding a rate the file genuinely did carry is flagged too.

After import, the same thing is available per run. Open Imported Runs, select the row, and use Data Frame Rate and Time Scale:

The panel shows the source rate and the scene's rate side by side, so you can see what needs matching. A 100 fps run in a 30 fps scene wants a scale of 0.3: 100 samples become 30 frames, one second either way. A 10 fps run in the same scene wants 3.0.

Scaling pivots on the run's time zero — the frame you placed it on does not move, and the setup pose stays on frame -1. Time Zero and Time Scale are independent, so changing one never undoes the other.

This replaces re-running the simulation at the scene's rate just to export a matching FBX.

A scale below 1.0 puts keys on fractional frames. Blender evaluates them correctly, but the *rendered* motion is still sampled once per frame, so a heavily compressed run shows fewer distinct poses than the data contains. That is the same limit re-exporting at the lower rate would hit.

Scale a run before Process Imported FBX where you can, for the same reason as time zero.

Show imported data in a display box

Use Data Display Box (under Post-Simulation Processing) to render imported variable-output data as live text inside an HVE-style box — label column, divider, value column — that updates on every frame.

The short version. The panel's sections aren't in the order you use them — the channel list is long, so it sits at the bottom, *below* the button that builds the box. Work in this order instead:

The panel tracks where you are and shows the next step as a numbered line near the top (*"Step 2 of 4: Check channels to show"*). Click that line and it opens the section the step is talking about; hover it for the full instruction. Once a box is built and attached to a camera the line goes away. Everything after step 4 — labels, units, decimals, colours, size, placement — is tuning, and each of those edits updates the box in place while Auto Update is on.

The rest of this section is the detail behind those four steps.

1. Click Scan Imported Data. Every channel imported by the Variable Output Importer is listed in groups per vehicle and data group (Kinematics, Kinetics, Driver, wheels, tires, …). A Time channel is always offered. Units from the CSV's units row are picked up automatically, so labels read like V Tot (mph). The scan only shows data the Variable Output Importer itself created — a generic scene custom property, or data imported by the Recon Toolkit, won't appear here even if both add-ons are installed on the same scene.
2. Every display box is driven by a named Box Profile — its own checked rows, Box Style, and camera settings — so different boxes can show completely different variables with entirely different styling instead of all sharing one global look. With only one box you won't notice anything extra; once a second, independent box exists, a row of buttons appears above Display Rows letting you pick which profile the rest of the panel edits, and an Editing Profile field lets you rename the one currently shown.
3. Display Boxes & Cameras comes first of the three collapsible sections, directly under the profile switcher — the button that builds the box is reachable without scrolling past anything:
   • Click Create / Update Display Box once you've checked some channels below. With Auto Update on (the refresh toggle next to the button, enabled by default), existing boxes rebuild automatically from then on whenever you change checked channels, row order, prefixes, or style — you won't need to click it again.
   • Remove All Display Boxes deletes every box at once. Each listed box shows which profile drives it in brackets, with a pencil button next to it that jumps the switcher above to editing that box's profile — handy once you have several boxes with different content.
   • *(Optional)* Attach each box to a camera with the 🔗 button. Where it then sits on screen is set in On Camera, at the bottom of Box Style & Placement — size and position are tuned in the same pass, so they live together.

Each row also has detach and ✕ remove (to delete just that box). Both perspective and orthographic cameras are supported — orthographic framing is computed from the camera's Orthographic Scale rather than its field of view, so the box sizes and positions correctly either way. An attached box automatically re-anchors itself to its corner every time the box rebuilds — including when you check or uncheck channels afterward — so it never needs re-attaching just because its row count changed.

• Add Display Box offers three ways to start a new box, depending on what you're after:
  • Linked Duplicate — the new box shares the profile you're currently editing, so it always shows the exact same rows and style as the original; edit either box and both update together. Use this to put the same information on two cameras at once.
  • Blank — the new box gets its own brand-new profile with nothing checked, ready to build up from scratch with completely different variables and styling.
  • Copy Current — the new box gets its own independent profile that starts as a copy of the one you're viewing (same rows, style, and camera settings), so you can tweak it from there without affecting the original.

Removing a box also removes its profile, unless another box still shares it — at least one profile is always kept around to edit.

Once attached, a box's on-screen *size* is set by Screen Width Fraction, not by Box Width — Box Width only controls the box's internal layout (divider position, column widths), so changing it afterward resizes the box on screen without also inflating or shrinking the text. That calibration is captured the moment you click the attach button, so click it again on an already-attached box any time you want to recalibrate its on-screen size to the current Box Width.

1. Two more collapsible sections follow. Both only tune a box that already exists, which is why they sit *below* the button that creates one; expand them at any time (each remembers its open/closed state). Both edit whichever profile the switcher above has selected:
   • Display Rows lists whatever is currently checked, top to bottom in box order. Use the ▲/▼ arrows to reorder rows, the pencil to edit that row's label, unit, decimal places, and Custom Color right there (no need to hunt through the groups below), and ✕ to remove a row (which unchecks its channel). Empty until you check at least one channel.
   • Box Style & Placement holds text size, box width, divider position, the Time Zero Frame / Time Offset settings, the Row Lines toggle (a horizontal divider between every row, off by default), and the box's Text, Background, and Frame colors. Its fields flow into as many columns as the sidebar is wide, dropping back to one per row when it is narrow. Time Zero Frame slides every checked channel's sampling relative to playback — nudge it if your imported data drifted a fixed number of frames out of sync with the scene, and every value re-syncs together, not just the printed Time text. Time Offset only changes the printed Time value itself (e.g. so it reads relative to impact) without touching what any row actually samples.

An On Camera group closes the section, holding everything that only applies once a box is attached to a camera:

• Camera Distance and Screen Width Fraction set how far in front of the camera the box sits and how much of the frame width it takes. Once attached, Screen Width Fraction — not Box Width — is what sizes the box on screen; Box Width then only controls its internal layout, which is why the two sit in the same section.
• Screen Anchor picks which corner or edge of the frame the box sits against — six of them, all four corners plus top and bottom centre.
• Offset X / Offset Y move it from there. They are fractions of the camera's view, not metres: 0.1 is a tenth of the frame, positive is right and up. Being fractions means a box nudged clear of a timestamp stays clear of it when the camera moves or the lens changes.
• Reset Offset puts it back on its anchor without retyping zeroes.

The whole group stays greyed out until a box using the profile you're editing is attached to a camera: every control in it only ever repositions an attached box, so before that there is nothing for them to move.

1. Check the channels you want to show, in the Channels section below — its header shows a running checked count and, like Display Rows and Box Style & Placement, collapses as a single section (handy once you've made your selections in a scene with many channels). Inside it, channels are organized in two levels: a top-level group per vehicle with the data subgroups (Kinematics, Kinetics, Driver, wheels, tires, …) nested inside. Both levels start collapsed — click a triangle to expand (headers show how many channels are checked, and filtering auto-expands matches). The checkbox on a vehicle toggles everything under it; the checkbox on a subgroup toggles just that subgroup; the checkbox next to an individual channel checks it into the profile you're currently editing — use Display Rows above to edit its label, unit, decimal places, and Custom Color once it's checked. Each subgroup also has a Prefix field applied to every label in it, shared across every box profile; for Variable Output groups it is pre-filled with the vehicle name, so rows read Honda Fit EX-L 5-Dr HB, V Tot (mph) — clear it if you don't want the prefix. It also has a Zero Frame Offset — an extra frame shift added on top of the box's own Time Zero Frame, applied only to that subgroup's channels — for re-syncing one dataset that's drifted a fixed number of frames out of step with the others (for example two datasets checked into the same box) without affecting anything else in the box.

If both the HVE and Recon toolkits are installed, each manages its own display boxes independently (scanning or rebuilding in one never touches the other's boxes); when the scene also contains boxes from the other toolkit, the panel notes how many so it's clear why they aren't listed here.

Values are sampled from the imported animation data each frame, so the box tracks the simulation during playback and in final renders. Re-scanning keeps your checked channels and edits.

HVE Configuration

Settings that live in HVE itself rather than in this scene. They are read when HVE starts, so a change here applies to the next HVE session and to anything exported from it -- not to data already on disk.

Set HVE's output precision

HVE Output Precision edits how many decimal places HVE writes for a variable, without touching the file an HVE update will overwrite.

Why you would. Every variable has a printf format in HVE's Language.rsc. VehKinematicX ships as 8.2f — position on a 0.01 ft grid. That is plenty for reading a coordinate off the screen, and not nearly enough to differentiate. At a 100 Hz export, one 0.01 ft step becomes 0.68 mph of speed and 3.1 g of acceleration, so a speed trace derived from position climbs in visible stairs and an acceleration trace is unusable. No averaging window recovers it, because the information was never written.

Setup. Point Edit → Preferences → Add-ons → HVE Toolkit → HVE Support Files at HVE's supportfiles folder. The add-on reads Language.rsc and language_overrides.rsc from the sys folder inside it.

Use.

1. Open HVE Toolkit → Post-Simulation Processing → HVE Output Precision and find the record. Three filters, usable together:
   • Search — matches the record name and its label. VehKinematic finds the six position and rotation columns.
   • Panel and Type — VariableOutput + Column is what lands in an exported CSV, and is the default.
   • Decimals — everything still at a given precision. Set it to 2 to see what will stairstep if you differentiate it; most of HVE's output ships at two.

The mark at the left of each row says what, if anything, language_overrides.rsc has to say about that record. The legend under the list repeats it:

The filled mark is reserved for precision because that is the column the list shows: a filled dot means the format beside it did not come from HVE.

1. Select it. The box below shows its panel, unit, label, and current format. If it is already overridden, it instead shows what the override actually changes, as two columns — Language.rsc on the left, your override on the right — with a row for the format, one for each label line, and one each for the soft and hard limits:

`` Language.rsc Override Format 7.4f 7.4f Label 1 "" "" Label 2 "time" "time" Soft limits 0 .. 40 → 0 .. 480 Hard limits 0 .. 40 → 0 .. 480 ``

The rows that actually differ are the ones not greyed out. Unchanged rows are still shown, because seeing that the format matches on both sides is how you find out the change you are looking for is somewhere else. An override can change any of the three things, so "overridden" on its own never told you which. If the answer is *nothing* — the override is a copy of Language.rsc — it says that too, and points at Remove Redundant Overrides. Selecting a record also loads its current width, decimals, label and limits into the edit fields, so you are always editing from the record's real values rather than from whatever was last typed. The ↩ button beside Precision, Label or Limits reloads that box, for when you want to undo an edit without reselecting.

1. Set Width and Decimal Places, then Write to Overrides.

Labels. Below the precision fields, what HVE calls the record — the text you see on its panel, and the heading above its column in an exported CSV.

• A Column has two heading lines, stacked. HVE writes "Turn" over " On " as a two-row heading, and the spaces inside the quotes are how the second row is centred under the first. Both lines get their own field, and the spaces are kept exactly as typed.
• Leave a line empty for a blank row. Whichever blank convention the record already used is kept, so blanking a Column heading writes NULL and blanking a coordinate label writes "".
• A handful of Label records hold HVE expressions rather than text — "Roll Steer:" + "Axle no. " + CurrentAxleNum. Those are not offered for editing: rewriting one as plain text would replace working code with the words it happened to contain.

Presets. A saved copy of the whole language_overrides.rsc, under a name. Made for exactly the case where you keep one high-precision set for deriving speed and another at HVE's stock values, and switch between them.

• Save Preset stores everything currently in the overrides file — precision, labels and limits together, not just the record on screen.
• Load Preset offers Replace or Merge. Replace makes the preset the whole overrides file, so anything not in it goes back to its Language.rsc value; the dialog says so before you commit. Merge lays the preset's records on top of what is already there and leaves the rest alone.
• Presets are stored in Blender's config folder, not under supportfiles — an HVE update is what overwrites things there, which is the whole reason the overrides file exists. Use the folder button to open it; each preset is an ordinary language_overrides.rsc, so one can be handed to a colleague or dropped straight into an install without this add-on.

Records HVE cannot see. If the overrides file contains a record that was pasted in with a leading tab, it reads as part of the record above it rather than as its own, and HVE silently falls back to the Language.rsc value. The symptom is an override that simply does nothing, with nothing anywhere to explain it. The panel says so at the top, names the record and its line, and Fix Indented Records moves it back to column 0 — only the indentation changes.

Limits. Below the label fields, the same record's soft and hard limits. Soft is the range HVE's panel offers by default; hard is the range it refuses to go beyond.

• A * means that limit is unset — 431 of the shipped rows are. Unset is not the same as zero, so it is shown as * rather than as a number.
• Coord2 and Coord3 records carry one set of limits per axis, and the panel asks which one you mean rather than assuming the first.
• A minimum above its maximum is refused: nothing could be typed into that field. A soft range reaching outside the hard range is written with a warning instead — unusual, but HVE's own Language.rsc ships five like it, and refusing to write what the vendor ships would be a tool wrong about its own rules.

Nothing is written until you press a Write button. The fields are just fields — typing in them changes nothing on disk, and neither does selecting a different record. There is no autosave and nothing to lose by looking around.

Changing many records at once. Set the filters until the count in the header is the set you want — VehKinematic + Column is the six position and rotation columns — then set Width and Decimal Places and press Write Precision to All Matches. It names the number before doing it, and writes straight away — there is no second step. Only the format changes; labels and limits are per-record and are left alone. A record that cannot hold the requested format is reported and skipped rather than abandoning the rest half-applied.

Undo. Blender's Ctrl+Z does not reach a file on disk, so every write keeps the previous language_overrides.rsc as language_overrides.rsc.bak and Undo Last Write swaps them back. It is one step deep, and it swaps rather than discards — pressing it twice returns you to where you started. A batch edit writes once, so one press undoes the whole batch. For a single record, Remove Override is the more precise tool: it drops just that record and lets Language.rsc apply again.

Tidying up. Remove Redundant Overrides drops every override that no longer says anything Language.rsc does not already say — the residue of setting a value and later putting it back. It lists what it will remove before doing it, and nothing HVE reads changes.

Worth doing occasionally: an override that matches the base is not harmless. It hides the fact that HVE's own default is what you are getting, and it will keep hiding it if a future HVE update changes that default, because the stale copy wins. An override that only changes a label or a limit is kept — it is still doing something, even though the precision matches.

Reading the files. The Files buttons load Language.rsc or language_overrides.rsc into Blender's Text Editor. That is a copy in the blend file, not a live view — edits made there do not reach HVE unless you save them yourself, and the panel will not see them.

What gets written. Only language_overrides.rsc. Language.rsc is never modified — and that is enforced rather than merely intended: every write in the add-on passes through one check that refuses HVE's own file by name, whatever it is handed and wherever the support files folder points. If something ever tries, it fails with a message instead of succeeding quietly. The whole record is copied across, not just the format, because HVE reads the overrides file on its own. The previous overrides file is kept as language_overrides.rsc.bak.

Restart HVE to apply — the overrides file is read at startup.

Recommended: 4 decimal places for position, 5 for angles (they are in radians, so 0.0001 rad is 0.006° — coarser than it looks). Width must leave room: use 10, not 8, or the column overruns and every row after it goes ragged. The panel refuses a width too small for its decimals rather than writing a broken column.

The error is absolute, not relative. The same 0.01 ft grid is 12% of a 5 mph manoeuvre and 1% of a 50 mph one. Slow manoeuvres need *more* precision, not less — the opposite of the intuition.

Lowering the export rate helps more than adding decimals. Ten times the gap between samples means ten times less amplification for speed and a hundred times less for acceleration. For a one-second low-speed manoeuvre, 20–50 Hz at the shipped precision beats 100 Hz at four decimals. The trade-off is time resolution: 10 Hz cannot resolve a crash pulse.

Units and scale

• Variable Output Importer: choose feet or meters to match the HVE output; the optional scale factor override gives finer control.
• H3D export: the file browser exposes a global scale option, and the GATB surface export has its own global scale setting.
• Set the scene unit system in Blender's Scene Properties → Units before importing so conversions match your data.

Troubleshooting

The EDC Toolkits tab is missing. Make sure the HVE Toolkit add-on is enabled in Preferences, you're in the 3D View, and the sidebar is open (N). Check the tab name in the add-on's preferences.

Which version am I running? The console prints it when the add-on loads — HVE Toolkit 3.3.11 successfully (re)loaded from <folder> — which also settles whether a second, older copy installed somewhere else is the one Blender picked up.

Panels are flat instead of nested. Switching the add-on off and on again in Preferences puts them back. If it keeps happening, the console output from a fresh Blender start is what helps — on Windows, Window → Toggle System Console.

The export button warns about mixed HVE object types. The selection contains objects classified as different types — use the one-click reclassify buttons in the warning (or H3D Setup → Object Type) to make the selection one type, then export.

License & support

HVE Toolkit™ is a trademark of Engineering Dynamics Company (Anthony Cornetto). The source code is GPL v2 or later. HVE Toolkit is a workflow aid for HVE simulation, not a substitute for professional engineering judgment — independently validate every result. See the bundled LICENSE file for licensing and the full disclaimer.

Official builds, updates, and support are provided by Engineering Dynamics Company; visit edccorp.com or contact EDC support.