Ok I think we have some options here, but it really depends on exactly how you want your application to work. Ever since we started this conversation I have been thinking about using subpanels. You can insert a VI in the subpanel, and then remove it later. So you could create a VI that all it has on the panel is the 3d control. So you put a sub panel on the main VIs panel and then insert that vi in the panel. When you want to pop up the big display we simple remove the VI from the sub panel and then popup the VI. There is actually only 1 3D graph, and therefore no copies. However, in this case when the copy/large view is up there will not be a graph on the main VIs panel.
Another route that may work out really well is to use a single element Queue. The appraoch may be too complex for the application, but it can be a really nice way to hold the data as a 3 element cluster. Basically you would create a Queue with a size of 1 and everytime you want to change the data you de-queue the data, then you bundle the new data and enqueue it. This takes advantage of how labview handles Queues and clusters. You should not have too many copies here. The only other part this needs is that the Graph itself would need to know when to update. Depending on how you impliment it you can simply call a vi to draw it, or you could send a notification or any number of ways. It really depends on if you are using subpanels etc.
As a side note and I know I am throwing a lot at you, I would lean away from using parrellel case structures like you are. There is a chance that the user hits 2 of the booleans fast enough that they are both processed. This could lead to some very strange behavior in your vi. I would suggest looking at some of the state machine examples and the event structure examples to clean up the code. We can look at that route also if you need help.
