Note: I have also begun to explore the use of "volumetric light" for the bars - a short note about it is at http://www.nowherenearithaca.com/2015/08/experiment-using-volumetric-light-in.html.
The sample interactive three.js/webgl visualization using this the method discussed here is at https://learnforeverlearn.com/splitdepth/.
Animated gifs made from the three.js visualization are included below.
Last January, there was a lot of buzz about a weird technique that could make animated gif's more "3D like". The effect is pretty remarkable.
I was wondering about exploring using this same effect in interactive three.js 3D visualizations (which is a new area for me).
It turns out that it seems to be pretty simple to implement in three.js.
This might provide some additional ways to improve the user experience when working with 3D visualizations and the associated hard-to-avoid clutter.
After looking a some of the animated gifs using the technique, I realized that all we need to do is have the "bars" or whatever be located at a fixed distance from the current camera - the machinery of three.js/webgl does the rest.
(interactive example, available at https://learnforeverlearn.com/splitdepth/,
is based on the "Cube Reflection" Three.js Demo)
I can definitely "feel" the difference between the two examples above. It is preattentive: we can detect it effortlessly and almost instantaneously (N.B. I put together this page for interactively exploring set preattentive processing).
What is more interesting is the optimization of these techniques, which are certainly context-specific. For example, how many bars are needed and how wide should they be? How does the size of the frame/border impact the effect? Does a slight transparency of the bars/frame help?
I could certainly see enabling this feature when you are trying to focus on one aspect of a visualization - the bars provide a slight "jumping out" illusion that makes for a more effective experience. One could adjust the distance between the bars/border and the camera, transparency, and whatever else that makes sense in a given context.
There are many more avenues to explore here.
After defining the rectangles and basic material for the bars/borders (with width a parameterizable fraction of the "near" plane of the camera frustum), on every animation update we update each bar/border by moving each bar to its proper spot in the plane that is a fraction alpha from the camera's current near and far planes, and make sure it is pointing at what the camera itself is looking at.
The net effect is that the bars/border do not appear to "move" when we move the camera around (although there are some slight artifacts, I have noticed), and the bars/borders automatically and satisfyingly interact with the objects in the scene.