Recently, I used papervision for a project. I needed to create a carousel like 3D system. Even though I think it would be helpful and interesting to some to write about the carousel, I’m going to focus on the equations this task led me to instead. I think they’ll prove to be very useful to anyone that needs to match design compositions with pixel perfect precision. To really get the most out of this article, you’ll need some papervision experience. Having made a carousel will help too 
At the moment, I’m unable to share any working example of the carousel, but at some point I should be able to post an example.
[Update 10/09/2008: I have adjusted the equations in the article so that they work with the latest of papervision to keep the validity of this article intact. I have modified some semantics, notably screenZ is now just referred to as distance. A link to the updated sample source. This is not different than the one below.]
[Update 08/22/2008: The equations in this article and in the source will only work for builds prior to 639. I am in the process of writing an article about a set of functions that should achieve these effects for versions of papervision after 639. I am leaving this article intact for educational purposes.]
[Update 08/15/2008: sample source - it is not the carousel, but it demonstrates the use of the equations pretty well.]
Great article! Near the end:
“What we do is compute the perspective to apply to an object at such a distance, and then we divide the perspective by 1 to get the inverse ratio of the perspective.”
Did you mean divide 1 by z position to get our perspective ratio? (not divide perspective by 1)
Thanks!
Hey Jim! Yea, actually I did, nice catch. Thanks for the comment!
Thanks
this article was really helpful, my workaround to this was just to show a 2D version of the plane when they zoomed T_T
Hey Jairus,
I’m glad it helped. I actually had to do the same thing for a few reasons:
- Displaying graphics in papervision is a bit blurry
- There was no hand cursor for buttons
- Constantly rendering the scene for interactivity was too expensive
With the precision you get from this technique, it makes the swap literally seamless if you time it right…
Hi,
Great article!
can you release the source code?
Thanks…
Hi Tulio,
I’ll try to. If not I’m planning on writing another article that emphasizes this, but I have a different navigation scheme in mind that I’ve been meaning to try – it’s like a multi axis carousel. I can release the source for that…
The sample file seems to be broken with build 639 and later? The scaling seems to work (gives a perspective of 1 at distance = 1000) but the shape is positioned too far towards whatever edge it is near. This is very pronounced at plane.z = 1000, and very slight at plane.z = 10000. I’ve heard that the following equation no longer needs the “-1″ after build 639, but I’m not sure if it is relevant:
plane.z = ((cam.zoom – 1) * cam.focus) – Math.abs(cam.z)
Any tips?
Hey Mark,
Check out this discussion:
http://www.nabble.com/Re%3A-align-objects-to-camera-or-stage–p19037587.html
I have code posted there that should work with the latest build of paper vision.
I have been real busy this week, but I think this weekend I will have some time to post a new article with the final function.
Thanks a lot for pointing out which build has the change in how perspective is computed. I will make a note of it in this article.
As for -1, I am not familiar with this equation. Though, when I had a look at the source, I saw that focus is not used when computing the difference in z from object to camera during projection. Since zoom is a factor of focus in the equation (cam.zoom – 1) * cam.focus) – Math.abs(cam.z) I can only assume that -1 would serve to cancel out focus since it was a part of the z distance. Since it is no longer used to compute the distance, it is no longer needed.
That sounds amazing, I’m excited to see the final function (as I’ve been trying to figure it out for a week and it’s wayyy beyond me apparently). Thanks for sharing your amazing work, I really appreciate it. *bookmarked, checking daily*
provide more samples codes (papervison)
I know this is a really old thread and chances are nobody checks it anymore but I was wondering how I would modify this to get it to work on planes which are children of other planes. This works great when the child is a direct descendant of the viewport but not once it is reparented. I thought first that adjusting the calculations so that it takes into account the containing plane width and height as opposed to the viewport but I am getting odd results.
Any help would be much appreciated…
Thanks
Hey Matt,
Let’s call the parent of the target element the “branch element” and the actual target element the “leaf element.” We will also refer to the viewport as the “root.”
The branch element’s transform must be recalculated relative to the root’s transform. The leaf element’s transform must be recalculated relative to the branch element’s transform. Perhaps there are multiple leaf elements that we want to leave unchanged. One solution is to apply the calculations that would occur between the root and branch element to the leaf element, as well as the branch and leaf element calculations. In this scenario, we take two passes to compute the target leaf element’s transform, one with the root and branch element’s transforms, and one with the branch and *the original* target leaf element’s transform.
Sample algorithm:
Create a copy of the target leaf element’s transform.
Apply root to branch calculations to the copied transform.
Apply branch to leaf calculations using the original leaf element’s transform to the copied transform.
Set the target leaf element’s transform to the copied transform.
Force render if needed.
Hope this helps,
Melih