Hi everyone!
Good news! 3D box coding finally has had a new visible effect: Boxes are now resizable 'in perspective'. The current version by default provides three handles for each box, two on the front face (which we consider lying in XY plane) and one on the rear face (for the Z direcion). (As a sidenote, observe that the labelling of the Y and Z axis has been changed compared to the last version.)
The first two handles can be used to arbitrarily resize the box inside the XY-plane, the third one obviously resizes it in the direction of the Z axis. When Shift is being pressed, the movement temporarily becomes constrained to a single axis for the first two handles and switches to occuring inside the XY plane for the third handle. (Try it, this is more intuitive than it sounds.)
However, this is only one of many possible scenarios. As an alternative, I have implemented a second variant where the box has four handles and all but the circle-shaped one (which acts as a kind of 'master handle') use constrained dragging by default.
It is possible to switch between these two variants using the corresponding toggle buttons in the 3D box toolbar showing three/four knots, respectively. These buttons are for convenience only and will disappear once the definitive behaviour is settled.
I would very much appreciate your feedback what kind of behaviour you consider most intuitive. This could certainly also be a mixture of the two, or there could be a different number of handles, or they could be at different corners, or ... Tell me what you think is most natural. (It probably depends on the perspective, too; try toggling the states of the vanishing points from infinite to finite using the corresponding buttons and see whether this makes a difference). BTW, the 3D box tool now has the shortcuts Shift-F4 and X so that it's not necessary to manually change line #143 in widgets/toolbox.cpp to unhide the toolbox icon.
In case you are wondering why this new feature has taken so long since my last email: I have constantly been refactoring the code under the hood because it was extremely cumbersome at that time, making expansion and implementation of new features rather difficult. But I believe that the current internal representation is sufficiently elegant and generic so that further development should be much quicker (and with a lot more visible effects anyway).
Next I am going to attack the style issues Bulia mentioned in one of his last emails (sorry that this has lied idle in the meantime). Alternatively, I could implement draggable vanishing points first. Bulia, what do you think is more important?
Thanks for all your feedback and best regards, Max
====
P.S.: While I am at it I'd also like to pose a few questions regarding small bugs that can possibly spare me a good deal of scouring the code. Maybe someone has a quick hint where to look.
1) After resizing the box, undo (Ctrl-Z) correctly undoes the change of size but the corresponding handle remains at the altered position. How can I make the handle undo-aware, too?
2) Toggling the state of a vanishing point is not undo-able either. How can I change that? Do I need to register the corresponding action somewhere?
3) With the 3D box tool active, clicking on an already created but currently unselected box only selects a single face instead of the whole box. I suspect this is related to the fact that the box is implemented as a group of paths (which represent the separate faces). How can I pass the click on to the parent box? Can this be done by tagging the paths as objects of sodipodi:type="inkscape:3dboxface" (which I would have to do for the style stuff anyway) and catching the select action?
Thanks!
On 7/4/07, Maximilian Albert <Anhalter42@...173...> wrote:
The first two handles can be used to arbitrarily resize the box inside the XY-plane, the third one obviously resizes it in the direction of the Z axis. When Shift is being pressed, the movement temporarily becomes constrained to a single axis for the first two handles and switches to occuring inside the XY plane for the third handle. (Try it, this is more intuitive than it sounds.)
Thatnks, it's very cool to play with!
It is possible to switch between these two variants using the corresponding toggle buttons in the 3D box toolbar showing three/four knots, respectively. These buttons are for convenience only and will disappear once the definitive behaviour is settled.
OK, I'll try both and let you know what I think on this...
Next I am going to attack the style issues Bulia mentioned in one of his last emails (sorry that this has lied idle in the meantime). Alternatively, I could implement draggable vanishing points first. Bulia, what do you think is more important?
Whatever itches you most :)
Some more things:
Apart from the shape of the sides' paths, the 3Dbox must also control the z-order of these paths in the group. Depending on which way the box is turned, the 3 sides that face the viewer must be on top of the z-order and the 3 others must be at bottom. If I "rotate" the box by dragging vanishing points, this must be adjusted accordingly.
Your tool cannot select its own 3d box because it, like most other tools, disregards groups (i.e. enters groups) on click, including its own 3d box groups. Fix this in the click handler of the tool.
Also your tool somehow eats middle-button drags, so panning and shift-middle-button zooming do not work (try them in other tools).
- After resizing the box, undo (Ctrl-Z) correctly undoes the change of
size but the corresponding handle remains at the altered position. How can I make the handle undo-aware, too?
You need to register a listener for your box. See for example how it's done in rect-context.cpp. When selection changes, it destroys old knotholder; if the new selection contains a rect, it creates new knotholder and adds listener with ec_shape_repr_events. That listener responds to the attribute changed event (which may be caused by undo, among other things) and calls ec_shape_event_attr_changed which updates the knotholder. Note however that you can only listen one repr, i.e. either the group or any one side, so for this to work on the entire box, you need to watch the root <g> but also you need to change some attribute on it whenever you change your box (and not only change the sides), otherwise the listener won't fire. For example, add some attribute on <g> which in condensed form records the 3D position/dimensions of the entire box. This may later prove helpful in other situations too.
- Toggling the state of a vanishing point is not undo-able either. How
can I change that? Do I need to register the corresponding action somewhere?
Does this change any repr in the document? If it does not you cannot undo it - the undo system is only for changes in the document, not in the UI. And of course don't forget to do sp_document_done whenever you are finished with some document change.
- With the 3D box tool active, clicking on an already created but
currently unselected box only selects a single face instead of the whole box.
See above, just change one argument in your sp_event_context_find_item call.
bulia byak wrote:
Apart from the shape of the sides' paths, the 3Dbox must also control the z-order of these paths in the group. Depending on which way the box is turned, the 3 sides that face the viewer must be on top of the z-order and the 3 others must be at bottom. If I "rotate" the box by dragging vanishing points, this must be adjusted accordingly.
This issue makes a question arise. As suggested by you in a previous email, I have assigned different default styles to the faces of a 3D box. Currently this looks acceptable because parallel faces are next to each other with regard to z-order. But this is not "correct", since the three rear faces are not at the bottom. If you manually change the order, however, the box looks very funny because almost every edge has a different color. I am not sure what would be the best way to overcome this problem. Any suggestions?
Regarding the general process of determining the "correct" z-orders of the faces, it shouldn't be a problem when all the vanishing points have "finite" state because then it's easy to determine which of two faces is "further away" from a vanishing point. But in case some (or all) of the vanishing points lie at infinity there is no way to decide which of two parallel (say) faces is "in front of" the other - both possibilities are equally acceptable, they only result in different visual perceptions of the same perspective. Should we therefore provide an option (maybe in form of a button for each axis direction in the toolbar) to let the user switch between them?
Thanks, Max
On 7/10/07, Maximilian Albert <Anhalter42@...173...> wrote:
Apart from the shape of the sides' paths, the 3Dbox must also control the z-order of these paths in the group. Depending on which way the box is turned, the 3 sides that face the viewer must be on top of the z-order and the 3 others must be at bottom. If I "rotate" the box by dragging vanishing points, this must be adjusted accordingly.
This issue makes a question arise. As suggested by you in a previous email, I have assigned different default styles to the faces of a 3D box. Currently this looks acceptable because parallel faces are next to each other with regard to z-order. But this is not "correct", since the three rear faces are not at the bottom. If you manually change the order, however, the box looks very funny because almost every edge has a different color. I am not sure what would be the best way to overcome this problem. Any suggestions?
If by edge you mean stroke, then just make the default box styles without any stroke at all. Then the three or four closest-to-view sides will completely obscure the others (except for small antialiasing fringe which is not a problem). If the user assigns stroke and it looks funny - well, we cannot do anything about it, because the concept of stroke simply does not fit too well with 3D. Avoid strokes when you go into the third dimension :)
Currently however, in SVN I do not see three different styles of the three visible sides - they are all the same blue. They should use different shades of blue or gray by default. Also the z-order of the sides is still wrong, and the styles of the sides that I change are not used for new boxes. (I know you're still working on that, just mentioning so it's not forgotten :)
Regarding the general process of determining the "correct" z-orders of the faces, it shouldn't be a problem when all the vanishing points have "finite" state because then it's easy to determine which of two faces is "further away" from a vanishing point. But in case some (or all) of the vanishing points lie at infinity there is no way to decide which of two parallel (say) faces is "in front of" the other - both possibilities are equally acceptable, they only result in different visual perceptions of the same perspective. Should we therefore provide an option (maybe in form of a button for each axis direction in the toolbar) to let the user switch between them?
That's a good point. Indeed I think it will be useful to have a "3D flip" button on the toolbar. And no, it will be useful not only for infinite-VP perspectives. It's just that with finite VPs, it will be interpreted differently: not as rotating of the box (which would then have a wrong perspective), but as converting a box into a hollow structure similar to three walls of a room with other walls removed, in the same perspective as the box. This button would work by swapping the z-order of the three lower sides and three upper (closer to view) sides, taken as groups.
On 7/11/07, bulia byak <buliabyak@...400...> wrote:
That's a good point. Indeed I think it will be useful to have a "3D flip" button on the toolbar. And no, it will be useful not only for infinite-VP perspectives. It's just that with finite VPs, it will be interpreted differently: not as rotating of the box (which would then have a wrong perspective), but as converting a box into a hollow structure similar to three walls of a room with other walls removed, in the same perspective as the box. This button would work by swapping the z-order of the three lower sides and three upper (closer to view) sides, taken as groups.
And this flipped state should be stored in the box as some attribute, so that it's not lost when you edit the box in 3D.
On 7/4/07, Maximilian Albert <Anhalter42@...173...> wrote:
However, this is only one of many possible scenarios. As an alternative, I have implemented a second variant where the box has four handles and all but the circle-shaped one (which acts as a kind of 'master handle') use constrained dragging by default.
I like the first one better. But it's still not ideal. Ideally, I'd like to have a handle in each corner, and have these handles as little constrained as possible (I understand they cannot be absolutely unconstrained or it will be ambiguous, but we need to find some logical compromise).
Some more comments:
You need to implement a _description method for your SPObject so that the statusbar says correctly what kind of object this is (now it just says "Group").
Shift+mousedrag in the 3d tool crashes.
Duplicating a 3D box works, but the handles of the resulting box are in some random position, and dragging them crashes.
Please update doc/keys.xml with the new tool's shortcuts (including shortcuts inside the tool, for which you'll need to add a new section)
What am I missing here? I just updated SVN, uncommented the line to show the 3D box tool and rebuilt. But I can't seem to figure out how to get the tool to do anything other than draw an axis aligned rectangle.
--bb
On 7/5/07, bulia byak <buliabyak@...400...> wrote:
On 7/4/07, Maximilian Albert <Anhalter42@...173...> wrote:
However, this is only one of many possible scenarios. As an alternative, I have implemented a second variant where the box has four handles and all but the circle-shaped one (which acts as a kind of 'master handle') use constrained dragging by default.
I like the first one better. But it's still not ideal. Ideally, I'd like to have a handle in each corner, and have these handles as little constrained as possible (I understand they cannot be absolutely unconstrained or it will be ambiguous, but we need to find some logical compromise).
Some more comments:
You need to implement a _description method for your SPObject so that the statusbar says correctly what kind of object this is (now it just says "Group").
Shift+mousedrag in the 3d tool crashes.
Duplicating a 3D box works, but the handles of the resulting box are in some random position, and dragging them crashes.
Please update doc/keys.xml with the new tool's shortcuts (including shortcuts inside the tool, for which you'll need to add a new section)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Bill,
What am I missing here? I just updated SVN, uncommented the line to show the 3D box tool and rebuilt.
If it's too unconvenient to manually uncomment the line you can just press X or Shift-F4 to activate the tool (although then the icon in the toolbox won't be visible, of course).
But I can't seem to figure out how to get the tool to do anything other than draw an axis aligned rectangle.
Check out
http://www.rzuser.uni-heidelberg.de/~malbert/core_functionality.shtml
for a description of the envisaged behaviour of the tool (paragraph #1 explains how to create a box). Note that each 3D box is associated with a certain 'perspective', which is given by the positions/directions of the three vanishing points (VPs) together with their respective states (which in turn can be 'infinite' or 'finite', meaning that perspective lines in the direction of the VPs are either parallel or meet in the VP).
Currently VPs are not draggable yet, thus an initial fixed perspective is created in box3d-context.cpp, lines 120-132. For each VP both a location on the canvas and a direction is specified. These determine the behaviour of perspective lines towards this VP for each of the states 'finite'/'infinite'.
Notice that the directions specified in box3d-context.cpp for the VPs in X- and Y-direction are 'left' and 'up', respectively, and that their states are both VP_INFINITE. That's why opposite sides of the rectangle you create are parallel (i.e. don't meet in a finite VP) and axis-aligned. You can play with different directions or initial states for the VPs to observe the effect this has (unfortunately, this needs recompiling because the perspective is hard-coded at the moment).
Now the axis aligned rectangle you see only represents one face of the box. To extrude the box and make it appear 3D, press Shift once the front face is created (but keep holding the mouse button). This fixes the front face and starts dragging the remaining faces in Z direction.
As I said, the initial states of all three VPs are 'infinite'. But when you activate the 3D box tool you will observe three small unfilled squares on the canvas. These indicate the positions of the VPs if their state would be 'finite'. Although at the current stage VPs are not draggable, it is possible to toggle their states by pressing the buttons in the 3D box toolbar (they are rather easy to overlook; each one simply shows two parallel lines, but the tooltips should be more meaningful). When the state is toggled to 'finite', the square representing the VP is color-filled and corresponding edges of newly created boxes are now drawn along perspective lines meeting in that VP. Toggling it back to 'infinite' unfills the square and draws edges parallel again. I know that it's rather unintuitive to have the squares for the VPs shown on the canvas but boxes ignore them when they are white. But since the VP-machinery needs to be rewritten anyway (very soon hopefully), I didn't want to invest a lot of time to make static VPs work more beautifully.
I hope this makes things a bit clearer. Don't hesitate to ask if something still remains cryptic. And your feedback is very welcome.
Best regards, Max
Ok. Thanks for the explanation. That shift thing is very unintuitive. Hopefully you will get rid of that in favor of something that can be changed any time by dragging a handle or changing a "thickness" setting in the toolbar.
More generally I guess I still don't get why you'd want to have a 3D box tool. It's basically an extrusion tool that happens to only extrude rectangles. Why not make something that's capable of extruding anything and applying a perspective transform to it? Like the question that was on the list earlier today -- about extruding fonts. This would be a useful tool for doing that, if it weren't restricted to extruding only rectangles.
--bb
On 7/5/07, Maximilian Albert <Anhalter42@...173...> wrote:
Hi Bill,
What am I missing here? I just updated SVN, uncommented the line to
show
the 3D box tool and rebuilt.
If it's too unconvenient to manually uncomment the line you can just press X or Shift-F4 to activate the tool (although then the icon in the toolbox won't be visible, of course).
But I can't seem to figure out how to get the tool to do anything other than draw an axis aligned rectangle.
Check out
http://www.rzuser.uni-heidelberg.de/~malbert/core_functionality.shtml
for a description of the envisaged behaviour of the tool (paragraph #1 explains how to create a box). Note that each 3D box is associated with a certain 'perspective', which is given by the positions/directions of the three vanishing points (VPs) together with their respective states (which in turn can be 'infinite' or 'finite', meaning that perspective lines in the direction of the VPs are either parallel or meet in the VP).
Currently VPs are not draggable yet, thus an initial fixed perspective is created in box3d-context.cpp, lines 120-132. For each VP both a location on the canvas and a direction is specified. These determine the behaviour of perspective lines towards this VP for each of the states 'finite'/'infinite'.
Notice that the directions specified in box3d-context.cpp for the VPs in X- and Y-direction are 'left' and 'up', respectively, and that their states are both VP_INFINITE. That's why opposite sides of the rectangle you create are parallel (i.e. don't meet in a finite VP) and axis-aligned. You can play with different directions or initial states for the VPs to observe the effect this has (unfortunately, this needs recompiling because the perspective is hard-coded at the moment).
Now the axis aligned rectangle you see only represents one face of the box. To extrude the box and make it appear 3D, press Shift once the front face is created (but keep holding the mouse button). This fixes the front face and starts dragging the remaining faces in Z direction.
As I said, the initial states of all three VPs are 'infinite'. But when you activate the 3D box tool you will observe three small unfilled squares on the canvas. These indicate the positions of the VPs if their state would be 'finite'. Although at the current stage VPs are not draggable, it is possible to toggle their states by pressing the buttons in the 3D box toolbar (they are rather easy to overlook; each one simply shows two parallel lines, but the tooltips should be more meaningful). When the state is toggled to 'finite', the square representing the VP is color-filled and corresponding edges of newly created boxes are now drawn along perspective lines meeting in that VP. Toggling it back to 'infinite' unfills the square and draws edges parallel again. I know that it's rather unintuitive to have the squares for the VPs shown on the canvas but boxes ignore them when they are white. But since the VP-machinery needs to be rewritten anyway (very soon hopefully), I didn't want to invest a lot of time to make static VPs work more beautifully.
I hope this makes things a bit clearer. Don't hesitate to ask if something still remains cryptic. And your feedback is very welcome.
Best regards, Max
Bill Baxter wrote:
Ok. Thanks for the explanation. That shift thing is very unintuitive.
Really? I thought it was the most obvious thing. First you need to draw the front face, but then when you are already in the process of drawing, some modifier is needed to tell the tool that we want to go along the Z axis now. I really can't see any significantly different way to create a box, but I'm confident that you will quickly get used to it after trying it a couple of times. What had you envisioned instead?
This is of course only for the intial drawing process. Once the box is created it can certainly be resized by dragging handles (see below).
Hopefully you will get rid of that in favor of something that can be changed any time by dragging a handle or changing a "thickness" setting in the toolbar.
Dragging handles is implemented in the most recent version. :) Only the question of how many of them we want and if their movement should be constrained to certain axes or unconstrained by default still needs to be settled. Comments are appreciated.
More generally I guess I still don't get why you'd want to have a 3D box tool. It's basically an extrusion tool that happens to only extrude rectangles. Why not make something that's capable of extruding anything and applying a perspective transform to it? Like the question that was on the list earlier today -- about extruding fonts. This would be a useful tool for doing that, if it weren't restricted to extruding only rectangles.
See Bulia's original proposal in the wiki for some comments, in particular the second question in the Mini-FAQ:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code#3D_Tool
Basically, I think the 3D box tool is certainly a very helpful thing for people in the realm of technical designing (alone because 3D boxes can be used as a sort of "skeleton" for more complicated shapes that are then drawn by hand). But as Bulia writes, a 3D box is first and foremost the fundamental building block of any 3D scene. And imho it is a very convenient way of specifying a certain perspective. Once you have a means of defining perspectives, these can be used to extrude any kind of objects, draw objects in tilted planes, and many, many more things; the wiki and the accompanying website of the tool (see the link in my last email) list a random and certainly incomplete collection of further ideas. The implementation of the tool contains a separate C++ class for 3D perspectives which can (and is supposed to) be used as a basis to implement all this, although such advanced functionality won't be part of this SoC project.
/Max
On 7/5/07, Maximilian Albert <Anhalter42@...173...> wrote:
See Bulia's original proposal in the wiki for some comments, in particular the second question in the Mini-FAQ:
http://wiki.inkscape.org/wiki/index.php/Googles_Summer_Of_Code#3D_Tool
And after playing with the current tool, even though I cannot yet drag the VPs, I can only confirm that the tool is very valuable. Apart from any practical considerations, what I look for in any tool is, above all, magic. A tool's magic is its ability to wow me, to surprise me, to do something cool that would be very difficult or impossible to do otherwise, to do something fundamentally different from all the other tools. Examples of pure magic are blur, clone tiler, calligraphic pen... and the 3D tool, I can assure you, provides a healthy dose of its own unique magic.
On 7/5/07, Maximilian Albert <Anhalter42@...173...> wrote:
Bill Baxter wrote:
Ok. Thanks for the explanation. That shift thing is very unintuitive.
Really? I thought it was the most obvious thing. First you need to draw the front face, but then when you are already in the process of drawing, some modifier is needed to tell the tool that we want to go along the Z axis now. I really can't see any significantly different way to create a box, but I'm confident that you will quickly get used to it after trying it a couple of times. What had you envisioned instead?
This is of course only for the intial drawing process. Once the box is
created it can certainly be resized by dragging handles (see below).
No, that doesn't work if you don't do the shift thing initially. So maybe it's just a bug. You get two handles that work, and a third one floating in space that moves diagonally but has no effect.
Anyway, compare with how arcs are created, for instance. You create an initial circle/arc by a click-drag-release, then you set the wedge angle you want by dragging on a handle. And the last arc angle is remembered by the tool. I think that is how the 3D box should work too.
As far as the goal of being able to specify perspective is concerned -- I'm a little unclear what the interaction is going to be like for creating vanishing points that are very far away, but not infinite. Say you want lines not to be parallel but converging just slightly, to a vanishing point that's, say, 5 screenwidths to the left. Sure you could enter in a numeric value to place the vanishing point, but that's not very intuitive. I think it would be more useful to provide an alternate click-drag operation for the vanishing point lines. Say Ctrl-drag on one of the vanishing lines changes the distance to the vanishing point by some inverse function like 1/(dx+k) where dx is the mouse motion and k is some constant. That's probably not the right function exactly, but anyway making it inverse means you can get to an infinite vanishing point with a finite amount of mouse dragging, in exchange for making it take infinite dragging to get to zero. But by the time you're close to zero you'll be within reach of the vanishing point for direct click and drag anyway, so that should be ok.
--bb
Bill Baxter wrote:
On 7/5/07, *Maximilian Albert* <Anhalter42@...173... mailto:Anhalter42@...173...> wrote:
Bill Baxter wrote: > Ok. Thanks for the explanation. That shift thing is very unintuitive. Really? I thought it was the most obvious thing. First you need to draw the front face, but then when you are already in the process of drawing, some modifier is needed to tell the tool that we want to go along the Z axis now. I really can't see any significantly different way to create a box, but I'm confident that you will quickly get used to it after trying it a couple of times. What had you envisioned instead? This is of course only for the intial drawing process. Once the box is created it can certainly be resized by dragging handles (see below).No, that doesn't work if you don't do the shift thing initially. So maybe it's just a bug. You get two handles that work, and a third one floating in space that moves diagonally but has no effect.
Anyway, compare with how arcs are created, for instance. You create an initial circle/arc by a click-drag-release, then you set the wedge angle you want by dragging on a handle. And the last arc angle is remembered by the tool. I think that is how the 3D box should work too.
As far as the goal of being able to specify perspective is concerned -- I'm a little unclear what the interaction is going to be like for creating vanishing points that are very far away, but not infinite. Say you want lines not to be parallel but converging just slightly, to a vanishing point that's, say, 5 screenwidths to the left. Sure you could enter in a numeric value to place the vanishing point, but that's not very intuitive. I think it would be more useful to provide an alternate click-drag operation for the vanishing point lines. Say Ctrl-drag on one of the vanishing lines changes the distance to the vanishing point by some inverse function like 1/(dx+k) where dx is the mouse motion and k is some constant. That's probably not the right function exactly, but anyway making it inverse means you can get to an infinite vanishing point with a finite amount of mouse dragging, in exchange for making it take infinite dragging to get to zero. But by the time you're close to zero you'll be within reach of the vanishing point for direct click and drag anyway, so that should be ok.
Bill,
Please remember that the 3D Box tool, as with all other GSoC projects, is not close to being finished... we're just getting to the mid-term progress report stage (and Max had a late start this summer to boot). Please be patient and see what Max has in store. With the quality of his proposal, as well as knowing his mentor's reputation, I can assure you that it will all come together and make sense (as well as be incredibly intuitive) prior to the first official release to include it.
-Josh
On 7/7/07, Josh Andler <scislac@...400...> wrote:
Bill,
Please remember that the 3D Box tool, as with all other GSoC projects, is not close to being finished... we're just getting to the mid-term progress report stage (and Max had a late start this summer to boot). Please be patient and see what Max has in store. With the quality of his proposal, as well as knowing his mentor's reputation, I can assure you that it will all come together and make sense (as well as be incredibly intuitive) prior to the first official release to include it.
Yeh, I totally understand that it's a work in progress. And it does seem to be coming along nicely. He was asking for feedback so I was trying to give some is all. I looked at the web page and didn't see anything about a UI for adjusting the distances to the vanishing points easily over the full range from 0 to infinity, so I thought I'd throw out a rough idea for how to do that.
--bb
Hi Bill, Josh,
sorry for not answering earlier. I didn't have internet access during the weekend.
Please remember that the 3D Box tool, as with all other GSoC projects, is not close to being finished... we're just getting to the mid-term progress report stage (and Max had a late start this summer to boot). Please be patient and see what Max has in store. With the quality of his proposal, as well as knowing his mentor's reputation, I can assure you that it will all come together and make sense (as well as be incredibly intuitive) prior to the first official release to include it.
Thanks for the backup, Josh. :)
I am aware that many things don't work as expected yet, and maybe it's a bit early to ask for public feedback since many problems may only be due to the incompleteness of the tool (and I am not that much aware of them because I have the final version in mind).
But I think that at a stage where some design decisions still need to be made - even if they are small and could be changed later on - it's good to have an idea of what people expect from such a tool. Thus I'm glad to hear Bill's opinion (and other people's, for that matter). He is totally right to complain if something appears unintuitive to him (although in this case part of the unintuitivity comes from the bug he described). That doesn't mean that we will radically change the intended behaviour, but it's always good to know what people think and if there is room to react, there is no reason not to do it.
Once the box is created it can certainly be resized by dragging handles (see below).
No, that doesn't work if you don't do the shift thing initially. So maybe it's just a bug. You get two handles that work, and a third one floating in space that moves diagonally but has no effect.
Bulia already pointed out that it's a bug, which is fixed in my local version (the fix will be submitted to SVN later today, along with some other changes).
He was asking for feedback so I was trying to give some is all.
As I said, it's always appreciated. :) Don't hesitate to make further comments.
Cheers, Max
On 7/6/07, Bill Baxter <wbaxter@...400...> wrote:
No, that doesn't work if you don't do the shift thing initially. So maybe it's just a bug. You get two handles that work, and a third one floating in space that moves diagonally but has no effect.
Yes, I noticed that too. It's a bug.
Anyway, compare with how arcs are created, for instance. You create an initial circle/arc by a click-drag-release, then you set the wedge angle you want by dragging on a handle. And the last arc angle is remembered by the tool. I think that is how the 3D box should work too.
Agreed. It would be interesting to treat the Z-axis depth of boxes as a property of the box which is to be remembered the way the angle of an arc is remembered. By providing some sensible default value for the depth, this will address the discoverability problem of the Shift+drag technique and will make it much easier to make many boxes of the same depth, which is a common enough use case. However, we don't need to lose Shift+drag - it can still be used while drawing to change the default depth, so that a box of any depth can still be created with one mouse drag.
As far as the goal of being able to specify perspective is concerned -- I'm a little unclear what the interaction is going to be like for creating vanishing points that are very far away, but not infinite. Say you want lines not to be parallel but converging just slightly, to a vanishing point that's, say, 5 screenwidths to the left. Sure you could enter in a numeric value to place the vanishing point, but that's not very intuitive. I think it would be more useful to provide an alternate click-drag operation for the vanishing point lines. Say Ctrl-drag on one of the vanishing lines changes the distance to the vanishing point by some inverse function like 1/(dx+k) where dx is the mouse motion and k is some constant. That's probably not the right function exactly, but anyway making it inverse means you can get to an infinite vanishing point with a finite amount of mouse dragging, in exchange for making it take infinite dragging to get to zero. But by the time you're close to zero you'll be within reach of the vanishing point for direct click and drag anyway, so that should be ok.
Yes, we discussed that already. One of the things that will be implemented is: simply drag the line that goes from the box to the vanishing point and that point will correspondingly orbit the center of the box (and all other selected boxes sharing this VP will update accordingly). Then we can similarly provide a way to move a VP along the line (apart from directly dragging it), for example by Shift+dragging along the line, perhaps with some kind of exponential effect as you suggested.
bulia byak wrote:
Anyway, compare with how arcs are created, for instance. You create an initial circle/arc by a click-drag-release, then you set the wedge angle you want by dragging on a handle. And the last arc angle is remembered by the tool. I think that is how the 3D box should work too.
Agreed. It would be interesting to treat the Z-axis depth of boxes as a property of the box which is to be remembered the way the angle of an arc is remembered. By providing some sensible default value for the depth, this will address the discoverability problem of the Shift+drag technique and will make it much easier to make many boxes of the same depth, which is a common enough use case.
Do I understand you correctly that you propose to let each box already have a certain depth during the creation process (i.e., during dragging)? This is certainly an alternative. However, since we don't have a real 3D model of boxes (that is, "true" z coordinates), it needs to be seen how we can make sure that all boxes have the "same" default depth, regardless of their position on the canvas. I am currently thinking about this problem in the context of moving 3D boxes "in perspective" (which is what I chose to address before making VPs draggable because the infrastructure is already there; I already have an almost working local version ;)). I'm sure that it's possible to achieve a good measuring of perspective lengths and distances this but I am still looking for the numerically most stable solution.
However, we don't need to lose Shift+drag - it can still be used while drawing to change the default depth, so that a box of any depth can still be created with one mouse drag.
I am not quite certain how you imagine Shift+drag to to work when the boxes already have a default depth. For once you press shift and continue dragging along the z axis, the mouse pointer is at a different position than the already extruded (= lower right rear) corner. Should that corner in this case just "snap back" to the position of the mouse pointer so that the box is momentarily collapsed and can then be extruded in the same way as it currently is? Or do you have other alternatives in mind?
/Max
On 7/10/07, Maximilian Albert <Anhalter42@...173...> wrote:
Do I understand you correctly that you propose to let each box already have a certain depth during the creation process (i.e., during dragging)?
Yes
This is certainly an alternative. However, since we don't
have a real 3D model of boxes (that is, "true" z coordinates), it needs to be seen how we can make sure that all boxes have the "same" default depth, regardless of their position on the canvas.
I think it's easy enough to define "same width". Imagine you have two boxes. Just drag one of the XY-plane handles of one of them until it coincides with the analogous handle of the other box. Then the length of z-axis edges at that handle can be compared directly.
However, we don't need to lose Shift+drag - it can still be used while drawing to change the default depth, so that a box of any depth can still be created with one mouse drag.
I am not quite certain how you imagine Shift+drag to to work when the boxes already have a default depth. For once you press shift and continue dragging along the z axis, the mouse pointer is at a different position than the already extruded (= lower right rear) corner. Should that corner in this case just "snap back" to the position of the mouse pointer so that the box is momentarily collapsed and can then be extruded in the same way as it currently is? Or do you have other alternatives in mind?
Yes, I think it should snap back to mouse then. Not very intuitive, but it will be a shortcut for power users anyway. Most first-time users will just draw XY, release, and then drag the Z handle.
Also, same as Rect tool produces a square with Ctrl, your tool must produce perfect cube with Ctrl.
Other bugs:
- duplicating a box places its handles in some weird place
- dragging a box by Selector makes its handles go off the corners, and then dragging corners makes box jump - this used to work fine before but is broken now
- middle-button drag to pan in 3D box tool does not work (very annoying because I use it exclusively for panning)
bulia byak schrieb:
I like the first one better. But it's still not ideal. Ideally, I'd like to have a handle in each corner, and have these handles as little constrained as possible (I understand they cannot be absolutely unconstrained or it will be ambiguous, but we need to find some logical compromise).
This is now in SVN (click on the button showing four squares in the 3D box toolbar to activate it). Currently the four front handles of a box by default resize inside the XY plane and with Shift along the Z axis. The four rear handles behave the other way round, but the more I think about it the more I come to the conclusion that all of them should behave the same way. It depends on the states of the vanishing points, however, which of these alternatives seems most intuitive, but the latter option is most consistent. What do you think? Also, do you believe that eight handles don't overcrowd the canvas, especially if there are many boxes?
Best regards, Max
On 7/10/07, Maximilian Albert <Anhalter42@...173...> wrote:
This is now in SVN (click on the button showing four squares in the 3D box toolbar to activate it). Currently the four front handles of a box by default resize inside the XY plane and with Shift along the Z axis. The four rear handles behave the other way round, but the more I think about it the more I come to the conclusion that all of them should behave the same way. It depends on the states of the vanishing points, however, which of these alternatives seems most intuitive, but the latter option is most consistent. What do you think?
Hmm, that means that it will not be possible to change Z at all unless you know the Shift trick. I'm worrying about the discoverability of this. I think it will be more consistent, in some sense, to leave it as it is now, because now you can change any of the three dimensions without any modifiers.
As an additional visual clue, can you make the 4 handles of the corners that are closer to the viewer in Z direction larger than the 4 others? See nodepath.cpp for how to change the size of a handle (it makes selected nodes larger). This will also address the problem of the visual clutter somewhat.
Also, for consistency with rect, please allow a handle to snap to the closest continuation of an edge or a diagonal (in the latter case it will be scaling a box preserving the ratio of that plane's side). (Since Z-axis drag is always constrained, Ctrl will have no effect on it.) And with Alt, make it snap to 2, 3, 4, and 1/2, 1/3, 1/4 etc of the current size in the direction of the drag (this is now done in Selector scaling but I will add this to Rect tool as well).
Thanks for all your feedback and best regards,
I tried out this tool, and I have some difficulties. This is the revision 15303.
Here is a screenshot of the tool: http://i16.tinypic.com/67e94ly.png
Maybe it is not working? I dont see any 3d like object, and looks like the rectangle tool is activated. (so if I drag something it has the rectangle tool cursor and I draw a recangle, but as soon as I finish drawing the rectangle disappear, and only the two handles rest on the canvas.)
I highly doubt this is works...
Any idea?
Khiraly
Khiraly schrieb:
Thanks for all your feedback and best regards,
I tried out this tool, and I have some difficulties. This is the revision 15303.
Here is a screenshot of the tool: http://i16.tinypic.com/67e94ly.png
Whooops, that looks strange indeed. Can you give precise steps to reproduce this? Did you do anything special? Or did you just do a simple drag as you would have done with the rectangle tool?
Maybe it is not working? I dont see any 3d like object, and looks like the rectangle tool is activated. (so if I drag something it has the rectangle tool cursor and I draw a recangle, but as soon as I finish drawing the rectangle disappear, and only the two handles rest on the canvas.)
Everything up to the point where the rectangle disappears is normal behaviour. The cursor is the same as for the rectangle tool (I haven't bothered to change it yet), and what you do while dragging is you create the front face of the 3D box. It looks like an undistorted rectangle because the states of all vanishing points are 'infinite'; try toggling them using the corresponding buttons in the 3D box toolbar, which show two parallel lines each. You can extrude the box by pressing Shift during dragging. (See my recent post in reply to Bill Baxter's questions or the first paragraph of
http://www.rzuser.uni-heidelberg.de/~malbert/core_functionality.shtml
). Does it make a difference if you create an extruded box instead of only the front face?
Thanks for any further feedback! Max
Khiraly wrote:
I tried out this tool, and I have some difficulties. This is the revision 15303.
Here is a screenshot of the tool: http://i16.tinypic.com/67e94ly.png
Maybe it is not working? I dont see any 3d like object, and looks like the rectangle tool is activated. (so if I drag something it has the rectangle tool cursor and I draw a recangle, but as soon as I finish drawing the rectangle disappear, and only the two handles rest on the canvas.)
I highly doubt this is works...
Any idea?
Finally, yes. I just had a chat with Johan Engelen on IRC, and he pointed me in the right direction (many thanks again, Johan!!).
It seems that depending on the locale the coordinates of the box get converted in the wrong way when they are written to svg. More precisely, the decimal point is sometimes converted to a comma, which completely messes up the interpretation of the coordinates. I just committed a fix in SVN. Would you (or anyone else experiencing the same problem) mind giving it a try again to report if it works or if any problems remain?
Thanks, Max
On 7/17/07, Maximilian Albert <Anhalter42@...173...> wrote:
It seems that depending on the locale the coordinates of the box get converted in the wrong way when they are written to svg. More precisely, the decimal point is sometimes converted to a comma, which completely messes up the interpretation of the coordinates. I just committed a fix in SVN. Would you (or anyone else experiencing the same problem) mind giving it a try again to report if it works or if any problems remain?
Ah, yes. This hit us many times before. Sorry I forgot to warn you against this :)
It's better to use not g_string_append_printf but our own Inkscape::SVGOStringStream class - it has settable number precision and some other nice properties. You can find examples of its use in many places in the code.
Oh, and I just noticed that you used g_string_append_printf for creating your own path representation. In this case, it's simpler and better to use our existing path code for that. Just create a temporary NArtBpath, add the linetos, and then call sp_svg_write_path to get the string. This way all path writing is in one place, which is good for maintainability.
bulia byak schrieb:
It's better to use not g_string_append_printf but our own Inkscape::SVGOStringStream class - it has settable number precision and some other nice properties. You can find examples of its use in many places in the code.
Oh, and I just noticed that you used g_string_append_printf for creating your own path representation. In this case, it's simpler and better to use our existing path code for that. Just create a temporary NArtBpath, add the linetos, and then call sp_svg_write_path to get the string. This way all path writing is in one place, which is good for maintainability.
Thanks! With these suggestion the code gets _a lot_ cleaner. This is precisely what I was looking for, in the face of the ugly previous fix.:) The new version is in SVN now.
Cheers, Max
On 7/18/07, J.B.C.Engelen wrote:
Maximilian Albert wrote:
the coordinates. I just committed a fix in SVN. Would you (or anyone else experiencing the same problem) mind giving it a try again to report if it works or if any problems remain?
Works fantastically!
Works now for me too, except I see the rear plane on front :)
Alexandre
2007. 07. 18, szerda keltezéssel 02.27-kor Maximilian Albert ezt írta:
Would you (or anyone else experiencing the same problem) mind giving it a try again to report if it works or if any problems remain?
Hi!
Sorry for the delayed reply, just let you know the 3D box tool works now.
Im on hungarian locale, which use the same comma decimal point as the german locale.
Other questions:
Is the toggle button (with 3 and 4 knots) works? I have always 3 vanishing points.
Can I drag the vanishing points, or reform my question: Can I rotate somehow the cube? (all my cubes are identic)
ps: this is revision 15465
Best regards, Khiraly
Khiraly wrote:
Sorry for the delayed reply, just let you know the 3D box tool works now.
Great!
Other questions:
Is the toggle button (with 3 and 4 knots) works? I have always 3 vanishing points.
Yes, it does work, but it's not intended to toggle the number of vanishing points - their number is always three, since we're in 3D :). These toggle buttons are simply an auxiliary means to test different resizing behaviours for the boxes. More precisely, how many handles the box has and along which axes or in which planes they resize the box. BTW, I just discovered that the tooltip for the 4-handles-button is wrong, since I changed the box to have 8 handles if it's toggled; but I won't bother to correct it now since the behaviour will change with one of my next commits anyway.
Can I drag the vanishing points, or reform my question: Can I rotate somehow the cube? (all my cubes are identic)
Not yet, but very soon - I'm currently working on draggable vanishing points. It's almost finished, but I'd like to clean up a few things and fix a couple of bugs before commiting the change. It may take till next week, tough (for personal reasons I couldn't invest as much time as I would have liked this week). An announcement will go over the list.
Best regards, Max
participants (7)
-
unknown＠example.com -
Alexandre Prokoudine -
Bill Baxter -
bulia byak -
Josh Andler -
Khiraly -
Maximilian Albert