Hi Friends,
I'm taking another stab at learning how to use the 3D box tool. At one point, I had the vanishing points so messed up, that I couldn't make sense of the boxes I drew. Now I have them set like this: Angle X: 30, Angle Y: 90, Angle Z: 30, with only Angle Y engaged (infinity), and it does draw recognizable 3D boxes (I had asked a year or 2 ago if there was a default configuration, but apparently not.) And this is all with 0.48.1 on Windows 7, 64-bit.

So this time, I read the manual, to make sure I understand everything from the beginning (or at least try to understand). The manual says this:

By default, a box is drawn with two vanishing points, one each on the left (x) and right (z) sides. The vanishing points are initially placed at the edge of the page, halfway between the top and bottom. These points are determined when the SVG drawing is first created so resizing the page does not move them.

(

All boxes that share the same vanishing points will change together. If you wish to change the vanishing points of just selected boxes, hold down the Shift while dragging. If multiple boxes are selected with different vanishing points, dragging a vanishing point for one box near that of another box will “merge” the points together.

I've tried selecting 2 3D boxes, then hold Shift and drag one VP towards another. I don't know if "..."merge" the points..." is supposed to mean ""snap" the points". But they in fact do not snap....unless there's an obscure snapping rule that I'm not aware of (so that I don't have the proper settings on snap control bar). Oh wait....I see, you have to get them really, really close. And apparently, once "merged", they do not unmerge, except by moving one of the boxes! I actually noticed the same thing with gradient handles the other day. Very frustrating if you don't want them merged! But that's another story.

Ok, that's all my questions. Thanks for your help

Did u have a question?

brynn wrote:..... So first question: I'm curious why they are placed according to a page size that's not used by this document. (Maybe a bug that's been fixed by now?)
2nd question: Why would resizing the page change the vanishing points' positions? ....
.... 3rd question: Is that because precision of the vanishing point is not typically needed? ....

Sorry, I guess I answered my 4th and last question myself. But still don't understand the other 3. Thanks

brynn wrote:So first question: I'm curious why they are placed according to a page size that's not used by this document.

In your prefs is it set to ''persp="perspective2984"? it is in mine. I am not sure where else to find any saved settings, but .. Try setting them to where you want them and then deleting everything, vacuuming defs and resaving it as your default document or you could open your default doc and see if there is a defs for the perspective - there isn't in mine.... You know how to do that, right?

brynn wrote:I notice that the vanishing points don't snap to a grid

I just tried it, and in 0.48, no snaps, but in a recent development build, I can snap the handles to everything in sight. I even snapped them to my cat all the way across the room (she's not happy about that). I know you don't like to use dev builds because they're 'unstable' (meaning I guess you can snap in them and not in stable versions) so you are out of luck.

Yes, I know how to find the prefs file.....assuming you mean preferences.xml. Mine says

I don't especially want to change or "fix" it, I just wanted to know if it's a bug, or expected behavior, or somehow related to my custom default doc (although it would appear not to be related to custom default doc....but then what do I know -- that's why I'm asking).

Oh, nice to know that snapping will be available at some foreseen point! Thanks for testing

It's not so much the instability that keeps me from using a dev version, although that's part of it. Mostly I need to stick with something I can reasonably expect to know how to deal with, if problems come up. Problems seem to come up quite often (for me) in the "stable" builds, so I would probably not enjoy using a dev version, and risk causing my system harm if I react the wrong way to potential previously never-before-experienced problems.

Meanwhile, another question has arisen with the 3D Box. It appears that each of the 6 sides are already paths (grouped paths) when the box is drawn. I'm curious why the 3D Box doesn't behave like all the other shapes, in that it doesn't need to be converted to a path. I'm surprised about this, because in my mind, the quality that makes shapes shapes, is that they are not paths. Now it seems that there must be some other quality about shapes that causes them to be shapes. If there's a simple answer, how are the shape tools defined, or described. If it's not a simple answer, then don't answer, and I will know it's too technical for me to understand

Thanks again

brynn wrote:Yes, I know how to find the prefs file

Sorry, I wasn't asking if you could find it! I was asking if you could

druban wrote:Try setting them to where you want them and then deleting everything, vacuuming defs and resaving it as your default document

Why do you not want to try this?
I am guessing the reason you are having the problem is that your default doc has the A4 defs for perspective, which, when you set up your letter size landscape default file, you forgot to vacuum out of there. Now unless you remove the def for perspective entirely you have a mismatch. If you are too worried why don't you make a copy of the default file and stash it somewhere and then try it, this is standard practice, really.
This might be a bug in some version, but as far as I can tell it's just because you left the A4 defs in your default.
Let me try to explain it this way:
If there are NO defs in your Default.svg Inkscape will look at the page size and create the right one as soon as you call the tool. If you switch page sizes during use Inkscape will REWRITE the defs (you might need to vacuum first.. but I didn't). If you empty the file of all objects and then vacuum defs it should clear it out of that file, but as soon as you start Inkscape again the wrong defs will be loaded. Again. It's what the default file is for! I could send you the code for the right defs but I don't see what good that would do! Well, good luck.

brynn wrote:risk causing my system harm if I react the wrong way to potential previously never-before-experienced problems

This is not really the difference between stable and unstable... if your system is fragile it doesn't matter if 0.48.2 or 0.49 rxxxx crashes, as far as your system is concerned it's still a crash... or just a crash... IMO every time you get on the Internet you are putting your system at more risk than when Inkscape crashes.

brynn wrote:...the quality that makes shapes shapes, is that they are not paths

Shapes are defined in the SVG specs but a 3D box is not, therefore only editable in inkscape, sort of like layers...

Thanks druban

brynn wrote: And apparently, once "merged", they do not unmerge, except by moving one of the boxes! I actually noticed the same thing with gradient handles the other day. Very frustrating if you don't want them merged! But that's another story.

When it comes to gradient handles, you can separate them by holding SHIFT while you drag the stop. According to the status bar, the same should happen with vanishing points, but it doesn't seem to work on my installation.