Re: [Inkscape-devel] New tiling interface proposal
The unclump option is already in the align and distribute dialog.
So... should I add it or not?
This might give some problems when used with the fuse cut method (with or without borders). In principle the user can obviously create a design based on a rectangular tile, but this might not be the most natural.
You mean edge scenarios right? It shouldn't be a problem for inner tiles, since you can just duplicate the pattern to fill the missing part, and Inkscape will still cut it more or less correctly.
How about this? You can skew, but if you mess with the handles, the tile snaps to 90 degrees angle again. It becomes skewed again if you go back to P1 or P2.
(I don't envy the person who wants to try to program the tiles...)
This reasoning is partly correct, and I agree that this would definitely not be a "must". On the other hand, I think that some changes might be quite logical, so at some point it might be nice to have the option.
Hmm... I'll leave it in the design as a "really low priority feature", and we can just wait and see if anybody actually requests the feature one day.
Partially. One of the things that would make interpolation work really well with tiled clones is that they are conceptually laid out in a grid
True. Leaving dynamics out made the design conception much easier, but I realized that having to go back and add dynamics separately would be annoying in the end. Here's what I propose:
http://postimage.org/image/4235075wd/
The solution is that little dot thing in the corner of each frame. Initially I was worried that it'd get in the way, but then I realized that until rendering is done, those frames are empty anyway. They're also invisible outside of the render mode.
Each dot offers a visual representation of opacity, blur and HLS. Mouse-over gives exact values. Double-click to define exact values.
At this point I hope the programing folks can answer a few questions about interpolation:
1. It is possible to define interpolation over both rows And columns using just a start tile and a reference tile (example: a base tile at the upper-left and a reference tile and the bottom-right). The current tiling dialogue forces you to define changes for both Rows and Columns. Though, in that scenario, maybe Inkscape just divides the values over Rows and Columns (I still need to make sure though that users don't need to choose two reference tiles besides the base tile).
2. Could each render tile in fact be considered more or less like an independent tile? Like, should we have the option to allows the user to break a tile apart and drag it around independently? (internally, Inkscape would still keep track of their row and column value, so users could still use some mechanism to select a whole row for example)
On 29-03-12 10:59, Valerie wrote:
The unclump option is already in the align and distribute dialog.
So... should I add it or not?
I wouldn't. If it turns out to be really handy to have it explicitly linked with tilings as well, then it should probably be just a matter of creating another button that does the same thing as the button in the align and distribute dialog. (I haven't double checked that the really do the same thing, but I can't imagine what could be different.)
This might give some problems when used with the fuse cut method (with or without borders). In principle the user can obviously create a design based on a rectangular tile, but this might not be the most
natural.
You mean edge scenarios right? It shouldn't be a problem for inner tiles, since you can just duplicate the pattern to fill the missing part, and Inkscape will still cut it more or less correctly.
How about this? You can skew, but if you mess with the handles, the tile snaps to 90 degrees angle again. It becomes skewed again if you go back to P1 or P2.
(I don't envy the person who wants to try to program the tiles...)
Hmm... Perhaps it's best to just leave this for now. It's only in the fuse (cut) method(s) that this matters, and it might be best to start simple and see whether it becomes necessary to make it more complicated.
Partially. One of the things that would make interpolation work really well with tiled clones is that they are conceptually laid out in a grid
True. Leaving dynamics out made the design conception much easier, but I realized that having to go back and add dynamics separately would be annoying in the end. Here's what I propose:
http://postimage.org/image/4235075wd/ ...
Each dot offers a visual representation of opacity, blur and HLS. Mouse-over gives exact values. Double-click to define exact values.
This looks a bit (too) free form, but if that's just to show different options, that's fine. So then essentially the behaviour would be that if you change a tile in the "tiling mode", you change all tiles, while if you change a tiled clone using the normal tools, you only change that tile? If not, what would be the point in having these two separate ways of doing things? (In fact, in light of your second question below and my answer to it, I think it might not make that much sense.)
At this point I hope the programing folks can answer a few questions about interpolation:
- It is possible to define interpolation over both rows And columns
using just a start tile and a reference tile (example: a base tile at the upper-left and a reference tile and the bottom-right). The current tiling dialogue forces you to define changes for both Rows and Columns. Though, in that scenario, maybe Inkscape just divides the values over Rows and Columns (I still need to make sure though that users don't need to choose two reference tiles besides the base tile).
I've been thinking about this, and I think the most natural method would probably be to act more or less like a gradient does, so the start tile would be the first stop, and the reference tile the last. So if they are both on the same row, then all tiles within a column have the same value. This should also translate very directly to what Inkscape currently uses.
The underlying assumption is that the interpolation is (effectively) linear, like with a gradient. It is then sufficient to have the values at two points, in combination with the assumption that the "isolines" run perpendicular to the line through both points given. Alternatively, you can use the values at three points.
However, this is assuming you are interpolating a single quantity. In principle, if you are interpolating multivariate data (like colors or transforms), then you'd either want to be able to set up the interpolation per component (this is essentially what Inkscape currently does), or take three values into account.
In short, for things like transforms, you probably want to allow three values to be set (so two reference frames). However, I haven't checked yet whether this is compatible with what Inkscape currently does (whether we can specify the same transforms or more), and I would recommend also allowing just one reference frame (is less flexible, but probably already matches a lot of cases).
- Could each render tile in fact be considered more or less like an
independent tile? Like, should we have the option to allows the user to break a tile apart and drag it around independently? (internally, Inkscape would still keep track of their row and column value, so users could still use some mechanism to select a whole row for example)
In principle it could. Basically you can consider each tile as a transformed version of the original tile. If you can somehow distinguish between the transform applied to it by the tiling and the additional transform applied by the user, then yes, you can allow what you describe. (Might also be useful for things like jitter, and "undoing" such transforms.)
Hi, (I'm the guy who made that alignment tool video)
Let me just say I've been dying for years for the Inkscape tiling dialog to get some much needed attention, and thank you Valerie (and everyone else) for fleshing out so much about this. Simply figuring out the dizzying requirements of this as a tool is huge. The fuse tiling mode is exciting!
Being able to "draw" out which tiles get rendered is good. It would be nice to use a tile pattern to fill areas, but until wallpaper groups are part of SVG patterns, how about the tracing acting like a lasso select, trace out a closed path and create enough tiles to fill? Drag out an open path would still just add tiles to whatever tile edges you cross, control-cross-over-edge remove the tile you were just in? For fuse mode, this could get quite interesting if your tile render area has holes (not simply-connected in math speak)!
I would strongly encourage live preview to be a part of this. Tilings are complicated enough, and being able to visualize on the fly is quite important. If dynamics adjustments are allowed, these then are simply previewed. Perhaps have a live preview toggle.
Skew is important at least for P1. With other groups, skew breaks the actual symmetry, unlike p1. A p1 example where skew is essential: http://www.tomlechner.com/randompics/skew.png
For dynamic adjustments, having a separate tool to do this (or combined in a distribute tool) sounds good, as long as it can still be accessed easily during the tiling phase. Jasper suggested a kind of keyframing dynamics? There is potential there! That way (as Valerie suggested), most things, like color, blur, opacity, size, offset position, can be adjusted with existing line style controls, then (perhaps selectively) grab a keyframe of the settings. For random jitter, maybe draw little wub wub marks near the tile, drag to make more or less random? Perhaps a toggle for having tile controls OR dynamics controls on the canvas (if they take up too much room to have both at once)?
If you allow stacking different dynamics adjustments, the hard part then is distinguishing on screen how the rather large number of possible adjustments map to the tiles. I have yet to hit on an adequate way to do this in my own alignment tool, but gradient style keyframing strips (applied by rows, columns, linear or elliptical fashion) might be the preferred direction!
So a toolbar could look like this with everything else on canvas: [fuse mode v] [tiling group v] [live preview toggle] [tile/dynamics control toggle]
Managing guide points could just be a matter of clicking on the cell outline, with a hover status message saying "double click to add point" or something? To be really clever, one could float representative icons strategically on the canvas, and allow changing by clicking the floating icons, or with a context menu. Then you don't need a toolbar at all!
The distinction between Plain/clip/fuse/fuse cut is only relevant when the original object extends outside the initial cell. In that light, not sure if the Clip and Fuse would be all that useful of modes. Plain and fuse-cut might do it from my point of view. If that is reasonable, then that could simply be an on-canvas toggle.
I don't see why radial tiling need be separate from path tiling. To set a radial tile as proposed, you need to edit the original path very carefully as to fit in the radial tiling cell. It might be easier just to adjust a common rectangular object, then warp into a wedge to fit a circle (or along path). Start, stop, and aligning on the path (or circle) could all be done (as with my align tool) by pushing around little controls. Sometimes, though, adjustments only within plus or minus 1% are not good enough! Something I'm toying with is when you click and/or move those little controls, there would be a "detail obsessed" toggle to hover a number nearby indicating the new value. Click on the hovering number to enter a new, more precise value.
-Tom
PS. and what about Penrose tilings?
You know what? Forget about modifying individual tiles. Users can modify individual pieces after rendering.
Here's the general concept for dynamics:
1. (Double?-)Click on any other tile besides the base tile.
(note: although the frame look empty, they will be considered filled objects when selecting and modifying, so you don't have to pick the edges).
2. Modify the angle, size etc. of that tile by dragging its transform handles. Move the tile for shifting. The corresponding values of all the other tiles in the render frame will also automatically be modified via some sort of interpolation. (may take some time to render, but since they're just frames it shouldn't take too long)
3. Use Ctrl- drag handles to constrain to row values. Shift- drag to constrain to column values. For radial tiling, they'd be constrained to angular and radial values.
4. Alt-drag the same handles to add jitter: drag right to add, drag-left to remove.
So now the only dynamics still needed in the toolbar are trace + Blur, Opacity, Hue, Saturation and Lightness. BOHSL will appear as tools, a bit like tweak tools. Just drag over any frame with it after selecting it with double-click. The ctrl, shift and alt modifiers still apply.
(same as last mail:) http://postimage.org/image/4235075wd/
The "result" will be "visible" thanks to that little sphere in the corner.
And hopefully we're a step closer to stuffing a 7-tabbed dialogue into one toolbar!
Jasper: I only saw your reply after I finished this current one. I'll remove the unclump button (besides, fuse tile renders 1 object, and I think the normal tiling can be made to render just a normal group of objects, so you can just ungroup).
I can also consider your "gradient" approach. Basically render frame will come with two reference tiles which will be connected to the base tile with a line (to look a bit like a gradient line). You can move it to another tile, but they will still be constrained to row/column. So, you modify these two tiles specifically.
This would save up the use of a few modifiers. I think I'll put up a mock-up for each and ask again which one people prefer.
The interface will likely be more complicated for P3 transformation and such. Then again, I never did understand how "rows and columns" worked for those. : (
participants (3)
-
Jasper van de Gronde -
Tom Lechner -
Valerie