# Restoring scene view duplicates scene heirarchy

**URL:** <https://discourse.slicer.org/t/restoring-scene-view-duplicates-scene-heirarchy/22025>\
**Category:** Development\
**Created:** [February 17, 2022, 3:46pm UTC](https://discourse.slicer.org/t/restoring-scene-view-duplicates-scene-heirarchy/22025 "2022-02-17T15:46:59Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![hherhold](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/hherhold/32/12199_2.png) [@hherhold](https://discourse.slicer.org/u/hherhold)\
**Post date:** [February 17, 2022, 3:46pm UTC](https://discourse.slicer.org/t/restoring-scene-view-duplicates-scene-heirarchy/22025/1 "2022-02-17T15:46:59Z")

</div>

This harkens back to a number of discussions from months past on Scene Views, which I haven’t used in quite a while (and now I’m remembering some of the reasons why). One of the discussions linked below.

So right now, when I capture a scene view and later restore it, things _appear_ to be okay. But when I check the Data module, restoring the scene view basically duplicates everything in the scene. Subsequent restores make yet another copy, and another.

As nobody’s really talked about scene views in quite some time, maybe it should be deprecated if it’s not going to be worked on?

Link to one of the old discussions:

> [@What scene views are supposed to do?](https://discourse.slicer.org/t/what-scene-views-are-supposed-to-do/497):
>
> We experienced many problems related to scene views, seen many workarounds in many places in the code, and there are many open issues caused by or related to scene views. The main problem seems to be that it is unclear what information scene views should store and restore. Should it be enough for scene views to store display information of nodes, view layout, view settings, and camera settings? If that’s true, we could simplify the scene view implementation a lot, because we would not need to…

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [February 17, 2022, 5:29pm UTC](https://discourse.slicer.org/t/restoring-scene-view-duplicates-scene-heirarchy/22025/2 "2022-02-17T17:29:24Z")

</div>

I think that discussion from 5 years ago is basically still up to date. Which is to say, yes, the feature is weird and unreliable. I’d be happy to see it gone or replaced with something much simpler.

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [February 17, 2022, 5:56pm UTC](https://discourse.slicer.org/t/restoring-scene-view-duplicates-scene-heirarchy/22025/3 "2022-02-17T17:56:45Z")

</div>

It is not very useful as is, so it can be axed. But a functionality to recover camera positions, light settings, etc is needed. Your suggestion to save the states as mrml files is not a very practical one, as in situations like @hherhold you might be making dozen figure plates and keeping them all separate mrml files will be too much a confusion.

So, maybe it is time to have that conversation about what can replace that?

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [February 18, 2022, 4:23am UTC](https://discourse.slicer.org/t/restoring-scene-view-duplicates-scene-heirarchy/22025/4 "2022-02-18T04:23:32Z")

</div>

> [@muratmaga](#):
>
> It is not very useful as is, so it can be axed.

It is very useful feature and it can be fixed with today’s Slicer infrastructure much more easily than years ago. We could save display nodes (and camera and slice nodes, maybe the layout node) to sequence nodes, essentially automating the manual workflow that I showed [here](https://discourse.slicer.org/t/new-feature-basic-support-for-physically-based-rendering-pbr/21725/17).