Voxels 👾

2025-08-18T00:00:00+00:00

This is going to be a brief post, but with an image that makes me exceptionally happy:</p>

</p>

I've been implementing a voxel data structure similar to an octree, but with a larger branching factor (still powers of 2), that contains a hashmap at the root of the tree. It takes inspiration from the paper "VDB: High-Resolution Sparse Volumes with Dynamic Topology" by Ken Museth</a>.</p>

The image shows the mesh graph voxelized into a tree containing depths 2, 3 and 4 (VDB<2, 3, 4></code>). Depth 2 gives 64 children, 3 gives 512 children, and 4 gives 4096 children. See the following overview:</p>

Depth</th> Child count</th></tr></thead>

0</td> 1</td></tr>

1</td> 8</td></tr>

2</td> 64</td></tr>

3</td> 512</td></tr>

4</td> 4096</td></tr>

5</td>

32768</td></tr> </tbody></table>

Having these higher child counts (i.e. branching factor), helps to keep the tree very wide, as opposed to an octree, where each depth only has 8 children.</p>

Simple undo history for a mesh graph using diffs

2025-08-14T00:00:00+00:00

Undo is a fundamental feature in many software applications, and my app ShapeReality - 3D Modeling is no exception. Due to the ubiquity of undo, one might expect implementing it to be a solved problem, but there commonly isn't a one-size-fits-all approach.</p>

This post will go into how I implemented undo for my mesh graph data structure, and how this fits into the complete undo history of an application containing multiple data structures and contexts. These principles should be applicable to other applications and data structures too.</p>

Command pattern

struct </span>ICommand </span>{
</span>    </span>virtual </span>void </span>undo</span>() </span>= </span>0</span>;
</span>    </span>virtual </span>void </span>redo</span>() </span>= </span>0</span>;
</span>}</span>;
</span></code></pre>
Undo and redo stack#</a>
</h2>
Commands get stored in an undo_stack</code> and redo_stack</code>:</p>
struct </span>History</span>{
</span>  std</span>::</span>stack<ICommand</span>*</span>> undo_stack;
</span>  std</span>::</span>stack<ICommand</span>*</span>> redo_stack;
</span>}</span>;
</span></code></pre>
Any time a command is performed, it gets pushed onto the undo_stack</code>, and the redo_stack</code> gets cleared.</p>
Alternatively, one could create branching undo, where each time you undo, and then perform new changes, it creates a new branch. While this could be an interesting feature, it requires a lot of additional UI to communicate the existence and state of this branching history. Compared to two simple buttons, this complexity doesn't weigh up against the benefits.</em></p>
When History::undo()</code> is called, it takes the top of the undo_stack</code>, calls Command::undo()</code> on it, and pushes it onto the redo_stack</code>. The inverse is done for History::redo()</code>.</p>
Note about invalid states#</a>
</h3>
When the user performs any modification to the data structure, it must</em> be stored as a command. If a change is not recorded, and History::undo()</code> is called afterwards, the data structure can end up in an invalid state. See the following simplified example:</p>
State before</th> Operation</th> State after</th> Undo stack after operation</th></tr></thead>

ABCDEF</code></td> erase(1), store</code></td> ACDEF</code></td> [EraseCommand(1, 'B')]</code></td></tr>
ACDEF</code></td> erase(0), don't store</code></td> CDEF</code></td> [EraseCommand(1, 'B')]</code></td></tr>
CDEF</code></td> undo EraseCommand(1, 'B')</code></td> CBDEF</code></td> []</code></td></tr>
</tbody></table>
If the letters are required to be in alphabetical order, the non-recorded operation caused the undo</code> operation to make the state invalid.</p>
The mesh graph also has such requirements, for example:</p>

When two vertices are selected that connect to each other via an edge, the edge must also be selected</em></li>
When all vertices / edges are selected that make up a face, the face must also be selected</em></li>
</ul>
For this reason, it's important that anything modifying the mesh graph is pushed to the history as an undoable command.</p>
Command implementation for mesh graph - the dumb approach#</a>
</h2>
There are many operations that can be performed on the mesh graph. Take for example:</p>
struct </span>Mesh</span>{
</span>    </span>// ...
</span>    </span>void </span>insert_vertex</span>(</span>...</span>);
</span>    </span>void </span>insert_edge</span>(</span>...</span>);
</span>    </span>void </span>insert_face</span>(</span>...</span>);
</span>    
</span>    </span>void </span>erase_vertex</span>(</span>...</span>);
</span>    </span>void </span>erase_edge</span>(</span>...</span>);
</span>    </span>void </span>erase_face</span>(</span>...</span>);
</span>
</span>    </span>void </span>insert_face_or_edge_from_selected</span>(</span>...</span>);
</span>    </span>void </span>extrude_selected</span>(</span>...</span>);
</span>    </span>void </span>select_linked</span>(</span>...</span>);
</span>    </span>// ...
</span>}</span>;
</span></code></pre>
To make these operations undoable, I considered a naive approach, where a corresponding command has to be created for each operation. e.g.:</p>
struct </span>InsertVertexCommand : </span>ICommand </span>{
</span>    </span>// ...
</span>    </span>void </span>undo</span>() </span>override</span>;
</span>    </span>void </span>redo</span>() </span>override</span>;
</span>}</span>;
</span>struct </span>InsertEdgeCommand : </span>ICommand </span>{
</span>    </span>// ...
</span>    </span>void </span>undo</span>() </span>override</span>;
</span>    </span>void </span>redo</span>() </span>override</span>;
</span>}</span>;
</span>// etc.
</span></code></pre>
However, life's too short for this. Not only does this make the code needlessly verbose, it's also a pain to figure out what data to store in the command and how to reverse the operation. Each function can also call the other functions recursively, thus making this approach highly complex to implement.</p>
The super lazy approach - pool copies#</a>
</h2>
Recall that the mesh graph contains 5 elements</a> (Vertex</code>, Edge</code>, Face</code>, VertexUse</code> and EdgeUse</code>). These elements are stored in a pool.</p>
If we're exceptionally lazy, we can copy the pools before and after executing the operation, and on undo() assign the old pools to the pools, and on redo assign the new pools to the pools.</p>
The issue with this however, is that it takes up an insane amount of memory. For each operation performed, no matter how small, we store an entire copy of the mesh in working memory. For sufficiently large meshes, this approach won't work.</p>
The less lazy approach - pool diffs#</a>
</h2>
This brings me to the final design:</p>
Instead of storing a copy of the entire pool in a command, we only store elements that were changed. Elements are considered changed if they: 1) were deleted, 2) were inserted or 3) had their data changed.</p>
For each changed element, we store the before and after state. This gets stored in a PoolDiff<T></code>.</p>
template </span><</span>typename</span> T>
</span>struct </span>PoolDiff </span>{
</span>    </span>struct </span>Entry</span>{
</span>        </span>unsigned int</span> index;
</span>        T before;
</span>        T after;
</span>    </span>}
</span>    std</span>::</span>vector<Entry> entries;
</span>
</span>    </span>void </span>undo</span>();
</span>    </span>void </span>redo</span>();
</span>}</span>;
</span></code></pre>
Recording a diff#</a>
</h2>
Recording a diff is left as an exercise to the reader.</p>
Conclusion#</a>
</h2>
This post outlines how to implement undo / redo for a more complex data structure, where it is borderline insane to create a separate Command</code> subclass for each operation. Diffs can be a powerful approach, potentially applicable to a wide range of other applications.</p>
Note that specific optimisations can still be done where the mesh does not change topologically.</p>

    
        
            
            
                ShapeReality - 3D Modeling</p>
                
ShapeReality - 3D Modeling brings 3D polygon mesh modeling tools to your iPhone and iPad. Inspect, edit, save and share .obj files.</p>
            </div>
            
        </div>
    </a>
</div>

ShapeReality - Blog - Posts

Voxels 👾

Simple undo history for a mesh graph using diffs

`ShapeReality - 3D Modeling</p> ShapeReality - 3D Modeling brings 3D polygon mesh modeling tools to your iPhone and iPad. Inspect, edit, save and share .obj files.</p> </div> </div> </a> </div>`

`ShapeReality - 3D Modeling</p> ShapeReality - 3D Modeling brings 3D polygon mesh modeling tools to your iPhone and iPad. Inspect, edit, save and share .obj files.</p> </div> </div> </a> </div>`