Difference between revisions of "Tiling tool"

From Inkscape Wiki
Jump to navigation Jump to search
(Redid the whole interface, now it actually makes sense... Also added new features)
(→‎Implementation: Changes to make more sense from programming POV? (though I may be saying nonsense))
 
(32 intermediate revisions by 3 users not shown)
Line 1: Line 1:
== Tiling guide and dialogue ==
== Tiling tool ==  
The current tiling interface is hard to use. The current interface attempts to make the process more user friendly through the use of a tool that creates a "render frame", which consists of two parts:
* A base tile, where the pattern is supposed to be
* A more general render frame, showing the location of the output
* Both can be edited on-canvas


The current tiling interface is hard to use. The current proposal attempts to solve that by dividing the problem into two parts:
The tiling process is simply:
# Tiling guides (tool): this creates a guide object, which helps the tile creation process and sends coordinates for tiling.
# Create a frame
# Tiling dialogue: where you apply the tiling. In fact, users can add one of 3 options: Pattern Along Path, Radial Tiling, Wallpaper Tiling.
# Select a pattern and a frame
# Click "Render" from the tiling tool


{| class="wikitable"
* By default the frame becomes invisible after a render, and becomes "implied" in the generated output (a bit like clipping?).
* Undoing the render makes the frame appear again.
* The user can choose to drop a copy of the frame after a render for re-use however, or make a copy before applying.
 
{| class="wikitable"  
|+  
|+  
! scope="col" width="180"| Type
! scope="col" width="180"| Type
! scope="col" width="500" | Description
! scope="col" width="700" | Description
|-
|-
! Wallpaper tiling
! Wallpaper tiling
| This tool allows users to use the 17 wallpaper types.
| Allows users to use the 17 wallpaper types.
|-
|-
! Radial tilings
! Radial tiling
| This is for radial designs, and uses radial coordinates.
|  
* This is for radial designs, and allows both angular clones and radial clones.
* For angular clones, users can choose between simple rotation or symmetry + rotation. (thus covering the Rosetta patterns as well)
* For radial clones, users can choose between same direction and alternating directions.
|-
|-
! Clone along path
! Path tiling
| Clones are created along a path. This can be used to create a string of decorations, for repeating frill designs, for page borders etc. Could be called Path tiling?
|  
|}
* Clones are generated along a path. This can be used to create a string of decorations, for repeating frills, for page borders etc.
* Users can choose from all 7 Frieze groups.
|}
 
[[File:Tiling_Tool_Toolbar.png|UI Proposal for tiling tool]]
<br clear="all"/>
 
[[Media:WallpaperTransformations.png | Transformation images for wallpaper groups]]


The tile creation process is quite simple:
== Render modes ==
# Copy a base tile and a guide (optional) to clipboard.
# Select a target to apply the tiling to (you can also just choose the original base tile)
# Open the tiling dialogue ("Shift + Ctrl + C" perhaps, as C stands for clones) and add a tiling type: Pattern along path, Radial Tiling, Wallpaper Tiling
# Choose options and apply.


This proposal also includes an interface that lets you define seamless tiles with edge-tile scenarios using a single base tile.
There are two modes:
* Create clones: This is the current rendering mode
* Fuse: This mode first cuts excess for "inner" sides, then performs a "fuse" operation on the whole output.


[mockup]
[[File:Tiling_cut_excess.png|Explanation of "Fuse" feature for tiling proposal]]
<br clear="all"/>


In case anyone asks why the title is "tiling tool": this is due to a previous version that attempted to stuff even the tiling functions into the toolbar. Let's just say it didn't fit....
[[File:Tiling_interface_examples.png|More examples of the possible outputs for the “Fuse Cut” mode]]
<br clear="all"/>


== The components ==
== Render frame ==


This current proposal is a combination of several separate features that can be programmed separately:
The render frame is made up of:
* A central tile, which defines the location of the pattern to copy
* A more general render grid


# '''Guide management'''. See the existing proposal here: [https://blueprints.launchpad.net/inkscape/+spec/guides-improvement Guide improvement and management Blueprint]. I will assume that in fact, guides are a type of objects that can be:
[[File:Tiling_Tool_Render_Frame.png|UI Proposal for the Render frame of the Tiling tool proposal]]  
#* Grouped with an object (the base tile in fact)
<br clear="all"/>
#* Moved and transformed along with said object (within certain constraints)
# '''Tiling guides''': This allows you to add a type of guide specific for a tiling type (a wallpaper transformation, a radial transformation...):
#* A pop-up will help you choose the type of tiling with visual references
#* Just like any other guide object, they don't have any filters attached. Their only purposes are to:
#*# Help you position your base tile elements and
#*# Communicate certain boundary information to the tiling tool that'd be too painful to input manually
# '''Guide points for seamless connection''' (extra feature on tiling guides): for a wallpaper tile for example, adding a guide point on one side will generate counterparts on all other sides to help you place nodes for seamless transition. This requires the guides themselves to be a bit more complicated though: rather than just objects, they'd have to specify to which other sides they link to and in what direction.
# '''Tiling dialogue''': Here's where you apply a tiling, basically. I chose the dialogue format because tiling is something you may want to edit, but at the same time, you wouldn't want to edit it often enough to justify a separate tool (besides the options wouldn't fit).
#* Extra feature: This could connect to a more general "Add effects" dialogue for stacking effects.
# '''Cut excess''': this feature is actually a simple Cut operation. For "interior" tiles, Inkscape cuts along certain guide lines and deletes the extra. That's it. This will require some fixes to the cut operation and implementation of boolean operations to groups, though:
#* [https://bugs.launchpad.net/inkscape/+bug/166302 Bug #166302: Cut Path looses some segments ]
#* [https://bugs.launchpad.net/inkscape/+bug/171379 Bug #171379: Boolean Operations on Groups ]
#* [https://bugs.launchpad.net/inkscape/+bug/701819 Bug #701819: Copy/Cut a Part of a Grouped Object ] (scenario of above)
#* [https://bugs.launchpad.net/inkscape/+bug/408551 Bug #408551: Cut Path with a grouped object does nothing ]
# '''Fuse paths''': A new mode which is basically just a "select all nodes / join" operation. Combined with "cut exterior" and careful design, this allows you to create seamless tiles while retaining edge scenarios.
# '''Improved interface for dynamics''' : See later. Also has presets.
# '''Pattern management''': I don't know how .svg specifies patterns, but if wallpaper groups are allowed, the user has the option to save the tiling as a pattern or apply it directly as a target  pattern fill (like... a character's t-shirt)
# '''Line pattern management''' : In this feature, Inkscape saves the line pattern properties much like it would for patterns. There could be a dock where you choose all the line patterns you've saved.


Hopefully the above description divides the proposal into more manageable parts. What's more, the different tiling types (wallpaper, radial and clones along path) can be implemented separately.
== On-canvas transformation handles ==


== The tiling guide tool ==
[[File:Tiling_Tool_Transformation_Handles.png|UI proposal for on-canvas handles for the tiling tool proposal]]
<br clear="all"/>


=== Guide types ===
== Guide points ==


When you want to add a new guide type, you click a button that opens a floating window with a list of guides and a visual preview (especially for those confusing wallpaper transformations). We could use the previews created by Thorsten Wilms for Inkscape: [http://thorwil.wordpress.com/2010/08/30/inkscape-tiled-clones/ Inkscape Tiled Clone previews]
[[File:Tiling_Tool_Guides.png|UI proposal for guide points feature for Tiling Tool]]
<br clear="all"/>


The guides fall into the following groups:
Guide points are there to serve as reference point when creating tile designs.
* When you add a guide point, "counterparts" are generated in all the other tiles
* Ctrl-drag to drag out a segment.
* The idea is that users can snap guide points along tile edges, snap a node of the pattern to that guide and snap the node handle to the end of the guide segment, then repeat with the guide point's counterparts. This should help easily create seamless transitions.


{| class="wikitable"
== Option for dynamics Symmetry around base tile? ==
|+
! scope="col" width="180"| Type
! scope="col" width="500" | Description
|-
! scope="row" | Wallpaper tiling
| These guides corresponds to the different wallpaper categories
|-
! scope="row" | Radial tiling
| These are to create radial patterns. They're basically an arc segment with an implicit direction.
|-
! scope="row" | Clones along Path
| This is defined by a central axis, an attach point and 2 tile bounds. The central axis represents the path to which the tile will attach, basically a visual normal offset. The tile attaches to a specific node (say, the first node of the path) from the attach point, basically a visual tangential offset. The two bounds decide where the tile cuts off save for edge scenarios.
|}


[mockup]
Proposal: option for all dynamics to be rendered in a symmetry around the base tile. This proposal is because users may want tiles to fade around a central tile. Rendering the frame in just one direction is easy, but achieving the symmetry otherwise is not.
<br clear="all"/>


The direction matters for a tiling guide: it will decide the direction in which the tiling occurs.
The main difficulty is that the current dynamics mechanism is linear, so adjustments would be needed.


Note: when applying a type of tiling, you do not necessarily have to choose a guide of that type (though Inkscape may still constrain to certain types). You can do a P2 transformation with a P1 guide, for example. However, Inkscape can't guarantee the results in that case.
[[File:Tiling Tool Symmetry.png|Proposal for dynamics to occur in a symmetry around the base tile for the tiling tool]]
<br clear="all"/>


=== Guide editing ===
== On-canvas dynamics editing ==


Guides will actually behave a lot like normal objects. You can scale them and rotate them, duplicate them and even group them with existing objects. They will be managed separately as already proposed in [https://blueprints.launchpad.net/inkscape/+spec/guides-improvement Guide improvement and management Blueprint].
Currently the two following approaches to on-canvas dynamics editing have been considered:
# Edit a tile of the render frame (rotate and resize for example), all other tiles in the render frame are updated dynamically to give you an idea of the result.
#* Pros: high preview value, as the outline of the tiles by themselves should give an idea as to the output of the whole tiling.
#* Cons: forcing live update of tiles may be slow, and big displacements of tiles are distracting from the editing process. Worse if jitters are also visualized on-canvas.
# Edit only one or two "reference" tiles. None of the other tiles change. Inkscape deduces transformation values from there and converts them into values for the existing tiling mechanism.
#* Pros: less taxing on the interface.
#* Cons: Less preview value.


Options in the toolbar will depend on the type of guide. Some of the code at least can be taken from existing tools (rectangle etc). You can also potentially change the type of the guide (?).
Tom Lechner made a possible mock-up for the second option: [http://www.tomlechner.com/randompics/finishing.png Mock-up for on-canvas tile dynamics editing]


This can be a component of a more generalized "guide" tool which also has categories for other types of guides: composition, perspective, etc.
It could be possible to combine the best of both worlds with a "Dynamics preview" mode (so it's a preview of the dynamics, not of the pattern getting tiled):
* When preview mode is on, Inkscape generates a preview of the render frame's tiles with dynamics applied, including jitters.
* Editing is not allowed. You have to exit the preview mode to make other adjustments.
* The idea is that some complex tilings will probably take a long time to render. This preview mode gives a quick idea about the outcome without having to do a full render, then undo, adjust and re-render again.


[mockup]
[[File:Tiling Tool Dynamics Preview Mode.png|Preview mode for dynamics for the Tiling Tool proposal]]
<br clear="all"/>
<br clear="all"/>


Note: The same "Create Guide" floating dialogue can be accessed both from the toolbar of the tile guide tool and from the tiling dialogue:
== Radial tiling ==
* When creating a seamless tile, the user doesn't necessary want to apply a tiling, just create a design.
 
* On the other hand, it should be easy for those creating tiles to find where to make guides. Once a guide is created, double-clicking the guide opens up the guide editing options (so directs you to the tool, basically).
In theory, radial tiling could use the same mechanism as rows and columns tiling, by converting all input into X, Y input. Although users can also use rows and columns tiling to achieve radial tiling, doing so would not be very intuitive.
 
[[File:Tiling Tool Radial Tiling.png|UI proposal for radial tiling in the tiling tool]]
<br clear="all"/>


=== Seamless guide points ===
== Line tiling ==


When a guide point is created on one side of a guide, counterparts are automatically created on all other sides of the basic guide. All changes to the original will be reflected onto the new tile.
Implementing line tiling would be more complicated that implementing radial tiling, because it is an extension of the Pattern Along Path function rather than of the existing tiled clones mechanism. So, the programer would have to figure out a way to combine Pattern Along Path and the dynamics for Tiled Clones, all the while implementing the proper render guide. If he achieves it though, it'd be an amazingly powerful and versatile tool for designers of all kinds.


What's more, you can click and drag this guide to create a guide segment. By snapping a node on a guide point and snapping its handle to the end of the guide segment, and by repeating the operation with the node's counterpart, the user can create smooth transitions from one tile to the next.
Line tiling actually comes in two sets of guides:
* A pattern guide.
* A target guide. This target guide appears over the target path, which has to be copied first to the clipboard.


[mockup]
The pattern guide can actually be edited independently of a target path, but unless a target path is copied to the clipboard, the user cannot render the line tiling. So, the user can first adjust the pattern design and tiling properties, then copy a path, adjust and apply.
<br clear="all"/>


See this [http://www.cgl.uwaterloo.ca/~csk/software/penrose/ javascript program] for an approximate idea of how it'd behave.
[[File:Tiling tool line tiling.png|UI proposal for line tiling in the tiling tool]]
<br clear="all"/>


Note: programming-wise, the guide points don't actually do anything, they're just visual references. When Inkscape creates a "Fuse path" tiling, it just joins the nearest nodes. This means you can introduce slight dynamics and still have lines link up, though Inkscape can't guarantee the results in this case.
== Tile stacking ==


=== Tiling dialogue button ===
You can stack different tilings!


A button in the tile guide tool opens up the Tiling dialogue, which can also be opened on its own (Ctrl+Shift+C perhaps? C for Clones?).
[[File:Tiling stacking.png|Explanation of tile stacking feature for my tiling proposal]] <br clear="all"/>


== The tiling dialogue ==
Inkscape will likely have an Effects stacking mechanism in the future. Whatever it is, tiling would also fit right into it.


[mockups]
== Line patterns ==
<br clear="all"/>


=== Add tiling type ===
And why not "line patterns" while we're at it?


Work sequence:
[[File:Tiling line patterns.png|UI proposal for line pattern choosing]] <br clear="all"/>
# Select a target (optional, if no target is selected then "Tile's current location" is selected, and "fill" options are unavailable)
# Add a tiling type to it: Pattern along Path, Radial or Wallpaper tiling.
#* For Rotate, simple rotate and symmetry + rotate are then available. Symmetry + rotate first creates a symmetry using the guide's first rotation axis, creates a new base tile of double the angle of the original, and applies the radial tiling accordingly.
#* For Wallpapers, all 17 wallpaper groups are then available.


You'll note the "Help" tab. The help tab will have text along the following lines: "To create a tile, copy a tiling and a guide and apply the desired operation. You can find more in-depth explanations of the tilings here: (page created specially for this purpose)"
== UI design status ==


=== Guides ===
This section is a summary of how ready the UI proposal for the various features are (as well as comments about coding):


Guides are optional. If none is selected then Inkscape uses the base tile's bounding box.
'''General concept and tiling methods:'''


{| class="wikitable"  
{| class="wikitable"  
|+ Tool comparisons
|+  
! scope="col" width="180"| Guide
! scope="col" width="180" | Feature
! scope="col" width="500" | Default behaviour
! scope="col" width="600" | Status
|-
! General concept
| Valerie: The current interface is the result of exploring several very different concepts with inputs and criticism by a number of people. The "On-canvas editable central tile + render frame" concept is currently the first of these concepts to have encountered no major objections as to its usability, so it should be safe to consider this an acceptable general direction unless a better proposal comes along.
|-
! Wallpaper tiling
| Valerie: The general proposal (base tile, handles + render frame) doesn't seem to generate many objections. The exact form of the handles and the details about manipulation could still be refined.
|-
! Radial tiling
| Valerie: Not much input yet.
|-
! Line tiling
| Valerie: Not much input yet. There should be, as this is a potentially very powerful feature for designers, though also hard to implement.
|}
 
'''Specific features (all tiling methods)'''
 
{| class="wikitable"
|+
! scope="col" width="180" | Feature
! scope="col" width="600" | Status
|-
! Fuse mode
| Valerie: General input seems to be that this is a "good idea."
|-
! Guide points
| Valerie: General input seems to be that this is a "good idea."
|-
! On-canvas handling of dynamics
| Valerie: Concensus is that on-canvas manipulation of dynamics is very desirable. However, the exact form is still up to debate. Tom Lechner has a proposal that will allow to visualize most elements, but more work is needed to establish a mechanism for visualizing and controlling jitter as well.
|-
|-
! scope="row" | None selected
! Multi-Stop Interpolation Gradient (multi-stop dynamics)
| Inkscape uses the object's bounds
| Valerie: Such a mechanism would require reworking the entire tiling mechanism. The only bright side is that Inkscape doesn't store any tiling information, so changing the mechanism won't break backwards compatibility. See Jasper's detailed comment in "Implementation."
|-
|-
! scope="row" | One guide selected
! Symmetrical dynamics output around base tile
| Inkscape uses the one guide selected
| Valerie: Looking at Jasper's explanation below, symmetrical dynamics around a central tile basically aren't supported by the current mechanism.
|-
|-
! scope="row" | Multiple guides selected
! Tile stacking and line pattern management
| Choose the right one from the drop-down box that's there for this purpose
| Valerie: At this point both are just suggestions, as Inkscape has neither the mechanisms in place nor an UI.
|}
 
'''Implementation comments'''
 
{| class="wikitable"
|+
! scope="col" width="180" | Feature
! scope="col" width="600" | Comments
|-
! Multi-Stop Interpolation Gradient
| Jasper (mail from mailing list): All the code is in src/ui/dialog/clonetiler.cpp. The main function is CloneTiler::clonetiler_get_transform. This function essentially gets all info, as well as a row and column index. It then computes all the transforms required for that position and combines them. As far as I can tell it combines them in such a way that first a scaling is applied, then a rotation and finally a translation. If you select a different symmetry group then the translation can become a more complicated transform.
 
The scheme we talked about earlier that would interpolate transforms is not necessarily compatible. This is because in the latter the case the entire transform would be interpolated, while what Inkscape does is essentially interpolating per kind of transform. That this is not the same can be seen by realizing that rotate(50)translate(1)rotate(50)translate(1) is not the same as rotate(100)translate(2). The former is more or less what we talked about (or at least what I had in mind during that discussion), the latter is what Inkscape does.
 
However, Inkscape currently seems to store almost nothing about the tiling in the file. So it would be relatively benign to change behaviour. Existing files would not be affected in any way, users would only be affected when trying to change a tiling or create a new one. (This is not to say that it's necessarily a good idea to make it impossible to achieve the current behaviour, just that if we cannot reconcile the two, there is some room for change.)
 
Note that it would be possible to emulate Inkscape's current behaviour through interpolation of transforms, but only if we would allow "stacking" transforms. I'm not sure how this would have to be supported UI-wise though.
|}
|}


=== Mode ===
== Implementation ==
 
Proposed implementation steps:
 
=== 0. Very desirable: Guide management ===
 
See [https://blueprints.launchpad.net/inkscape/+spec/guides-improvement Existing blueprint]. Rather, what is needed here is not a full guide management system, but rather how to "define" a guide, as the guides here have properties very different from "normal" objects.
 
=== I. Core feature: addition of an on-canvas base tile or render frame ===
 
Jasper explains where the tiling code is located:


One of 3 modes are available:
"All the code is in src/ui/dialog/clonetiler.cpp. The main function is CloneTiler::clonetiler_get_transform. This function essentially gets all info, as well as a row and column index."
* Create group of copies
* Create group of clones
* Fuse path


Fuse path selects all the nodes in all the tiles and makes a "join" operation. If the user chose to make seamless tiles beforehand, the result would be seamlessly joined tiles.
As a first step, the programmer could program a "base tile" or "render frame" object as a separate file, that can be tested independently from the tiling code. This object:
* Provides a different base tile shape depending on the chosen transformation type
* Allows to visualize extra rows and columns on-canvas (not necessary in a first step, but quite desirable). Unless the user wants to tweak the tiling code itself, this step currently does not allow adding or removing individual tiles
* Creates a set of coordinates to be used by the existing tiling mechanism
* The tool icon and toolbar can be created from the start for testing or added later


=== Target ===
Testing would basically be to ensure that the on-canvas behaviour is consistent with what the user expects, and the output values are correct.


"Target" determines where you render your tiling.
Once this object works as expected, it can then be "connected" to the tiling mechanism by calling it up and sending it the correct values. Basically, the tiling code itself would not need too many adjustments at this phase.  


For wallpaper tiling:
[[File:Tiling Tool Step1.png|UI Proposal for first step of tiling tool implementation]]
* Tile's current location: render tiling where the base tile is.
<br clear="all"/>
* Over selected object: Covers an area, a rectangle for example. But can be anything.
* Inside selected object: Since a base tile has edges that can make the final result bigger than the selected area, this option forces the whole result to be no bigger than the desired area.
* Border around selected: option to easily make page borders?
* As pattern to selected object: if svg somehow allows it, the pattern becomes the selected object's fill pattern.
* As new pattern: a name pops up, asking you the name of the new pattern.


For radial tiling:
This is basically the minimum interface that would allow users to make basic tiling without opening the current tiling dialogue. Sequence:
* I think people usually want to define a radial tile just where the base tile is, but I could be wrong.
* Clicking the + button "adds" a render frame or just render tile (if the programmer hasn't programmed the ability to visualize extra rows and columns yet) of the chosen type.
* Choose the pattern to tile and the guide
* Click "create"


For Clones along path: (a separate path Must be selected before applying)
=== II. More features to the render frame ===
* On selected Path. Note: this can be a closed path.
* As selected path's line pattern: takes the selected path and makes the Clones along path its new pattern.
These are features that can be added to the render frame object without changing the tiling code too much.
* As new line pattern: if clone patterns can somehow be saved somewhere.
''' 1. Tiling handles '''
# Handles are added to the base tiles, making it possible to switch from one tiling to another.
# Users can be now offered to create a "Wallpaper" tile by default. Other transformation types are accessed via a pop-up when choosing "others." Previews are moved to this pop-up. Since the simple rectangle is the most commonly used tile shape, this default should be acceptable (and less confusing than "P1").


What's more, for Clones along path, you can choose from several "start" options:
A few notes:
* Path start: the first node of the path.
* Changing symmetries should be the priority.  
* Path end: the last node of the path.
* Eventually controls for angles could be added too, though this is lower priority, as not many users absolutely need to change from one tile shape to another.  
* Selected node


The orientation of the guide matters, so if you want to change tile directions, you can flip the guide. All tiling options also have a "both directions" option. In the case of Pattern along Path, for example, you can "fan out" from a selected node, and in the case of Wallpaper tiling, your tiles can shrink as they get further away from the center.
''' 2. On-canvas dynamics editing '''
This converts on-canvas cues to percentage values that are then fed to the tiling code.
Under discussion: Visual representation of the mechanism?


=== Exclude excess for interior tiles option ===
''' 3. Guide points? '''
The programmer must:
# Define/create guide points. This object can be snapped to objects and guides.
# Program it so that iterations of it appear and are rendered correctly in each tile of the render frame according to the chosen transformation mode. If the transformation type is changed, they must also update automatically.
# Additional feature: Ctrl-drag to create a segment from the point: this helps make transformations in each tile more obvious, and helps for handle-snapping.


This is in fact a simple cut operation followed by a deletion of "excess" for "inner" tiles:
''' 4. Radial tiling cheat? '''


[mockup]
A "radial tiling" guide form may be created on top of the existing mechanism. It's basically a P1 operation made to output radial tiling results. The render frame shsape allows users to more easily visualize radial tiling on-canvas. Any on-canvas dynamics manipulations also converts these values into settings appropriate for a "rows and columns" transformation.
<br clear="all"/>
 
By building this on top of the existing tiling mechanism, the programmer removes the need to create a dynamics system specific to radial tiling. On the down side, a user who wants to input values manually will have to deal with the rows and columns settings, which in this case would be less intuitive than "angular and radial" settings.
 
=== III. More tiling features ===
 
'''  1. Fuse mode '''
 
As noted, this is a cut + fuse operation. The programmer needs to implement the following features:
# Boolean operations (specifically "cut") on groups
# This also means fixing the cut operation, which is currently rather buggy...
# The guides must be extended, and for each wallpaper group, the ways to "cut" the tiles must be defined
# The programmer must then find the way to define the zone to be delete
# "Fuse" uses the existing group node join operation however
Alternatively, the programmer can make Inkscape render a shape over the tile and perform a union operation, but one that leaves resulting nodes instead of joining them.
** [https://bugs.launchpad.net/inkscape/+bug/166302 Bug #166302: Cut Path looses some segments ]
** [https://bugs.launchpad.net/inkscape/+bug/171379 Bug #171379: Boolean Operations on Groups ]
** [https://bugs.launchpad.net/inkscape/+bug/701819 Bug #701819: Copy/Cut a Part of a Grouped Object ] (scenario of above)
** [https://bugs.launchpad.net/inkscape/+bug/408551 Bug #408551: Cut Path with a grouped object does nothing ]
 
This feature requires adding two additional phases to the tiling code:
* A cut operation: the programmer must find a way to define which way the base tile is to be cut
* Fuse operation at the very end
 
''' 2. Allow adding and removing individual tiles to the render frame '''
 
The biggest work here is reworking the tiling code so that not all tiles are rendered. Combining this and "fuse path" will take some work.


When combined with guides for the creation of seamless tiles, you can easily obtain seamlessly joined tiles.
''' 3. Interpolation gradients? '''


This option is available to all tiling types.
As Jasper noted, this may require a whole rework of the tiling mechanism.


=== Advanced transformation options ===
=== IV. Line tiling ===


The "Dynamics" button opens up a separate dialogue with transformation options corresponding to the current tiling interface. Major differences are:
Line tiling requires a whole new mechanism combining dynamics and "pattern along path." A possible behaviour is:
* Vertical listing
* The programmer adapts the tiling code to the Frieze groups
* Checkbox next to every transformation type, so users can easily remove all of them while retaining some values.
* Clones are first generated in a straight line according to number and size inputs from the target path
* Radial Clones use Polar coordinates.
* They are then set along the target path using "pattern along path" mechanism.
* Clones along Path use orthogonal coordinates (normal and orthogonal).
* Users can save and use presets. This includes a "No dynamics" option.
Originally I pondered whether presets should be located at the "Advanced" level or at the top level (i.e. presets include tiling type). But I reason that dynamics such as fading and color hues for example work about the same no matter what tiling type you're using.


[[File:Tiling_advanced.png|thumb|left|700px|UI Proposal for tiling tool dynamics]]
[[Category:Proposals]]
<br clear="all"/>

Latest revision as of 07:54, 9 April 2012

Tiling tool

The current tiling interface is hard to use. The current interface attempts to make the process more user friendly through the use of a tool that creates a "render frame", which consists of two parts:

  • A base tile, where the pattern is supposed to be
  • A more general render frame, showing the location of the output
  • Both can be edited on-canvas

The tiling process is simply:

  1. Create a frame
  2. Select a pattern and a frame
  3. Click "Render" from the tiling tool
  • By default the frame becomes invisible after a render, and becomes "implied" in the generated output (a bit like clipping?).
  • Undoing the render makes the frame appear again.
  • The user can choose to drop a copy of the frame after a render for re-use however, or make a copy before applying.
Type Description
Wallpaper tiling Allows users to use the 17 wallpaper types.
Radial tiling
  • This is for radial designs, and allows both angular clones and radial clones.
  • For angular clones, users can choose between simple rotation or symmetry + rotation. (thus covering the Rosetta patterns as well)
  • For radial clones, users can choose between same direction and alternating directions.
Path tiling
  • Clones are generated along a path. This can be used to create a string of decorations, for repeating frills, for page borders etc.
  • Users can choose from all 7 Frieze groups.

UI Proposal for tiling tool

Transformation images for wallpaper groups

Render modes

There are two modes:

  • Create clones: This is the current rendering mode
  • Fuse: This mode first cuts excess for "inner" sides, then performs a "fuse" operation on the whole output.

Explanation of "Fuse" feature for tiling proposal

More examples of the possible outputs for the “Fuse Cut” mode

Render frame

The render frame is made up of:

  • A central tile, which defines the location of the pattern to copy
  • A more general render grid

UI Proposal for the Render frame of the Tiling tool proposal

On-canvas transformation handles

UI proposal for on-canvas handles for the tiling tool proposal

Guide points

UI proposal for guide points feature for Tiling Tool

Guide points are there to serve as reference point when creating tile designs.

  • When you add a guide point, "counterparts" are generated in all the other tiles
  • Ctrl-drag to drag out a segment.
  • The idea is that users can snap guide points along tile edges, snap a node of the pattern to that guide and snap the node handle to the end of the guide segment, then repeat with the guide point's counterparts. This should help easily create seamless transitions.

Option for dynamics Symmetry around base tile?

Proposal: option for all dynamics to be rendered in a symmetry around the base tile. This proposal is because users may want tiles to fade around a central tile. Rendering the frame in just one direction is easy, but achieving the symmetry otherwise is not.

The main difficulty is that the current dynamics mechanism is linear, so adjustments would be needed.

Proposal for dynamics to occur in a symmetry around the base tile for the tiling tool

On-canvas dynamics editing

Currently the two following approaches to on-canvas dynamics editing have been considered:

  1. Edit a tile of the render frame (rotate and resize for example), all other tiles in the render frame are updated dynamically to give you an idea of the result.
    • Pros: high preview value, as the outline of the tiles by themselves should give an idea as to the output of the whole tiling.
    • Cons: forcing live update of tiles may be slow, and big displacements of tiles are distracting from the editing process. Worse if jitters are also visualized on-canvas.
  2. Edit only one or two "reference" tiles. None of the other tiles change. Inkscape deduces transformation values from there and converts them into values for the existing tiling mechanism.
    • Pros: less taxing on the interface.
    • Cons: Less preview value.

Tom Lechner made a possible mock-up for the second option: Mock-up for on-canvas tile dynamics editing

It could be possible to combine the best of both worlds with a "Dynamics preview" mode (so it's a preview of the dynamics, not of the pattern getting tiled):

  • When preview mode is on, Inkscape generates a preview of the render frame's tiles with dynamics applied, including jitters.
  • Editing is not allowed. You have to exit the preview mode to make other adjustments.
  • The idea is that some complex tilings will probably take a long time to render. This preview mode gives a quick idea about the outcome without having to do a full render, then undo, adjust and re-render again.

Preview mode for dynamics for the Tiling Tool proposal

Radial tiling

In theory, radial tiling could use the same mechanism as rows and columns tiling, by converting all input into X, Y input. Although users can also use rows and columns tiling to achieve radial tiling, doing so would not be very intuitive.

UI proposal for radial tiling in the tiling tool

Line tiling

Implementing line tiling would be more complicated that implementing radial tiling, because it is an extension of the Pattern Along Path function rather than of the existing tiled clones mechanism. So, the programer would have to figure out a way to combine Pattern Along Path and the dynamics for Tiled Clones, all the while implementing the proper render guide. If he achieves it though, it'd be an amazingly powerful and versatile tool for designers of all kinds.

Line tiling actually comes in two sets of guides:

  • A pattern guide.
  • A target guide. This target guide appears over the target path, which has to be copied first to the clipboard.

The pattern guide can actually be edited independently of a target path, but unless a target path is copied to the clipboard, the user cannot render the line tiling. So, the user can first adjust the pattern design and tiling properties, then copy a path, adjust and apply.

UI proposal for line tiling in the tiling tool

Tile stacking

You can stack different tilings!

Explanation of tile stacking feature for my tiling proposal

Inkscape will likely have an Effects stacking mechanism in the future. Whatever it is, tiling would also fit right into it.

Line patterns

And why not "line patterns" while we're at it?

UI proposal for line pattern choosing

UI design status

This section is a summary of how ready the UI proposal for the various features are (as well as comments about coding):

General concept and tiling methods:

Feature Status
General concept Valerie: The current interface is the result of exploring several very different concepts with inputs and criticism by a number of people. The "On-canvas editable central tile + render frame" concept is currently the first of these concepts to have encountered no major objections as to its usability, so it should be safe to consider this an acceptable general direction unless a better proposal comes along.
Wallpaper tiling Valerie: The general proposal (base tile, handles + render frame) doesn't seem to generate many objections. The exact form of the handles and the details about manipulation could still be refined.
Radial tiling Valerie: Not much input yet.
Line tiling Valerie: Not much input yet. There should be, as this is a potentially very powerful feature for designers, though also hard to implement.

Specific features (all tiling methods)

Feature Status
Fuse mode Valerie: General input seems to be that this is a "good idea."
Guide points Valerie: General input seems to be that this is a "good idea."
On-canvas handling of dynamics Valerie: Concensus is that on-canvas manipulation of dynamics is very desirable. However, the exact form is still up to debate. Tom Lechner has a proposal that will allow to visualize most elements, but more work is needed to establish a mechanism for visualizing and controlling jitter as well.
Multi-Stop Interpolation Gradient (multi-stop dynamics) Valerie: Such a mechanism would require reworking the entire tiling mechanism. The only bright side is that Inkscape doesn't store any tiling information, so changing the mechanism won't break backwards compatibility. See Jasper's detailed comment in "Implementation."
Symmetrical dynamics output around base tile Valerie: Looking at Jasper's explanation below, symmetrical dynamics around a central tile basically aren't supported by the current mechanism.
Tile stacking and line pattern management Valerie: At this point both are just suggestions, as Inkscape has neither the mechanisms in place nor an UI.

Implementation comments

Feature Comments
Multi-Stop Interpolation Gradient Jasper (mail from mailing list): All the code is in src/ui/dialog/clonetiler.cpp. The main function is CloneTiler::clonetiler_get_transform. This function essentially gets all info, as well as a row and column index. It then computes all the transforms required for that position and combines them. As far as I can tell it combines them in such a way that first a scaling is applied, then a rotation and finally a translation. If you select a different symmetry group then the translation can become a more complicated transform.

The scheme we talked about earlier that would interpolate transforms is not necessarily compatible. This is because in the latter the case the entire transform would be interpolated, while what Inkscape does is essentially interpolating per kind of transform. That this is not the same can be seen by realizing that rotate(50)translate(1)rotate(50)translate(1) is not the same as rotate(100)translate(2). The former is more or less what we talked about (or at least what I had in mind during that discussion), the latter is what Inkscape does.

However, Inkscape currently seems to store almost nothing about the tiling in the file. So it would be relatively benign to change behaviour. Existing files would not be affected in any way, users would only be affected when trying to change a tiling or create a new one. (This is not to say that it's necessarily a good idea to make it impossible to achieve the current behaviour, just that if we cannot reconcile the two, there is some room for change.)

Note that it would be possible to emulate Inkscape's current behaviour through interpolation of transforms, but only if we would allow "stacking" transforms. I'm not sure how this would have to be supported UI-wise though.

Implementation

Proposed implementation steps:

0. Very desirable: Guide management

See Existing blueprint. Rather, what is needed here is not a full guide management system, but rather how to "define" a guide, as the guides here have properties very different from "normal" objects.

I. Core feature: addition of an on-canvas base tile or render frame

Jasper explains where the tiling code is located:

"All the code is in src/ui/dialog/clonetiler.cpp. The main function is CloneTiler::clonetiler_get_transform. This function essentially gets all info, as well as a row and column index."

As a first step, the programmer could program a "base tile" or "render frame" object as a separate file, that can be tested independently from the tiling code. This object:

  • Provides a different base tile shape depending on the chosen transformation type
  • Allows to visualize extra rows and columns on-canvas (not necessary in a first step, but quite desirable). Unless the user wants to tweak the tiling code itself, this step currently does not allow adding or removing individual tiles
  • Creates a set of coordinates to be used by the existing tiling mechanism
  • The tool icon and toolbar can be created from the start for testing or added later

Testing would basically be to ensure that the on-canvas behaviour is consistent with what the user expects, and the output values are correct.

Once this object works as expected, it can then be "connected" to the tiling mechanism by calling it up and sending it the correct values. Basically, the tiling code itself would not need too many adjustments at this phase.

UI Proposal for first step of tiling tool implementation

This is basically the minimum interface that would allow users to make basic tiling without opening the current tiling dialogue. Sequence:

  • Clicking the + button "adds" a render frame or just render tile (if the programmer hasn't programmed the ability to visualize extra rows and columns yet) of the chosen type.
  • Choose the pattern to tile and the guide
  • Click "create"

II. More features to the render frame

These are features that can be added to the render frame object without changing the tiling code too much.

1. Tiling handles

  1. Handles are added to the base tiles, making it possible to switch from one tiling to another.
  2. Users can be now offered to create a "Wallpaper" tile by default. Other transformation types are accessed via a pop-up when choosing "others." Previews are moved to this pop-up. Since the simple rectangle is the most commonly used tile shape, this default should be acceptable (and less confusing than "P1").

A few notes:

  • Changing symmetries should be the priority.
  • Eventually controls for angles could be added too, though this is lower priority, as not many users absolutely need to change from one tile shape to another.

2. On-canvas dynamics editing

This converts on-canvas cues to percentage values that are then fed to the tiling code. Under discussion: Visual representation of the mechanism?

3. Guide points?

The programmer must:

  1. Define/create guide points. This object can be snapped to objects and guides.
  2. Program it so that iterations of it appear and are rendered correctly in each tile of the render frame according to the chosen transformation mode. If the transformation type is changed, they must also update automatically.
  3. Additional feature: Ctrl-drag to create a segment from the point: this helps make transformations in each tile more obvious, and helps for handle-snapping.

4. Radial tiling cheat?

A "radial tiling" guide form may be created on top of the existing mechanism. It's basically a P1 operation made to output radial tiling results. The render frame shsape allows users to more easily visualize radial tiling on-canvas. Any on-canvas dynamics manipulations also converts these values into settings appropriate for a "rows and columns" transformation.

By building this on top of the existing tiling mechanism, the programmer removes the need to create a dynamics system specific to radial tiling. On the down side, a user who wants to input values manually will have to deal with the rows and columns settings, which in this case would be less intuitive than "angular and radial" settings.

III. More tiling features

1. Fuse mode

As noted, this is a cut + fuse operation. The programmer needs to implement the following features:

  1. Boolean operations (specifically "cut") on groups
  2. This also means fixing the cut operation, which is currently rather buggy...
  3. The guides must be extended, and for each wallpaper group, the ways to "cut" the tiles must be defined
  4. The programmer must then find the way to define the zone to be delete
  5. "Fuse" uses the existing group node join operation however

Alternatively, the programmer can make Inkscape render a shape over the tile and perform a union operation, but one that leaves resulting nodes instead of joining them.

This feature requires adding two additional phases to the tiling code:

  • A cut operation: the programmer must find a way to define which way the base tile is to be cut
  • Fuse operation at the very end

2. Allow adding and removing individual tiles to the render frame

The biggest work here is reworking the tiling code so that not all tiles are rendered. Combining this and "fuse path" will take some work.

3. Interpolation gradients?

As Jasper noted, this may require a whole rework of the tiling mechanism.

IV. Line tiling

Line tiling requires a whole new mechanism combining dynamics and "pattern along path." A possible behaviour is:

  • The programmer adapts the tiling code to the Frieze groups
  • Clones are first generated in a straight line according to number and size inputs from the target path
  • They are then set along the target path using "pattern along path" mechanism.