I'm here, like several others, because of Google's SoC. I am a Master's student in Mechanical Engineering at Southern Methodist University. I have kept an eye on Inkscape for several years, but I have only rarely had occasion to use it. I, like everyone else here (it seems), am interested in adding facilities that will make Inkscape easier to use to make 3D drawings. Being an engineer, I am also interested in being able to use it to make orthographic drawings. Aside from the 3D box tool, there are several features that might prove useful for 3D drawing:
1) Isometric/Axiometric grid 2) Diagonal guides (converging to a vanishing point) 3) Drawing with a prespecified transformation 4) Make Ctrl-dragging a node observe the object's transformation matrix 5) Perspective transformation (this would require somehow extending SVG's transformation mechanism) 6) Support for snapping non-node corners of rectangles
I would be happy to work on any of these features over the summer. The usefulness of the first two seem obvious (to me), but the rest may take some explaining. Being able to set a transformation before you start drawing would allow you to, for example, set up drawing top faces for an isometric drawing, and have the rectangle tool work properly for those faces. Similarly, it would be useful to have a convenient way to move a node only along the basis vectors of an object's coordinate space, thus moving horizontally and vertically in the conceptual image. In conjunction with the previous two items, a perspective transformation would allow the same manipulations of orthographic images to be applied to perspective images. As for (6), this is usually taken care of by bounding-box snapping, but that doesn't work when the rectangle has undergone a transformation, making its corners not at the corners of its bounding box.
Also, for bug #1674596, would an acceptable replacement for "Export Bitmap..." be "Render to File..."? This seems like an ideal bug for me to figure out the patch submission process because the change is only one line (I think; I haven't been able to test it yet).
-- Eric Sumner
On Tue, Mar 20, 2007 at 12:10:47PM -0500, Eric Sumner wrote:
I'm here, like several others, because of Google's SoC.
Hi Eric! Welcome to the group. :-)
- Isometric/Axiometric grid
There has already been some work in this area, but additional grid types would certainly be a good project.
- Diagonal guides (converging to a vanishing point)
This is something numerous people are interested in seeing, and would make a great GSoC project.
- Drawing with a prespecified transformation
- Make Ctrl-dragging a node observe the object's transformation matrix
- Perspective transformation (this would require somehow extending
SVG's transformation mechanism)
The above are also good ideas, I don't know of anyone working on any of them, but they'd all make significant improvements to Inkscape, particularly #5.
- Support for snapping non-node corners of rectangles
This is something I am very interested in. I've done a little research into it. An approach other drawing apps use is to add "glue points" aka "snap points", as distinct things that can be associated with shapes, and then allow the user to edit them.
Specifically, this would come in handy with the Symbol shape type (which is partly implemented in the Inkscape codebase, but not available for editing from the UI). Symbols are somewhat like clones in that you have one definition of the shape, but can put multiple instances of it in the document; then if you edit the original (say, adding some glue points), then all the instances will be similarly updated.
Anyway, if you're interested in doing glue points, I'd be happy to share the spare notes I've collected and bounce ideas around.
Also, for bug #1674596, would an acceptable replacement for "Export Bitmap..." be "Render to File..."? This seems like an ideal bug for me to figure out the patch submission process because the change is only one line (I think; I haven't been able to test it yet).
Possibly, or another approach could be to change it from exporting directly to PNG, to implement use of gtkpixbuf, which would allow exporting to jpg or other formats. I haven't looked into this too deeply but it looks reasonably straightforward; it's on our roadmap for milestone 17, so would be great to get that done early. :-)
Bryce
On Mar 20, 2007, at 12:50 PM, Bryce Harrington wrote:
- Support for snapping non-node corners of rectangles
This is something I am very interested in. I've done a little research into it. An approach other drawing apps use is to add "glue points" aka "snap points", as distinct things that can be associated with shapes, and then allow the user to edit them.
Specifically, this would come in handy with the Symbol shape type (which is partly implemented in the Inkscape codebase, but not available for editing from the UI). Symbols are somewhat like clones in that you have one definition of the shape, but can put multiple instances of it in the document; then if you edit the original (say, adding some glue points), then all the instances will be similarly updated.
Anyway, if you're interested in doing glue points, I'd be happy to share the spare notes I've collected and bounce ideas around.
I also have some ideas about this. One is using placement similar to that of text on a path.
On 3/20/07, Bryce Harrington <bryce@...961...> wrote:
- Support for snapping non-node corners of rectangles
This is something I am very interested in.
They already snap in SVN since for a week or two, as do all other shape handles (thanks to Diederik's fixes).
On 3/20/07, Eric Sumner <kd5bjo@...400...> wrote:
Aside from the 3D box tool, there are several features that might prove useful for 3D drawing:
- Isometric/Axiometric grid
I think Johan Engelen is already working on it. Johan, can you comment?
- Diagonal guides (converging to a vanishing point)
Yes, and I think it's natural to combine this with the 3D box tool with commands like "create a 3D gridset from this 3D box" or "align the 3D guides with this 3D box".
- Drawing with a prespecified transformation
For shape tools (rect, ellipse, star, spiral) it would make sense. For simple freehand drawing, probably not. Just use 3D grid or guides to snap.
- Make Ctrl-dragging a node observe the object's transformation matrix
Shape handles (i.e. handles on rects, ellipses, etc) already move in the object's local coordinates. So for example, a rotated rect remains rotated as you change it with handles. However, as soon as you convert it to paths, this capability is lost. But I don't think we really need it for nodes. In most cases, moving in local coordinates means moving along some adjacent straight line segments and/or along the bezier handles of a node, and we have a shortcut exactly for that: Ctrl+Alt+drag. So, for example, you can extend or contract a rotated rectangle path by selecting two nodes and Ctrl+Alt+dragging them.
- Perspective transformation (this would require somehow extending
SVG's transformation mechanism)
Absolutely, except that we cannot extend SVG. We must use our own extension attributes/elements and observe the fundamental rule that our SVG must look the same in any SVG viewer.
- Support for snapping non-node corners of rectangles
As for (6), this is usually taken care of by bounding-box snapping, but that doesn't work when the rectangle has undergone a transformation, making its corners not at the corners of its bounding box.
In current SVN, any shape handles snap (and of course they still snap regardless of whether the shape is transformed or not). Try it.
Also, for bug #1674596, would an acceptable replacement for "Export Bitmap..." be "Render to File..."? This seems like an ideal bug for me to figure out the patch submission process because the change is only one line (I think; I haven't been able to test it yet).
I don't like "Render to File...", and I honestly don't see a problem with the current title. Though perhaps we could rename it just "Export PNG" for now.
On 3/20/07, bulia byak <buliabyak@...400...> wrote:
- Support for snapping non-node corners of rectangles
As for (6), this is usually taken care of by bounding-box snapping, but that doesn't work when the rectangle has undergone a transformation, making its corners not at the corners of its bounding box.
In current SVN, any shape handles snap (and of course they still snap regardless of whether the shape is transformed or not). Try it.
Actually, I think this is currently done wrong. If you resize a rotated rectangle by handles, it snaps, but the handle is not on grid. It snaps the same as it would snap unrotated, but with rotation transformation this puts the handle off the grid and thus is not what we need.
Diederik, can you please look into fixing it? It should be easy: instead of snapping the rectangle x/y/w/h values, snap the actual position of the handle, and then obtain the x/y/w/h from that snapped position by applying the rect's transform if any. Same should be done for all other shapes.
On Tue, 2007-03-20 at 17:52 -0400, bulia byak wrote:
On 3/20/07, Eric Sumner <kd5bjo@...400...> wrote:
Aside from the 3D box tool, there are several features that might prove useful for 3D drawing:
- Isometric/Axiometric grid
I think Johan Engelen is already working on it. Johan, can you comment?
- Diagonal guides (converging to a vanishing point)
These two points are one of the same, in that both require drawing lines and snapping to those (angled) lines. Yesterday I committed my new grid infrastructure (classes for example), so now it should be much easier to implement new grids and use them in Inkscape. (really! Mail me any time for questions). I already had some axonometric grid code there, but much has to be improved. Also it does not snap yet.
At the moment a point is snapped to either a guide or a grid. It is not possible to snap to for example a vertical guide line and to a horizontal grid line at the same time; in effect the intersection of the two lines does not snap. A nice fix would be for grids and guides to return snapping lines, and for the snap manager to do the actual snapping to the intersection of the two closest lines (if there are 2 within snapping range). This might be done later, but could also be done up front to simplify snap coding (as it only needs to be done once; a grid will only have to return the lines closest to the point).
I decided to go for live effects for GSoC, which means I guess that, however much I like this topic, I will not be working on this for some time depending on how GSoC goes and how much time I have available.
From my point of view, I think adding a 'drawing mode' with no vanishing
points but with 'full' functionality would be a very nice project: axonometric grid + diagonal guides + dragging along one of the grid axes + ... (?)
Cheers, Johan
participants (5)
-
Bryce Harrington
-
bulia byak
-
Eric Sumner
-
Johan Engelen
-
Jon A. Cruz