Operation Log Dock
The Operation Log records what happened while you worked: the operations you ran, what you ran them on, how they ended, how long they took, and whether they were undone. It is a record for reading, not a place where work is done. Nothing in it changes the scene, and nothing in it can be deleted or edited.
It records the actions that explain your project: where its data came from, what changed it, what you measured or checked, what you exported, and each time the project was opened and saved. It does not record how the scene looks or how you are looking at it. Showing and hiding an object, isolating one, changing a colour, an opacity or a material, moving the camera, and changing a preference in Settings are not listed. You can still undo and redo a visibility change as before; it simply adds no line, and neither does undoing it.
Generating a mask 3D preview is listed, with the quality and the surface settings it was built with, because converting the preview to surfaces uses that preview. This covers the preview you ask for with the ribbon button or its quality menu, and from a script. A preview that an analysis builds, that a conversion builds for itself, or that is refreshed automatically after an edit is part of that action and adds no line of its own.
Where a setting decided the result of an action, the action carries it. Expand the line and the settings it used are listed with it, so you can see what a conversion or an import was given without looking for a separate entry.
Contour and text annotation measurements are recorded when creation finishes, as are new primitives. Primitive Fitting records the objects used and the primitive it creates. Copy to Measurements and Copy Annotation to Measurements record the tool and the measurements added. If fitting or copying stops after adding objects, the entry keeps those objects and reports Partly Succeeded. Snap To Surface on a primitive is listed as it is on a measurement, and Copy To Surfaces lists the primitives it read and the surfaces it created.
Edits you shape directly on screen are listed when you apply them: deleting, retaining and adding triangles and moving points in the Surface Editor, Extrude, Engrave Text, Curved Planar Reformat, and the segmentation Edit and 3D Editor tools. Deleting selected triangles in Diagnostics and Fixes is listed the same way. Each line names the objects that were edited and the settings the tool showed, such as the extrusion distances, the text and font, or the edit operation and threshold range. What you drew, selected, picked or dragged is not recorded, so these lines offer no Python call and Copy Python Call says why. A brush stroke or a click that changed nothing adds no line, and a brush that deletes triangles as you drag adds one line for the whole stroke, matching its one undo step.
Diagnostics and Fixes also lists Delete Selected Shells, which names the surface and the shells that were removed, Invert All Triangles, which names the surface it reversed, and Recompute Normals, which names the surface and the kinds of normal it rebuilt. What these were given is recorded in full, so unlike the triangle edits above they do offer a Python call. Deleting more than a couple of hundred shells at once is the exception: a list that long is summarized rather than kept, and that line then offers none.
The Surface tab's Analyze tools are listed when you run them: Elevation, Surface Distance, Shortest Path, Collision Detection and Shells. Each line names the surfaces the tool read, the settings its panel showed, such as the axis, the reference point or the contact tolerance, and what the tool measured, such as the smallest, largest and mean value, the length of the path, the collided triangles of both surfaces or the number of shells. The colour map a tool leaves on a surface is display and is removed when you close the panel, so these lines carry no undo step, and what you picked on the surface is not recorded, which is why they offer no Python call.
The Measure tab's Statistics and Analysis tools are listed when they calculate: Volume Statistics, Volume Similarity Statistics, the mask, mask 3D preview, surface and volume mesh statistics, Compare Masks, the Mesh Quality Analyzer and the Slice Analyzer. Each line names the object that was measured, the settings the panel showed, and the numbers it reported, such as the voxel count and volume, the triangles and area, the nodes and elements, the Dice and Jaccard overlap, or the smallest, largest and mean value of the metric shown. Only the calculation you ask for is listed: opening the panel, choosing a different target or slice, pressing Update and choosing the statistics. A panel that recalculates by itself after the scene changes adds no line. Measuring a triangle or element selection is not listed, because what you picked is not recorded. The colour map the quality and slice analyzers leave on an object is display and is removed when you close the panel. Some of these lines offer no Python call: the statistics of the visible masks, surfaces or volume meshes are measured over their union, a mask measured on one slice is measured over that slice, and a statistics choice can include values the scripting API cannot request, such as the shortest and longest edge of a mesh. Copy Python Call says so.
Setting up a FEM model in the FEM Export dialog of the Volume Mesh tab is listed: adding a material, creating node sets, element sets, sets and surfaces from a visible ROI, boundary surfaces and parts, and exporting the model. Each line names the volume mesh and what was created; the export also names the file and the format it wrote.
Moving, turning or scaling objects with the Interactive Transform gizmo is listed once per drag, and once per value you type into its boxes, with the transform it applied. A drag that turns or scales several objects at once offers no Python call, because each object turns about its own center and one call cannot repeat that.
A primitive fit offers a Python call only when the scripting method can use the same input points. Fits to selected triangles, several surfaces together, or selected measurement and primitive points have no copied call. A fit to one surface also has no copied call if preparing the surface removed duplicate or unused points, because the scripting method uses every original point.
An AI segmentation run is listed with the framework that ran it, the parameters it was given, the model it used and the version of the framework installed at the time. The line says whether the run created masks or modified an existing one: in Cellpose-SAM 2D mode the result is written into the active mask when that mask already holds data, and that mask is named as the object the run affected rather than as a new object. A run that creates masks is one undo step for the whole run, however many masks it produced. The line offers the Python call that repeats the run with the same settings, and says that the run will not produce the same masks again.
What the Operation Log is not
Read this section first. It describes limits that the rest of the page assumes.
- It does not record everything. Recording is best effort over a chosen set of actions. Something Volvicon does not record leaves no line, and there is no setting that widens what is recorded.
- It does not identify a person. It records the operating-system username of the account running Volvicon, including for actions that come from Python. Everyone who uses a shared account is recorded under the same name. No computer name is recorded.
- It is not a backup and it is not a way to recover work. It holds a description of what was done, never the result of doing it. Save your project.
- It does not guarantee that a workflow can be repeated. Most actions offer a Python call. Actions whose inputs were picked on screen, such as selected triangles or the position of a clipping widget, or whose data could not be captured exactly, do not. An available call does not guarantee the same result: the log does not check whether referenced files or scene objects have changed since the action was recorded, and an AI segmentation run produces what its framework, model and device decide rather than the masks it produced before.
- It does not copy scene objects. Volumes, masks, surfaces and meshes are not backed up by the log. Some large argument lists are stored separately and may be saved with the project; the log entries and JSONL exports carry references and summaries rather than embedding those lists.
- It is not complete when it says it is not. When history is missing, the dock says so above the list and an exported file says so in its header. Those statements are the ones to trust.
Those two limits are the ones that decide what you will find later: whether an action leaves a line at all, and whether that line can be turned back into a call. They are independent of each other.
An available call still does not guarantee the same result, because the log does not check whether the files or scene objects it refers to have changed since, and because some actions, such as an AI segmentation run, are not decided by their settings alone.
Opening the dock
The Operation Log is a dockable panel. Open it from Panels → Operation Log in the title bar, or press Ctrl+Alt+L; when another panel covers it, the shortcut brings it forward. It is hidden until you open it, and once open it can be moved between the top and bottom dock areas, dragged out into a window of its own, or closed. Where you move it is not remembered between sessions: it starts hidden in the bottom dock area each time Volvicon opens.
Recording happens whether or not the dock is open. Opening it does not start anything and closing it does not stop anything, and there is no setting that turns recording off.
The Operation Log is not the Messages dock. The Messages dock lists what Volvicon told you during the session, such as warnings and the text of message boxes, and it can be cleared. When an operation you started finishes, the Messages dock also shows one line for it.
What the list shows
Each line is one action, with these columns:
| Column | What it means |
|---|---|
| # | Where the action sits in the history: its number in the project history, or in this session for an action the project does not keep |
| Time | The local date and time of the action's result, or of its start while it has no result |
| Operation | What the action was |
| Objects | The objects it worked on |
| Duration | How long it took |
| Source | Whether it came from the interface or from a script |
| Outcome | Succeeded, Partly Succeeded, Failed, Cancelled, No Change, Running, or Interrupted |
| Undo | Whether it can still be undone |
An action started from a script and the operation it performed are shown as one line, with both still available: expand the line to see the exact call that was made, the values it used, any settings it read, and every undo and redo attempt on it.
Expand an action to see its Username. Source still describes how it started, such as User or Python. Each undo or redo attempt shows the username recorded for that attempt. Usernames stay with the history when a project is saved, reopened, or passed to someone else; opening it does not replace earlier usernames. An entry whose username could not be obtained shows Not recorded.
Usernames are included in copied summaries and CSV/JSONL exports. The scripting history listing exposes the recorded value as LogEntry.user_name, with an empty string when it was not recorded. Sharing a project or exported log also shares its recorded usernames.
When an action was given a group of settings rather than single values, such as the repair checks of a surface or the parameters of a reconstruction, the expanded line lists every setting in that group on its own line, named the way its control is labelled in the tool. A setting that belongs to a sub-group of its own, such as the mode of point matching in a registration, is shown with that sub-group's name in front of it.
An action that read many files, such as a CT reconstruction from projection images or an imported image stack, names every one of them, numbered and one to a line. Only the first few hundred lines are shown and the entry says that the rest are not shown; an export carries the whole list. A selection of several thousand files, or one whose paths are together too long to keep, is summarized by its size instead, and that entry then offers no Python call.
An action that has started and has not finished reads Running while this session is still going. The same unfinished action read from a project saved by an earlier session reads Interrupted, because that session ended without it reporting a result. A CSV export and a copied summary read Not finished for either, because neither can say what is happening by the time it is read. A JSONL export carries the recorded state itself and is unaffected.
Narrowing the list
The presets above the list are shortcuts for the questions most often asked:
| Preset | Shows |
|---|---|
| Changes and Results | The default: actions that changed the project, actions that wrote a file, and actions that did not fully succeed |
| All Actions | Everything the log holds, including the session's own start and end, and any line recorded by an earlier version of Volvicon that this one no longer records |
| Python Calls | Actions a script performed |
| Needs Attention | Actions that failed, were cancelled, were interrupted, or only partly succeeded, including failed undo or redo attempts |
| Undo and Redo | Actions with undo or redo attempts |
Click Filters to narrow further by category, by object, by outcome, by source and by time, and search with the box at the top. The search matches literal text without case sensitivity: it is not a pattern, so characters such as ., * and ( match themselves. The category list ends with Not in this build, which lists actions recorded by another version of Volvicon that this one does not recognise. Reset puts every control back to the default view.
Beside the search box a showing n of m count says how much of the history the current narrowing is hiding, so a filter can never make the history look shorter than it is.
Narrowing never changes the history. It changes what is on screen and nothing else. There is no command anywhere in this dock that deletes, clears or edits a record.
When history is missing
A message above the list appears when part of the history is not available. It stays visible whatever you have narrowed the list to, and it separates the cases that are genuinely different:
- A stored history could not be read. The project carries an unreadable history, for example one written by a newer version. Entries that can be read and retained within the storage limits are written back unchanged when you save. The message explains when history or associated large values cannot be preserved.
- Older project history was dropped. The project's history was longer than what is kept, so the oldest part of it is no longer there.
- The oldest records of this session were dropped. The current session recorded more than is kept in memory, so the oldest of it is no longer in the list. Records this session wrote successfully to its session file are still in that file; records that could not be written, and history that came from a project rather than from this session, are not.
- Something could not be recorded, written or read. The message carries the application's own explanation of what happened, which is also where the detail of an unreadable stored history appears.
Records that mark a hole in the history pass every preset, but search and the additional filters can hide those rows. The message above the list remains visible.
When something could not be recorded, the Messages dock also shows a warning with the explanation, whether or not the Operation Log dock is open.
Exporting
Right-click in the list to export. Two formats are offered:
| Format | Use it for |
|---|---|
| JSONL | The faithful record. One JSON object per line, carrying every field of every recorded event, for archiving or for reading with another tool |
| CSV | A flat summary for a spreadsheet. One line per action, with the columns above and Username. It is a summary and not an interchange format, and the file says so on its first line |
Export History writes the whole history and is never narrowed by a filter. Export Selected is offered while something is selected and writes the actions you have selected.
An export names exactly one history, and you are asked which:
- Project history is what the project carries and what saving the project would keep, including what earlier sessions recorded.
- Current project session is what this session recorded for the open project, including actions a project never keeps, such as an open that failed or a statistic computed without writing it to a file.
They are exported separately because they are ordered differently and have no common order between them.
The JSONL header identifies the history, selection, export time, Volvicon version and completeness. CSV starts with a summary declaration identifying the selection and completeness; it does not include the export time or Volvicon version. When completeness cannot be determined, the file reports unknown.
Exporting the history is not itself recorded, and it does not change anything.
Copying one action
The context menu also copies a single action:
- Copy Summary copies a textual summary of the action.
- Copy Python Call copies the call that reproduces the action, when there is one. When there is not, the action says why rather than offering a call that would do something slightly different. When a call is offered but comes with a caveat, such as writing a file outside Volvicon or producing a different result each time it runs, the action says that too before you copy it. When the call returns a result object, such as the result of a registration, the copied call stores it in a variable, for example
landmark_registration_result, so its values can be read after the call. - Copy JSON copies the raw record.
The same menu offers Show Related Undo/Redo, which expands the action and moves to its first undo or redo attempt. It is available only on an action with recorded undo or redo attempts, including failed attempts, because an undo adds no line of its own.
Adding a comment
Add Comment... on the filter row, or in the context menu, asks for a note and adds it to the project history as a record of its own. Use it to explain why something was done, to mark a result you checked, or to leave a reminder for whoever opens the project next.
A comment is listed with the actions around it, under the Project category, and it is saved with the project like any other change. It cannot be edited or removed afterwards, which is what makes it a record rather than a note.
Where the history is kept
Two places, with different lifetimes.
- In the project. Actions that changed the project are saved inside the project file and come back when you open it. So is every export the log records, including saved snapshots and the result and FEM files a script writes, because data that leaves Volvicon is part of the project's record: whoever opens the project can see when data was exported, what was exported and who exported it. Every open and every save is kept too, each as its own line in the order it happened and with the username that performed it, so the project shows each time it was opened and saved, when, and by whom. That includes the save that wrote the file you open. An open is written into the project file by the next save, so an open followed by no save is not in the file; the session file on that computer still records it. A save that failed or was cancelled is kept by the next save, and an open that failed is not kept with the project. A mask 3D preview you generated is saved there as well, because surfaces converted from it depend on it, even though the preview itself is not saved. Statistics, quality checks and other results that were not written to a file are not saved there, and closing a project is not recorded. Anything recorded after the last save reaches the project file when you save again. A project written by an earlier version keeps every line it already carried, including lines for actions this version no longer records.
- In a session file. While Volvicon runs, everything it records is also written to a session file in the application's local data folder, so that an interrupted session leaves a record.
Session files that were closed cleanly are removed after 30 days. A session file left by a session that did not close cleanly is not removed automatically, because it is the only record of what that session did. On a machine where Volvicon is regularly interrupted these files accumulate; they are plain text and can be deleted by hand once they are no longer wanted.
Recording is always on
There is no setting, command line option or environment variable that turns recording off. Every session records and writes its session file, and the Operation Log dock is always available.
Reading the history from a script
The scripting API can read the recorded history, list it a page at a time, report what it can and cannot say about itself, and write it to a file. It cannot delete, clear or edit anything, and reading the history is not itself recorded. See the Log Operations tutorial for a runnable walkthrough, and the scripting API reference for OperationLogOperations.