SEANT Posted August 22, 2013 Share Posted August 22, 2013 The issue was familiar. It was the root cause of the problems described in these two threads. http://www.cadtutor.net/forum/showthread.php?11995-PLEASE!-Rendering-problem-in-3D-orbit http://www.cadtutor.net/forum/showthread.php?26725-rendering-issues.... Quote Link to comment Share on other sites More sharing options...
Marvin7 Posted August 22, 2013 Author Share Posted August 22, 2013 The cause of the stutter in the "testing shaky orbit bug.dwg" can be found by opening the View Manager (_view). The current view has the Camera and Target set about 256 million feet from the solid. The actual Unit setting for that drawing is in Inches, so the camera/target is actually over 3 billion units away. Thanks, it's satisfying to have a better understanding of the problem. I don't ever use DVIEW or CAMERA. In fact, with respect to my view location, I'd say I use the viewcube, 3DORBIT, mouse scroll wheel zoom in/out & double-click zoom extents exclusively...only the basics. Not to get too ponderous, but an interesting thing is that _VIEW reports the camera and target as ~100 million feet for x,y,&z, yet a simple _ID command reports the cylinder is at ~100ft x,y,&z. It doesn't take an AutoCAD expert to know that if the camera is, for all intents and purposes, about 100 million feet from the cylinder (regardless of what the viewing angle vector is), you'd never be able to see the cylinder because it would be like looking at the soda can on my desk from outer space. What this may suggest is that AutoCAD thinks the camera is at 100 million feet out for the purposes of setting a pivot point, for example, but for the purposes of display it's at a normal distance, and that mismatch is causing a problem. Quote Link to comment Share on other sites More sharing options...
SEANT Posted August 22, 2013 Share Posted August 22, 2013 I couldn’t say how the camera got to that location. I would be surprised if it were placed there by a user. It would require some effort to get it that far removed – even just typing the numbers in would be rather tedious. Parallel Views do not modify geometry based on distance. The Plan view of a 10 by 10 square will appears the same if it is on the XY plane or 100 feet in the positive Z. Parallel views make it easy to keep things aligned. If we start the Orbit command on the file from post #6 we see that the current view is Parallel, if we change it to Perspective, the cylinder vanishes. Quote Link to comment Share on other sites More sharing options...
Marvin7 Posted August 23, 2013 Author Share Posted August 23, 2013 Parallel Views do not modify geometry based on distance. The Plan view of a 10 by 10 square will appears the same if it is on the XY plane or 100 feet in the positive Z. Parallel views make it easy to keep things aligned. If we start the Orbit command on the file from post #6 we see that the current view is Parallel, if we change it to Perspective, the cylinder vanishes. Parallel views do modify geometry based on distance in one way...overall size...every time you zoom in or out, for example. In parallel, the plan view of a 10 by 10 square will appear different if the camera is 100million feet from the square than if it is 100'...specifically, the square will appear smaller (so small you won't be able to see it, actually). The reason the cylinder vanishes when changing to perspective is likely because the bug is being corrected, which is to say that changing to parallel would also yield a cylinder too small to see. Quote Link to comment Share on other sites More sharing options...
ReMark Posted August 23, 2013 Share Posted August 23, 2013 Why would you refer to it as a bug? While the behavior is unexpected it is not a result of a flaw in the program itself in my opinion. Quote Link to comment Share on other sites More sharing options...
SEANT Posted August 23, 2013 Share Posted August 23, 2013 I’m not going to get into it too deep for this particular post because, as it appears from previous remarks, the problem has been solved. I will point out that the term “zoom” for a parallel view is a bit of a misnomer. When we use the Zoom command while in parallel view, we are actually just scaling the view. No camera displacement is involved. We're not even changing the Focal Length as it is perpetually set to infinite. I don’t think the issue is really that important, at least not such that proof is required. If I’m wrong I think I can set up a file do demonstrate the concept I’m describing. Quote Link to comment Share on other sites More sharing options...
ReMark Posted August 23, 2013 Share Posted August 23, 2013 I wasn't trying to start an argument so if it seemed that way I apologize. I just don't see it as being a bug in the program. Sometimes a program acts strangely simply because the user (that includes me) does something unexpected and the program can't make sense of it. I'll stop now. This thread was very informative thanks to your input SEANT. Your explanations are always to the point. Quote Link to comment Share on other sites More sharing options...
Marvin7 Posted August 23, 2013 Author Share Posted August 23, 2013 I’m not going to get into it too deep for this particular post because, as it appears from previous remarks, the problem has been solved. Just to clarify, I'm happy with the workaround, thanks to our sleuthing. If the problem was truly solved, I wouldn't need to keep a workaround in my back pocket for the next time this randomly happens. I will point out that the term “zoom” for a parallel view is a bit of a misnomer. When we use the Zoom command while in parallel view, we are actually just scaling the view. No camera displacement is involved. We're not even changing the Focal Length as it is perpetually set to infinite. .... If I’m wrong I think I can set up a file do demonstrate the concept I’m describing. You can try it on my "testing shaky orbit bug.dwg" file. Open the file, then switch to Perspective and back to Parallel. Set the origin of the UCS to the cylinder. Now do VIEW and note the x,y,z-coordinates of the camera. Then zoom out and do VIEW again. Then zoom way out and do VIEW again. You'll notice the x,y,z of the camera changes as you zoom out. Specifically, the x,y,z values get extremely large when you zoom way out. The camera placement actually changes...at least according to AutoCAD's own nomenclature. Now, if you open a new acad.dwg from template and do the same experiment with parallel, the camera location, as reported by VIEW, never changes...just like you said. So it appears that we're both right, depending on the drawing a person is currently in. Just so you know, I tried it myself on my drawing before I posted that last response, so I wasn't just shooting from the hip. After your reply today, I decided to investigate further and see if you could be right too, and that's when I tried it on the template drawing. Quote Link to comment Share on other sites More sharing options...
SEANT Posted August 24, 2013 Share Posted August 24, 2013 Well, there you have it. It appears that AutoCAD sets a flag as soon as the Perspective option is employed. At that point the camera can be sent god know where by standard zoom operations, whether perspective is still on or not. Just a quick investigation - the only way I’ve gotten back to the standard Parallel View behavior is to explicitly set the Camera and Target points via the DVIEW command. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.