JanetRossini.github.io

Lua, LSL, Blender, Python in Second Life

---

Project maintained by JanetRossini

Path Representation

Jun 25, 2025 • [design, lua, movers, testing]

One central issue in our movers is conversion from a distance to a point (and rotation) along a defined path. Let’s explore the space of paths and their representation.

Brainstorm

We’ll start with random topics, including path spacing, the representation of path information, and some ways of storing a path.

Fixed Spacing

We can have the path information recorded at fixed intervals. When we do, we can use a very compact storage mechanism, essentially long arrays of positions or rotations. Access is as fast as it can be for a stored path, and storage is quite compact, although there is wastage along long straight parts of the path.

Variable Spacing

There are at least two reasons why we might use variable spacing in a path. One is that it might be possible to store a longer path in less space by using a variable path.

Another is that we might be dealing with a path where the information about the path is inherently variable. SLRR is an example of that: the guides are spaced at various distances as the path wanders.

Variable spacing might allow for more compact storage, but random access to the path might be slow.

Calculated Path

A path might be represented by a calculation. A simple example of such a thing is a path defined by Bezier. There is associated storage, of the Bezier’s parameters, but the actual path points are computed rather than looked up.

While the Bezier (or NURBS) calculations are somewhat complex and possibly slow, there are certainly calculated paths, such as lines, circles or ellipses, or even some more complex paths such as spirals or helices, that would be compact and efficient.

Memory Storage

If a path is short enough and its storage requirements are small enough, keeping the whole path in main memory can be feasible. Schemes like this tend to be limited in the size of the path they can handle, but their code tends to be compact and simple.

Link Set Data Storage

We can store a path in Link Set Data. Access to LSD is very fast and within the capacity limitations, this can be very effective. Fixed spacing tends to work best with this and any form of remote storage, depending on need. For example, a vehicle that only moves forward, such as a roller coaster, might conceivably benefit from a variable-length LSD store.

Notecard Storage

Storing the path in a notecard has advantages including easily updating the path, which might allow one coaster package to travel very different coaster paths. Generally we have combined this scheme with an in-memory path, because of the slow and inconvenient legacy access to notecards.

Notecard access has recently received an update that allows buffering the card, after which access is more direct. We have not experimented with this but it seems likely to be useful.

“Remote Storage”

In principle, one could store path information somewhere on the web and access it via http (or other network protocols if SL provided them).

Note Made Along the Way

The “natural” object representation might be notably less efficient than other more compact, less object-oriented representations. There is probably value in exploring this. Objects make for clean code but may have performance issues.

Consolidation

Looking at the above, I get these ideas for things we might do:

• Explore performance of small objects vs array representations. We’d still use objects: they’re just named collections of data and functions. But the bottom-level ones might be very different. A dynamically discovered path may benefit from lots of tiny objects, while a statically-defined path might benefit from a very dense structure based on arrays.

• Learn about performance of buffered notecards. If they’re capable enough, they could have real advantages in convenience.

• Explore a few different objects that deal with different storage schemes while presenting a common interface to the base-level mover code.

• Consider whether there is a faster form of calculated path than Bezier/NURBS, one that we could use. Lines are much faster than Bezier. Conic sections are probably three times faster. We parse the SLRR into Beziers for appearance sake, making our path motion smoother. Is there a way that’s nearly as good but substantially better in performance?

Summary

Just notes, things to think about. I’ll probably keep working for a while at the low level, learning about ways to represent paths and process them down at the bottom level.

Safe paths!