Is there an add-on that allows you to return to a previous view?

I understand there is stored view, but you have to manually/consciously create a new save view in order to return to it, it would be like having to consciously remember to click a button to remember the current state or else undo wouldn’t work, that’s stupid.
Is there an undo for viewport navigation as well ?

1 Like

I don’t know of any, but it would be cool. As if we could record every movement and play back and forth in a virtual dedicated timeline

It’s a cool idea, but it would take so much RAM… not to mention all that I/O would slow the depsgraph_update handler down.

You’d need to save view position as a 3D vector of 32 bit numbers, view rotation as a 4D vector, zoom level as a 1D vector, so you’d be looking at 256 bits minimum being read/written every single depsgraph_update. Although you’d need to add a positional indicator to each set of vectors, and storing the vectors will take some extra bits outside of the pure data, so I’d say 384 bits or 48 bytes. You’d hit 1 MB of RAM usage after just 20 depsgraph_updates, and 100 MB after 2,000 depsgraph_updates. That sounds like a lot, but every slight viewport movement or zoom is 1 depsgraph_update. You can easily hit 2,000 depsgraph_updates in 30 seconds (they’re fairly easy to log, and I’ve done some testing there before.) You’d be using a GB of RAM every 5 minutes at that rate.

That isn’t to say that this isn’t technically possible… I just can see why it hasn’t been done

1 Like

what about a timeline with auto-record each let’s say, 1 second*. So the view-movement is a collection of location+rotation keyframes.
If that still takes too much memory the system could work within a timeframe*, where (unless you save a view, as in “stored view”) older keyframes get just forgotten.

*both could be settable

The problem is that 1 second of depsgraph_updates would be barely anything- moving completely between views with different zoom, location, and rotation would be probably 300 or 400 steps back. Scrubbing through those 400 steps would be a massive pain each time.

The obvious solution is not to store every update, just every N number of updates… but then you wouldn’t be able to perfectly recapture a previous view. The actual solution then is to only store the needed updates… what if there was a button you could click to store a view? Oh wait :wink:


yes that’s the idea. consider that the user tipically wants to go back to a view that has actually been “used”, not the precise moment in time while he/she was panning/zooming/rotating to somewhere else. So recording the view state would 99% of the time store the useful view (unless it was too much way back in time and the addon has forgotten it)

I think you’re missing my point - going back to a view that has actually been “used” would require either the user manually defining it as a used view (which is what the Stored Views add-on is for), or… somehow Blender magically recognizing that it was an important point in navigational history. How could Blender pick the “right” despgraph_update out of 5000 other very similar ones? Well, it can’t. So you can either store every navigational update, which will take GBs of RAM, slow down the viewport, and be almost impossible to scrub through, or you can store manually set views, which, again, already exists :slight_smile:

I highly recommend trying Photographer 4… By @chafouin
and it is very affordable !!

There is an older FREE version if you want to check it out…

How does it relates to the thread?

He is talking about a saved view which is a CAMERA function…ie: this will allow you to have AS MANY as you want and always return to them…Now if he is actually wanting something different like returning to a previous modeling STATE …then the question needs to be more precise!

1 Like

Let’s say that I enable this hypotheitical addon. Then, I move around and stop on a view that I’ll use to see my scene. The moment I stay in that view for more than x (set a number) seconds, a new view-state is saved. And so on for an hour of work session. I don’t think it would be GBs of ram. Would it be??
Blender shouldn’t decide or guess which view state are relevant, it would just save those that the user hold for enough time (this makes them maybe relevant).

I tried to whip this add-on up just now, but as it turns out, it’s not possible at all with the BPY API because there’s no handler for viewport navigation updates. That is to say, there’s no way in Blender’s API to < do function > when you navigate the viewport. I thought you could with despgraph_update but you can’t.

So long story short, any memory concern are irrelevant, since there’s no possible way to implement this idea

I did one for 2.79… will try update to 3.x
basically storing view matrix in some scene user propertie list and pop back last stored matrix when calling undo view operator.

*automatically storing view matrix after viewport changes.

View3D Exponent 2.0, add new module “Views Memo”


Linear mode + Fast option, mimic common editor’s undo/redo logic.

View3D Exponent 2.0 add “Views Memo” module - Coding / Released Scripts and Themes - Blender Artists Community


the script should just check viewport camera position every two seconds and if camera didnt change for 6 or 8 seconds (what feels better) , save the backup position … easy imo

You can’t do anything every “n seconds”, running a timer interrupts any interaction or code execution until the timer completes. That is to say, you can’t use Blender while a time.sleep or threading.Timer timer is running. In normal circumstances, you can get around this limitation with multi-threading. This doesn’t work with Blender’s API.

Sure, you could check if N time has elapsed on every depsgraph_update, but again, viewport navigation doesn’t update the dependency graph. Only changes that affect data or modes will trigger a depsgraph_update handler.

ok … could an external mini exe send a callback every 2 seconds ?

Technically yes, you could run an external script on file load that would be an infinite timer. There’s a lot of reasons why this is a very bad idea, though:

  • Blender does not have a “quit” handler that will tell that infinite timer when to stop running. As such, this timer would never stop running.
  • If this was a Python script, it would require the user to have a Python IDE installed and have a Python executable installed
  • The path to the said Python executable would only work if it was in the $PATH- if the user had Python installed in a non-standard way, Blender would immediately crash when trying to run this external script
  • If Blender was closed and the program was still running, the computer would freeze up, pop up some scary-looking errors in the terminal, and possibly crash. This is something to avoid in software development
  • If multiple instances of Blender were running, this timer could only be tied to one of them. Opening multiple Blender instances would cause the new instances, or the computer, to crash
  • If this was a standalone .exe, it would be immediately blocked (running a program from another program automatically is a big no-no for Windows Defender etc)
  • If this was a Python script, it would prevent other instances of Python from running. That’s another huge no-no in terms of things “programs shouldn’t do”
  • Running an infinite timer will still take up CPU resources and threads, and it will absolutely slow everything down

Ultimately, this is a lot of complicated gymnastics for a very simple problem. If you want to store a view, just… store a view with the button :man_shrugging: If that’s not satisfactory, here’s a condensed version of why what is being asked for cannot be done with Blender as it exists currently:

  • You can’t get any handlers or do anything when viewport navigation occurs
  • You can’t check viewport navigation every N seconds internally, and you shouldn’t externally
  • You could save viewport navigation on each depsgraph_update. Doing so will create hundreds of thousands of entries that would be impossible to navigate through, and will use GBs of RAM.
  • You can’t filter those potential entries - the only ways to determine which of those are valuable are with a timer (can’t be done) or with user input (can be done, very easily, with the store views add-on)

Also, I’m not immune to being wrong- if anyone can show me an add-on that runs a constant timer within Blender or has a custom viewport navigation handler, then I’m wrong, and I’m happy to admit it. In my time with Blender and Blender development, I’ve never seen either of these things

No you are right on your first understanding, I literally mean JUST the view, I don’t know how it devolve into modeling “states”.
If this is due to my poor usage of word I apologize to everyone who misunderstood my intention, it’s all on me :smiley:

I think this should work pretty well!
I’m going to be developing this add-on a bit more so if you have any feature requests please let me know.

ReView v0.1.0



  • One click to start automatically saving views
  • Click again to stop saving views
  • Easily browse saved views with 4 buttons (I’m going to add a key-map and a pie menu for this)
    • Next view
    • Previous view
    • First view
    • Last view

How it works

  • When ReView is active, every n seconds, the view is captured
  • If the view is the same as the last check, the view is saved
  • This is because it means the user stayed on that view for a while, and they might want to return
  • The view is also compared with all saved views to prevent duplicates