GNOME Bugzilla – Bug 392613
seamless texture painting: draw tool "warping across" image border
Last modified: 2018-05-24 12:07:14 UTC
Summary and Description: For painting seamless tileable images for use as textures it would be good to have a checkbox option "warp pointer" in at least pencil and brush tool to have the following behavior activated: Situation: - An image window shows an image - The zoom level lets the image be smaller than the display area Procedure: - A draw is started by starting to hold down the mouse button inside the image area - A draw is performed by dragging the mouse - The pointer leaves the display area - Now, instead of discarding any modification at coordinate x,y occuring outside the drawable area, the modifications should apply to x mod dimx, y mod dimy of the image, i.e. modulo the x resp. y dimensions of the image. Notes and Reference: - See blender's UV image editor, paint tool, "warp" button for an implementation of this behavior, where I also took the term "warping" from. Thanks in advance for any efforts on this and apologies if this already exists and I am unaware of it.
Bug 327175 is about a similar feature.
Looks like a duplicate of bug #327175 even. We would certainly not implement both. Actually, we will certainly not implement any of this. But we might accept a patch that implements it.
Just my 2c here: Aside from which one (if any) gets implemented ... I wouldn't agree that it's an exact duplicate, since in this bug you don't actually _see_ the seam, so you still need to offset the image.
The question is not which is an exact duplicate of the other, but which suggestion is considered better and should stay in the list of features that are planned to be implemented at some point. If we agree that we don't want any of these, we should close both reports. Otherwise we should combine them into a single feature request.
Created attachment 79612 [details] [review] udiff against gimp-2.3.12, not functional, draft of request #392613 I have drafted this (forgive hasty math & the like), implementing a boolean tool option gives me errors like (gimp:18669): Gimp-Paint-WARNING **: gimppaintoptions.c:507: invalid property id 27 for "do-warp" of type `GParamBoolean' in `GimpPaintOptions' and the "Warp" checkbox can not be checked.
Please don't use Bugzilla to ask such coding questions. Before even starting to implement anything, we should discuss this feature on the gimp-developer mailing-list. There, you can also ask for help if you run into problems while writing the code. But first of all we should specify what we actually want and how it should be presented to the user.
Mailing lists are for old people. Young and dynamic coders like me prefer web interfaces.
Then subscribe to a web mailer.
Ok. ;-) Anyhow, thanks for the suggestions (I think), maybe I continue the work, however, I'm slightly running out of time. I think right about now.
Comment on attachment 79612 [details] [review] udiff against gimp-2.3.12, not functional, draft of request #392613 The attached patch only warps the coordinates of the paint stroke. That's the trivial part. But it doesn't even attempt to attack the actual problem, which is to warp the paint that is applied. The approach taken here would only work for 1-pixel wide pencil strokes and I very much doubt that that's useful at all.
This bug and Bug 327175 seem almost identical, too close for me to tell. In my report, I've explained a possible method on how it could work with any sized brush. If the image is 200x200 and one of the pixels of the brush was at (-8, 202), the bottom left corner, the pixel would be drawn at the position (((200+-8)%200), ((200+202)%200)) which is (192, 2). The % here is the modulo function, the remainder of a division. Although I'm learning C programming, GIMP is far too complex for me at the moment. In short, the formula for determining the position is something like this: pixel.pos_x = ((image_size.x+brush.pos_x) % image_size.x); pixel.pos_y = ((image_size.y+brush.pos_y) % image_size.y); With the position established, the change in the image is made accordingly. Getting the tiling part is a bit trickier. As far as I can tell, one instance of the image is needed in memory with 9 draw functions to form the tiles. All that's needed are the image dimensions. If the image was 200x200, the top left tile would have a starting draw point of (-200, -200). It adds 200 twice more for 0 and +200 and the same goes for the Y. The one at (0, 0) for the starting point is the main image. Displaying this in the window and allowing for scrolling onto these tiled areas are the other things, of which is beyond what I know. The current behavior of GIMP is that, if you scroll to the top of the image when the image is larger than the interior window area, you cannot scroll any higher. This behavior would have to be changed in order for this to work at its best.
Nick, please we know how the modulo operation works. It's not helpful at all to go into implementation details at this point. The issue has been brought up on the mailing-list. Please discuss it there. The result of this discussion can then be entered as a feature request into this bug-tracker. With all these comments, this report has already become way too verbose to be useful.
*** Bug 327175 has been marked as a duplicate of this bug. ***
Ideally this would work in real time. If the display has room for 4 images, then as you draw a line you see 4 lines forming, one in each tile. (likewise for N images, you see N lines being formed) Of course it is really just one line forming, but visible on each tile in the display. This is needed to make editing feel totally seamless. The user should be able to lose awareness of where the tiles meet. Only then is it truly easy to draw tiles that don't show evidence of boundries. Some of the plug-ins are likely to show boundry problems. To avoid needing to hack all the numerous plug-ins to be aware of this feature, it might be reasonable to mark plug-ins that do/don't need a replicate-and-crop approach. (that is: send a 3x3 or possibly 2x2 tiling to the plug-in, then crop it back down when the plug-in is done) BTW, there are other tiling patterns in 2D space.
The problems outlined above are one of the reasons why this is very likely never going to be implemented in GIMP. Drawing seamless patterns is not part of our product vision for GIMP. Since implementing this feature would be rather intrusive it will most likely not be accepted. We can nevertheless keep this bug report to avoid duplicates.
This is actually a really good idea. The fact is that it sounds extremely good for seamless backgrounds. Aside from creating seamless desktop and web backgrounds, it would also be an ***EXTREMELY*** useful tool for game developers. However, I do have a few things I would like to mention. 1. It should be explicitly applied. 2. It should work for selections. 3. It would be preferable to have a clearly marked (outlined) 3x3 tiled expansion of a selection. I really hate being late on this. This feature would generally only present utility when touching up the edges of a photo, and esp the corners. I've tried cut and paste methods of doing the same thing, and as soon as you have 2-3 edges seamed, the next edge will most definitely screw it up. While I would mostly use such a feature for games, PLEASE DEAR GOD, do your part to eliminate ugly web backgrounds!!!
I would suggest an alternative approach to implement this. Instead of implementing this at the tool level, implement it at the layer level by adding support for cloning layers. That way a user can clone a tile and arrange them in a grid and then just paint on those tiles, since they are cloned the strokes will automatically appear on the other tiles and one will have the effect of them wrapping around. The hard part of course is that there would need to be support for drawing on multiple layers at once to make this work perfectly, but even without such support, layer cloning could be very handy in such situations.
I'm definitely interested in this, though I've not currently the time to hack on it (and I'm not familiar with the codebase in the slightest, either :( ). But in the interest of collecting prior examples, I wonder how the Photoseam people have it? I don't recall their app having layers, so probably at the image level; it was made for this sort of thing, so that would make sense, I suppose.
*** Bug 636021 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/228.