Hello
@KeplerDD and welcome to the forum!
It seems like you're somehow mixing up several (very different) concepts, namely:
1. Visualization (which is done by VTK in your case).
2. Undo/redo which is application-specific and basically not related to neither modeling nor visualization.
3. History of modification, which is not related to undoing, redoing, or visualization.
OCC published their training materials in PDFs here:
https://dev.opencascade.org/resources/trainings
My initial idea was to propose you to follow these documents in a kind of "self-training" mode to grasp the principal architectural concepts of the library. Would that make sense to you?
As per undo/redo, different people implement such tools in different ways. My guess is that the vast majority of C++ developers who are messing around with OpenCascade would prefer implementing the undo/redo stack by themselves, relying on their general programming and architectural skills (as this task is not related to neither geometry nor modeling). If you handle an undo/redo stack in your app, what you need from a B-rep shape is just to store its current and previous states, and this can be done without any history of modification. The history of modification is another concept not related to undo/redo directly. Usually, the history of modification is an integral part of a modeling API function whose purpose is to tell you what happened to the specific shape elements (faces, edges, and vertices) upon completion of a modeling function. E.g., when you extrude a prism from a planar sketch, the history of modification will tell you which face was generated from which edge. To arrange the modeled data in an undo/redo stack, you would not need any a history like that. You would rather store the initial sketch as the first state (T0) and then push back the extruded prism as the second state (T1); both states (stack elements) would store the shapes that know nothing about each other. Once you undo changes, you just rollback to the previous state in the stack. If you continue modeling and drill some holes in the extruded prism (as an example), you do it with a Boolean cut and store its result in the stack's T2 state. There is no need to trace the history of modification per shape again, although the Boolean operation can, indeed tell you which faces were affected by the hole drilling process. The question is whether you really need this information.
As all these undoing and redoing functions are standard in desktop CAD applications, the developers of geometric kernels tried to ease your life and added some services around the math core to give you the undo/redo stack preimplemented. In OpenCascade, it is a part of OCAF transactions. In ACIS, I believe it is RADF (rapid application development framework). In Parasolid, it is something else.
I'm not sure if this message answers any of your questions, but I felt like you needed some intro before you dive into the technical details. Maybe if you elaborate on what you're trying to achieve it would be easier to assist.
