Hi all,
I don't know how many times I announced this, but it has finally happened: As of rev #16681 the new, completely reworked(TM) 3D box tool code is now in SVN, hopefully still in time for 0.46.
Those of you who played around with the tool before may have noticed that although it was certainly usable, there were a couple of issues; most notably, undo/redo didn't work reliably, some box configurations in degenerate perspectives were not really stable, etc. But most of all, development was getting more and more of a pain, making both debugging and adding new features tremendously difficult. All this was due to the internal architectural design of the tool at the time. Since I didn't see a way to easily sort this out by continuing the chosen path (and even if I had, it would only have led the tool even further into a dead end as far as extensibility and applicability to other 3D related tasks are concerned), I decided that it would be better to rewrite a lot of it more or less from scratch. I apologize that this has taken me so long, but I'm studying for my finals right now (or rather should be :-/ ), which has been a major distraction for completion.
Anyway, the bulk is done now, and I'd like to give you a very quick overview of the changes.
As far as the "ordinary" user is concerned, the overall behaviour of the tool is roughly the same as before, except that it is more stable and reliable. :) (In particular, there haven't been any great new features added yet). The most notable visible changes are the following:
- Boxes now come equipped with a default depth, i.e. simply dragging on the canvas creates a full-featured box. This hides the allegedly hard-to-discover Shift+drag feature from the user and makes it easy for newcomers to find out what the tool actually does.
- Boxes sharing the same perspective move together when a vanishing point is dragged, as if they form part of the same 3D scene that is simply viewed from a different angle (before, they all moved independently of each other). This makes it easy to create entire scenes and adjust them as a whole during drawing.
If you want boxes to move independently of each other, you can split perspectives up by shift-dragging a vanishing point. For a full list of this and other features of the tool, please wait until I have updated the Release Notes (a copy will be posted to this list).
So much for the visible part of the tool. For those who are interested here comes a more in-depth description of the internal changes:
1) *All* 3D box related structures (namely, the box itself, its sides, and also perspectives) are now handled as SPObjects, which fixes the annoying issues with undo/redo. A notable consequence is that the SVG representation of boxes is now slightly different than it was before, which probably renders old files invalid or even unusable. This shouldn't be a great issue, though, since the tool has not officially been enabled yet (which turns out to be a good decision). I'm going to give the current representation a final revise in the next one or two days, but I don't expect it to change any more.
2) Perspectives are now added to the document's defs so that they can in principle be reused by other objects. This doesn't have an immediate effect on the tool itself but should make applications to other 3D related situations easier.
3) Before the refactoring, all constructions were made geometrically by computing connecting lines, points of intersection, etc. The way it works now is that we use the information given by the three vanishing points to compute a mapping from 3D space to the canvas which results in the specified perspective. By computing inverse images of canvas points, this allows us to determine "real" 3D coordinates of boxes, to model the concept of lengths (at least to a certain extent), to compare coordinates of boxes, etc. Also, degenerate perspectives can be handled in a numerically stable way because not the boxes themselves are degenerate but only their _images_ on the canvas.
In fact, this description is a bit of an oversimplification. In order to compute the mentioned perspective mapping, it is necessary to (at least implicitly) specify a _fourth_ point on the canvas, which can be thought of as the origin of the coordinate system (whose three axes point towards the vanishing points). This fourth point is not currently represented on screen. A while ago in one of our discussions Bulia suggested that it should be hidden from the user because its meaning might be unintuitive. Personally, I'm not entirely convinced and I'm tempted to leave it as an option to the user whether it should be drawn on the screen or not (it can also be quite useful for adjusting 3D scenes). Any opinions from other people? At present you can visualize this point by pressing 'O' in the 3D box tool (you may need to draw a box first). This draws a small pink point on the canvas. Note that I added this shortcut for debugging purposes and it will be removed later on. Think of this point as the "anchor" of the coordinate system - it is the only point that always remains fixed when vanishing points are dragged.
Well, that is pretty much all I can think of at the moment. Please ask if you are missing anything or if something remained unclear. In principle, everything should more or less work now. There are a few known issues I'm going to sort out in the next days, including (but probably not limited to) the following:
- I had to temporarily disable the spin buttons in the toolbar after introducing an undo-related crash yesterday (Inkscape chokes with the message "assertion failed: (doc->priv->sensitive)"). I will debug this and make them work again very soon. In the meantime, the states of vanishing points can be toggled using the shortcuts "X", "Y", and "Z". In addition, the angles of infinite perspective lines can be rotated using the various types of brackets - namely [], (), {} (where Alt+dragging results in a very small rotation angle).
- Although z-orders should be set reliably now, there may be a few degenerate cases where they are still wrong (I think I know which these are). If you discover such a case, you can send me a corresponding *.svg file if you wish.
- Transformations of boxes work, but if a single box is transformed this also transforms all other boxes sharing the same perspective. Bulia said that instead this box needs to be unlinked. Will fix this soon.
- Stroke, patterns, and gradients are not yet adapted during transformations. I'll have to see how to do this because transformations are implemented differently in 3D boxes than in the other tools. Any general pitfalls I need to know or keep in mind regarding this?
- Constrained dragging of handles (by using Ctrl) somehow sets the box off a certain amount from the intended position. Don't know precisely what causes this but I hope it won't be hard to fix.
- flipping boxes doesn't update its z-orders
- ... whatever you may discover ...
As always, if there are any questions, comments, suggestions, you name it - please don't hesitate to tell me. And now: Happy testing and enjoy. :=)
Cheers, Max
P.S.:There is still a number of debugging messages present in the code (most of them commented out, but maybe I forgot some). I will of course get rid of them soon, but currently they are helping me in resolving the remaining issues, so I left them in.
Maximilian Albert wrote:
I apologize that this has taken me so long, but I'm studying for my finals right now (or rather should be :-/ ), which has been a major distraction for completion.
Max! Don't feel bad! I'm sure I speak for everyone when I say how impressive your hard work and dedication has been! How you found the time to do so much is beyond me ;) I'm glad that you took on the 3D box tool instead of me.
Gail
Thanks! The tool is awesome! It "feels" a little more natural...maybe it's just a psychological effect of having the reworked tool :)
I have a suggestion. I'm not sure if this has been addressed before, but I don't remember - sorry if it has.
Maybe you could add some directional arrows to the "grip" diamonds which indicate which dimension the grips adjust...i.e., the one which makes the box taller and shorter would be labelled with an up and down arrow, etc.
Would there be a way to make the arrows for the other perspectives match the actual perspective "angle of view" for more intuitive control.
Just a thought. Anyway, nice job - and get back to studying ;-)
JF
Maximilian Albert wrote:
Hi all,
I don't know how many times I announced this, but it has finally happened: As of rev #16681 the new, completely reworked(TM) 3D box tool code is now in SVN, hopefully still in time for 0.46.
Those of you who played around with the tool before may have noticed that although it was certainly usable, there were a couple of issues; most notably, undo/redo didn't work reliably, some box configurations in degenerate perspectives were not really stable, etc. But most of all, development was getting more and more of a pain, making both debugging and adding new features tremendously difficult. All this was due to the internal architectural design of the tool at the time. Since I didn't see a way to easily sort this out by continuing the chosen path (and even if I had, it would only have led the tool even further into a dead end as far as extensibility and applicability to other 3D related tasks are concerned), I decided that it would be better to rewrite a lot of it more or less from scratch. I apologize that this has taken me so long, but I'm studying for my finals right now (or rather should be :-/ ), which has been a major distraction for completion.
Anyway, the bulk is done now, and I'd like to give you a very quick overview of the changes.
As far as the "ordinary" user is concerned, the overall behaviour of the tool is roughly the same as before, except that it is more stable and reliable. :) (In particular, there haven't been any great new features added yet). The most notable visible changes are the following:
Boxes now come equipped with a default depth, i.e. simply dragging on the canvas creates a full-featured box. This hides the allegedly hard-to-discover Shift+drag feature from the user and makes it easy for newcomers to find out what the tool actually does.
Boxes sharing the same perspective move together when a vanishing point is dragged, as if they form part of the same 3D scene that is simply viewed from a different angle (before, they all moved independently of each other). This makes it easy to create entire scenes and adjust them as a whole during drawing.
If you want boxes to move independently of each other, you can split perspectives up by shift-dragging a vanishing point. For a full list of this and other features of the tool, please wait until I have updated the Release Notes (a copy will be posted to this list).
So much for the visible part of the tool. For those who are interested here comes a more in-depth description of the internal changes:
- *All* 3D box related structures (namely, the box itself, its sides,
and also perspectives) are now handled as SPObjects, which fixes the annoying issues with undo/redo. A notable consequence is that the SVG representation of boxes is now slightly different than it was before, which probably renders old files invalid or even unusable. This shouldn't be a great issue, though, since the tool has not officially been enabled yet (which turns out to be a good decision). I'm going to give the current representation a final revise in the next one or two days, but I don't expect it to change any more.
- Perspectives are now added to the document's defs so that they can
in principle be reused by other objects. This doesn't have an immediate effect on the tool itself but should make applications to other 3D related situations easier.
- Before the refactoring, all constructions were made geometrically
by computing connecting lines, points of intersection, etc. The way it works now is that we use the information given by the three vanishing points to compute a mapping from 3D space to the canvas which results in the specified perspective. By computing inverse images of canvas points, this allows us to determine "real" 3D coordinates of boxes, to model the concept of lengths (at least to a certain extent), to compare coordinates of boxes, etc. Also, degenerate perspectives can be handled in a numerically stable way because not the boxes themselves are degenerate but only their _images_ on the canvas.
In fact, this description is a bit of an oversimplification. In order to compute the mentioned perspective mapping, it is necessary to (at least implicitly) specify a _fourth_ point on the canvas, which can be thought of as the origin of the coordinate system (whose three axes point towards the vanishing points). This fourth point is not currently represented on screen. A while ago in one of our discussions Bulia suggested that it should be hidden from the user because its meaning might be unintuitive. Personally, I'm not entirely convinced and I'm tempted to leave it as an option to the user whether it should be drawn on the screen or not (it can also be quite useful for adjusting 3D scenes). Any opinions from other people? At present you can visualize this point by pressing 'O' in the 3D box tool (you may need to draw a box first). This draws a small pink point on the canvas. Note that I added this shortcut for debugging purposes and it will be removed later on. Think of this point as the "anchor" of the coordinate system - it is the only point that always remains fixed when vanishing points are dragged.
Well, that is pretty much all I can think of at the moment. Please ask if you are missing anything or if something remained unclear. In principle, everything should more or less work now. There are a few known issues I'm going to sort out in the next days, including (but probably not limited to) the following:
I had to temporarily disable the spin buttons in the toolbar after introducing an undo-related crash yesterday (Inkscape chokes with the message "assertion failed: (doc->priv->sensitive)"). I will debug this and make them work again very soon. In the meantime, the states of vanishing points can be toggled using the shortcuts "X", "Y", and "Z". In addition, the angles of infinite perspective lines can be rotated using the various types of brackets - namely [], (), {} (where Alt+dragging results in a very small rotation angle).
Although z-orders should be set reliably now, there may be a few degenerate cases where they are still wrong (I think I know which these are). If you discover such a case, you can send me a corresponding *.svg file if you wish.
Transformations of boxes work, but if a single box is transformed this also transforms all other boxes sharing the same perspective. Bulia said that instead this box needs to be unlinked. Will fix this soon.
Stroke, patterns, and gradients are not yet adapted during transformations. I'll have to see how to do this because transformations are implemented differently in 3D boxes than in the other tools. Any general pitfalls I need to know or keep in mind regarding this?
Constrained dragging of handles (by using Ctrl) somehow sets the box off a certain amount from the intended position. Don't know precisely what causes this but I hope it won't be hard to fix.
flipping boxes doesn't update its z-orders
... whatever you may discover ...
As always, if there are any questions, comments, suggestions, you name it - please don't hesitate to tell me. And now: Happy testing and enjoy. :=)
Cheers, Max
P.S.:There is still a number of debugging messages present in the code (most of them commented out, but maybe I forgot some). I will of course get rid of them soon, but currently they are helping me in resolving the remaining issues, so I left them in.
SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Dec 13, 2007 6:10 AM, Maximilian Albert <Anhalter42@...173...> wrote:
Hi all,
I don't know how many times I announced this, but it has finally happened: As of rev #16681 the new, completely reworked(TM) 3D box tool code is now in SVN, hopefully still in time for 0.46.
First impressions:
- drawing and adjusting in 3D box tool indeed work much better now, no wrong z-order and no weird degenerate shapes anymore
- however, simply dragging a 3d box by selector is broken: part of the box stays behind, and undo of this operation does nothing. However, it seems the basic behavior is right : dragging a box drags its perspective points, and this is what it needs to do. However: when multiple boxes share the perspective points and I drag only one of them, it must automatically split the perspective so that the other boxes are not affected. If I want to selector-drag multiple boxes keeping them in the same perspective, I will just select them all and drag - and then no perspective splitting for these boxes must be done.
bulia byak wrote:
First impressions:
- drawing and adjusting in 3D box tool indeed work much better now, no
wrong z-order and no weird degenerate shapes anymore
- however, simply dragging a 3d box by selector is broken: part of the
box stays behind, and undo of this operation does nothing.
Whoops, now I see this, too, although it used to work just fine. But I have seen similar things (like single sides staying behind) before, and strangely they only occured when I was using custom styles for the sides. When the box had its default style, everything worked alright. Confusing. But I will investigate. Would you mind trying the default style, too, and report if it then works for you?
However: when multiple boxes share the perspective points and I drag only one of them, it must automatically split the perspective so that the other boxes are not affected.
Hmm, this is what Shift-dragging of the vanishing point currently achieves. I chose this behaviour because I believe it's much more common that you'd want to create a couple of boxes in a single perspective and to adjust this perspective frequently by moving the vanishing points (for example, think of the boxes as representing houses along a street, or as building blocks of a complicated shape). In this case it will be a great annoyance to always have to select all boxes that are supposed to move together. But with the current setup, once you decide that several boxes shall be independent of the others, you simply select them, Shift-drag once so that the perspectives are separated, and you can henceforth edit the two sets of boxes independently (but each of them consistently within itself, i.e., the boxes in each set again move together).
I can also see your point, but imho it would be a bit more awkward to work that way. However, I think in the end it's a question that should be decided according to the usual workflow of users, so I'd love to hear other opinions.
As for splitting up of perspectives upon applying transformations, check out current SVN, revision #16684. :)
Max
On Thu, 13 Dec 2007 21:13:19 +0100, Maximilian Albert <Anhalter42@...173...> wrote:
However, I think in the end it's a question that should be decided according to the usual workflow of users, so I'd love to hear other opinions.
My feeling is that it should work just like gradient handles: when multiple 3d boxes are selected, any vanishing points which coincide between the selected boxes will be locked together unless shift is held.
-mental
On Thu, 13 Dec 2007 12:26:56 -0800, MenTaLguY <mental@...3...> wrote:
My feeling is that it should work just like gradient handles: when multiple 3d boxes are selected, any vanishing points which coincide between the selected boxes will be locked together unless shift is held.
Of course: ...and otherwise, they should move independently.
-mental
On Dec 13, 2007 3:13 PM, Maximilian Albert <Anhalter42@...173...> wrote:
Whoops, now I see this, too, although it used to work just fine. But I have seen similar things (like single sides staying behind) before, and strangely they only occured when I was using custom styles for the sides. When the box had its default style, everything worked alright. Confusing. But I will investigate. Would you mind trying the default style, too, and report if it then works for you?
Yes, with default style nothing is left behind. But undo still does nothing. And further undos start to undo drawing of the box _in its new position_. That's wrong, it was drawn in a different place altogether.
However: when multiple boxes share the perspective points and I drag only one of them, it must automatically split the perspective so that the other boxes are not affected.
Hmm, this is what Shift-dragging of the vanishing point currently achieves. I chose this behaviour because I believe it's much more common that you'd want to create a couple of boxes in a single perspective and to adjust this perspective frequently by moving the vanishing points (for example, think of the boxes as representing houses along a street, or as building blocks of a complicated shape).
Yes, but I was speaking about a different thing: not dragging of points in the 3d tool but dragging of boxes in selector. If I have 10 boxes sharing the perspective, and with selector I select and drag away 5 of them, this should automatically split the perspective in two, each used by 5 boxes. The main point is to not move objects which I didn't select, it's very wrong.
As for splitting up of perspectives upon applying transformations, check out current SVN, revision #16684. :)
Ah, sorry, didn't notice that - just checked - splitting seems to work. But there's another bug: create 4 boxes, select 2, drag them - they jump to twice the distance I dragged!
As for dragging the perspective points in 3d box tool, I think your approach is OK: drag merged points together (even though this does result in changing objects that are not selected, but I think this is OK), Shift+drag to separate them. I also agree with Mental that adding auto-merge of perspective points when they are dragged close enough, as in the gradient tool, would be logical and convenient.
On Dec 13, 2007 2:23 PM, bulia byak <buliabyak@...400...> wrote:
- drawing and adjusting in 3D box tool indeed work much better now, no
wrong z-order and no weird degenerate shapes anymore
Perhaps I was too optimistic :) rev 16699: draw a box by starting in the middle of page and going up and to the left. As soon as you release mouse, the z-order becomes wrong (though it was correct while dragging).
participants (5)
-
bulia byak -
Gail Carmichael -
Joshua Facemyer / Impressus Art -
Maximilian Albert -
MenTaLguY