A concept film shows an engineering principle; it does not prove performance. The problem: a screen that looks like an instrument makes everything on it look measured, and a technical viewer who cannot tell animation from measurement trusts none of it. So scripts check our concept films before assembly. A readable number on screen, or a frame with boxes but without the line "animated illustration, not detector output", stops the build; the cooperative perception film adds a line-of-sight gate based on Blender ray casting. A measured figure appears only with a known setup, method and person behind it; in our films, only the EtherCAT bench figures qualify.

In short

  • Anything that looks like an instrument reads like a measurement. Our policy in two sentences: "Atmosphere can be invented. Evidence cannot."
  • Every element on screen falls into one of four categories (decoration, context, measurement, credential), and the burden of proof rises with the category.
  • Gates are scripts, not a person watching; if one fails, the film is not assembled.
  • The expensive lesson: a green gate may not test what you think it tests. Break it on purpose and watch it fail.
  • A number reaches the screen only with a bench behind it, like the 19.2 µs average, 30.9 µs maximum and 0% packet loss in the EtherCAT film.

Why does instrument styling suggest measurement?

Our films use the language of an engineering console: dark background, thin lines, boxes that follow objects, technical labels. That language has a price. A frame that looks like an oscilloscope suggests every line is a signal; a number next to a box reads like a detector's confidence.

We learned this from our own mistake. In August 2026 we removed some performance figures from our website because we could not document their setup and method, and we rewrote the EtherCAT content with real bench data. The rules below came out of that correction. They rest on one test: if a visual element can reasonably be read as a measurement, it must come from a real measurement; otherwise it belongs to the atmosphere layer.

Four categories: decoration, context, measurement, credential

The higher the category, the heavier the burden of proof:

Category Examples Rule In our films
A. Decoration grain, glow, grid, light sweep, particles Always allowed; makes no claim Light, haze and moving highlights
B. Context board name, CPU, RTOS, compiler, kernel version Must be real; makes no claim about us Bench details in the EtherCAT film; type names such as INT8
C. Measurement latency, jitter, fps, bandwidth, packet loss Published only if setup, method and who measured are known Only the bench figures in the EtherCAT film
D. Credential standard and certificate names Never decoration; only as a customer's requirement Not used on screen

Motion often draws the line: a moving light is decoration, a changing number is not. A counter that ticks like a frame rate reads as data with no data behind it, so it is not allowed; an animated waveform or time series needs real data too. On our website the same rule lives in the type system: a measurement record without a setup or method field does not compile.

Gates: scripts that stop the assembly

A gate is a check the build script runs before it assembles the film. Eyes get tired and see what they expect; a script asks the same question on every build.

The digit gate

The bird or drone film has no number on screen whose value you can read. The gate scans all visible text in the typography layer (titles, lower thirds, labels) against a pattern list and stops the build if it finds a digit. The allowed patterns are INT8 and 3D: a data type and a technique. Adding a pattern means answering one question: does this digit report a quantity? The cooperative perception film's description gives viewers the same rule: "There are no figures in this film."

# Sketch: every text in the overlay is checked against patterns
ALLOWED = ("INT8", "3D")   # type names, not quantities

def digit_gate(visible_texts):
    for text in visible_texts:
        rest = text
        for pattern in ALLOWED:
            rest = rest.replace(pattern, "")
        if any(c.isdigit() for c in rest):
            return False, text   # the build stops
    return True, None

The honesty gate

Every frame that shows a box or a track must also show the line "animated illustration, not detector output", and a script checks it. Each frame with a box is compared with the time windows in which the line is visible; one uncovered frame fails the gate. The bird or drone gate also checks the reverse: if the line is on where there are no boxes, it warns, because a needless disclaimer also wears down trust. The closing credits say the same for the whole film: "concept film".

The geometry gate

The cooperative perception film is about geometry: a container stack hides a forklift from the vehicle, and a mast at the junction sees the corridor. We did not draw who sees what. Every half second of scene time, a script casts a ray from each sensor to the target with Blender's ray_cast; if the ray hits a surface first, there is no line of sight. The result goes to a file, and the gate checks it on every build: if the vehicle sees the forklift where it must not, or the mast cannot see it where it must, the gate fails. When the scene changes and line of sight is recomputed, this gate fails first.

Credits and asset gates

"Real time has a cost" builds on a paper whose second author is our founder; the film animates the principle and does not repeat the paper's measurement. The credits gate looks for the full closing text, including the citation and the note that the result was not measured on the scene shown. The asset gate looks for the files the build depends on, such as frames and track data. If data is missing, the gate fails instead of passing: without track data, the honesty gate has nothing to check.

When the gate lied

The geometry gate's most useful moment came when it went green for the wrong reason. After we turned the vehicle body to face the right way, the test said the vehicle could not see the forklift in any sample; the claim held everywhere. But the report also named the object that stopped each ray, and that object was the lens housing of the vehicle's own camera: after the rotation, the ray started inside the lens. A name gave the bug away, not a number.

We excluded the vehicle's own parts from the test. Now it said the vehicle could see the forklift in every sample. The cause was again in the test: when a ray hit an excluded surface, the test answered "sees" and stopped instead of continuing the ray. The first hit was always the lens, so the stack was never tested. The fix was to cast the ray again from just past the excluded surface:

# Pseudocode: an excluded surface does not end the ray
# excluded: the sensor's own body and the target itself
def line_of_sight(source, target, excluded):
    direction = (target - source).normalized()
    total = (target - source).length
    travelled = 0.0
    while True:
        hit, point, obj = ray_cast(source + direction * travelled,
                                   direction, distance=total - travelled)
        if not hit:
            return True, None        # nothing in the way
        if obj.name in excluded:
            # the old version returned "sees" here
            travelled = (point - source).length + SMALL_STEP
            continue
        return False, obj.name       # record the reason: the blocker

The rule: a green gate does not mean it tested what you think it tested. Break the gate on purpose and watch it fail: put an obstacle in the mast's line of sight, write one digit into a lower third, shorten the honesty window by one frame. Software testing calls this mutation testing: add bugs on purpose, and if the tests still pass, they cannot catch those bugs.

Is it fair to tune the scene?

In the first timing of the cooperative perception film, the roadside node's decision and the moment the vehicle's own view opened fell on the same second. The film told a story in which cooperative perception gained nothing. We rebuilt the motion profile. Plainly: we tuned the scene to make the film convincing.

That is fair, because a concept film shows a principle and does not prove it; that is why its credits say "concept film". The limit is in what you tune:

Change to the scene Fair? Why
Vehicle speeds and timing Yes It picks a scene where the principle is visible; the credits say so
Drawing line of sight by hand No Ray casting decides who sees what
Showing the time gained by the scene in seconds No That number belongs to our scene, not to a system
Presenting the scene as field footage No Synthetic images are never presented as field recordings

The new timing also passed the geometry gate: the vehicle still cannot see behind the stack, and the mast still can. Choosing the scene is free; ray casting decides the physics inside it. Our cooperative perception article separates the engineering from the scene.

Sound, layers and frames: where gates cannot see

In the bird or drone film, the film's own sound carries the sentence "a wingbeat is a slow pulse, a rotor is a steady tone". We put no spectrogram on screen: it is a data plot, and we have no publishable measurement for it. Yet the sound made a claim. In the first mix, a small speed difference between two rotors produced a beat in the envelope close to the wingbeat rhythm, so the sentence failed the ear test. We measured the sound design and fixed it: a claim that rests on sound design gets measured too. The bird or drone article covers the cues.

In the same film, a glass panel and a lower third repeated the same lines; we removed the panel, because each layer should tell one state. The aim point of the pan-tilt head came from a sequential filter, so its value in a frame depended on how many frames had been processed before. The single-shot render and the full-film pass looked at different places in the same frame, and a box ended up in empty air next to the drone. The aim is now computed once for the whole film with plain math: anything tied to the camera must not depend on frame order. Overlay data and image must come from the same state; this is the film version of two sensors stamped by different clocks. The honesty gate could not catch it, since the line was on screen and only the box was wrong. A person watching the film found it.

When does a number reach the screen?

The EtherCAT film is the one exception: the screen shows a 19.2 µs average and 30.9 µs maximum transfer time, 25.5 µs in total including the software path, and 0% packet loss, with the condition right underneath: one slave, 64-byte process data, 10 kHz cycle, 100 Mb/s link. Behind them is a bench whose setup, method and measuring engineer are known: a commercial Class B EtherCAT master on a TI Sitara AM572x IDK running TI-RTOS, and a TI Delfino TMS320F28388D slave with an integrated ESC. Transfer time runs from sending the frame until all of it has come back on the wire; the total adds the master software's share. The full tables are in our measurement method write-up (in Turkish) and the EtherCAT case study.

We publish the maximum as well as the average: on a control loop the average makes you comfortable, and the maximum decides whether the machine ships. We give no DC synchronisation figure, because the stack is Class B and does not use distributed clocks. The note under the numbers draws the line too: the cabinet, the arm, the humanoid and the car are 3D illustrations, and the CAN comparison is structural. We do not sell an EtherCAT master; we bring lines up on TI silicon and characterise their timing. Our one-frame article explains the mechanism.

Boxes in the synthetic data films have yet another origin: no detector predicts them; the renderer or the placement step writes them because it already knows where each object is (ground truth). In the Blender obstacle film, a "synthetic data" label stays on screen for the full film; synthetic images are never shown as field recordings.

Five questions to ask of any engineering video

  1. Is the scene real? Field footage, synthetic render or animation? If the credits do not say, ask.
  2. Where is the setup behind the number? Board, operating system, software stack, conditions and method; if one is missing, do not read the number as a measurement.
  3. Maximum or average? With only an average, you know nothing about the worst case.
  4. Whose output are the boxes? A detector's prediction, a renderer's ground truth and an animator's drawing look the same on screen.
  5. What do the credits say? Look for "concept film", "synthetic data" or "field capture". If none is there, you do not know what you are watching.

Our video hub is a good place to try these questions.

Where it goes wrong

  1. Treating a green gate as proof. A gate tests only the question it is asked; in the lens bug the claim held because the ray hit the lens.
  2. Forgetting that the gate reads the layer. The digit gate does not read pixels, so it is blind to a digit painted into the 3D scene (a container number, a sign).
  3. Recording results without reasons. Without the name of the blocking object, the lens bug would have stayed hidden behind "claim holds".
  4. Counting missing or stale data as a pass. If the file to check is missing, the default answer must not be "passed". The line-of-sight file is produced in a separate step; if that step is not rerun, the gate checks the old scene.
  5. Confusing a line on screen with a line that is read. The eye still goes to the box. One benefit of the line in every frame: when a clip is cut and shared, the label travels with it.
  6. Borrowing a result measured elsewhere. A reduction reported in a paper belongs to that paper's hardware and task.

What this article cannot tell you

  • Gates catch only the errors we have defined. A script is not an approval authority: it catches patterns, and people judge context.
  • Gates do not remove misunderstanding on the viewer's side; they make it harder for us to put something false on screen.
  • The film scenes are still illustrations. The geometry gate shows that a scene is consistent with itself; it says nothing about a real terminal.
  • We have not measured how often our gates miss errors; the lens bug showed that a gate can be wrong too.
  • The EtherCAT numbers characterise one bench setup; a different setup gives different numbers.

Frequently asked questions

What is a concept film?

A concept film shows an engineering principle with 3D animation but does not prove how a system performs. In Spikedge concept films, the scenes, vehicles, sensors and the boxes, tracks and labels on screen are our own animation, and the closing credits say "concept film".

Are the boxes in the films real detector output?

Not in the concept films: boxes, tracks and labels are animation, and every frame that shows a box carries the line "animated illustration, not detector output". The boxes in the synthetic data films are ground truth, written during rendering or object placement.

Why are there no numbers in the concept films?

A number on screen reads as a measurement, so it has to come from a real measurement, and we have no publishable measurement for these scenes. The digit gate stops the build if it finds a digit on screen, apart from a few patterns such as INT8 that do not report a quantity.

Where do the numbers in the EtherCAT film come from?

From our own bench: a commercial Class B master on a TI Sitara AM572x IDK and a TI Delfino TMS320F28388D slave with an integrated ESC. The film shows a 19.2 µs average, a 30.9 µs maximum and 0% packet loss; setup, method and conditions are published in our measurement method write-up.

Sources