Wang tiles filling tool

[MoctezumaDev]

One of the things that you might want to do while filling a tiled map is to reduce the repetitiveness of the tiles and keep a continuous map. Wang Tiles provide a nice approach to this issue.

The idea would be to create a workflow for a filling tool that uses Wang Tiles as a strategy for filling a selected area. This project can be combined with some general improvements to filling methods #1272.

[vikasTmz]

Is there any particular reason for why the current Texture synthesis is done using tiling?

The Image Quilting technique by Efros unlike Wang would not require tiles to be selected in order to tessellate and thus can be done in preprocessing. I think Wang is more for real-time texture synthesis and infact is a build up of Efros technique to accomplish the former and thus will be slow if used as a fill tool.

Therefore I think Image Quilting can be done for each unique tile in preprocessing (probably on uploading the tile set) and be used in the bucket fill tool while Wang which will require the user to select the tiles and their color matching to be computed, could be used with the terrain brush. The results shouldn't vary but this will be more efficient.

[MoctezumaDev]

I was not aware of the image quilting technique, but if I understood it, you would need to synthesis new tiles which might end in undesired tiles. Game developers can be very picky when it comes to resource management, I think what ever the tile set is provided should not be modified by the tool.

The reason I found Wang Tiles attractive is that they kind of work as constrain rules, you might want to allow that some tiles get combined even if their boundaries don't match in color.

I agree that the less interaction the user has to do in order to use the tool the better, it might be possible to autogenerate the Wang Tiles by color boundaries or a similar rule but the user should always be able to modify it.

[MoctezumaDev]

@vikasTmz sorry I might not have answer you first question.

Is there any particular reason for why the current Texture synthesis is done using tiling?

Usually games requires to tessellate big maps, this maps are made by tiles created by an artist and arranged in a texture atlas this is usually to reduce the calls to the graphic card. So with this small tiles you can create big maps out of this small pieces.

For example the following is an atlas with the tile set used by Zelda.

[vikasTmz]

I was not aware of the image quilting technique, but if I understood it, you would need to synthesis new tiles which might end in undesired tiles.

The texture generation in Wang Tiles uses Image Quilting using seam carving as shown below. The below step is done after non-periodic tiling/color matching. [Section 3.2] in Wang

The image below is the result of texture synthesis using image quilting. You can see that the properties of the smaller input patch have been retained in the new larger output patch.

So with this small tiles you can create big maps out of this small pieces.

But this could lead to repetitiveness as mentioned in initial problem statement. So the idea I was suggesting above was, as the user creates larger grids, instead of repeating the same texture on all cells, create a tile set (same dimension as the grid) on the output of Image Quilting and use it as part of the bucket fill tool.
Unlike Wang which will do the texture synthesis on run-time as the user selects which tiles to modify, Image quilting is a one time process. Again there is some overlap between both the techniques but they both have their own advantages.

[bjorn]

It seems @vikasTmz is essentially referring to Wang Tile Tesselation based on Image Quilting, where Wang tiles are automatically generated from a sample, which are then used to tile an area.

While this could be a feature available in Tiled, it would work just as well as a separate tool and it is not the scope of this issue. This issue is about once you have a set of Wang tiles, be it auto-generated or hand drawn, that you can instruct Tiled to use them in a useful manner, like filling an area randomly or using it to pick tiles while painting similarly to the terrain tool.

What @leonidaX is getting at is that in the context of tile map editing, the Wang tiles will usually be hand-drawn. In this case border analysis may not provide the desired results, so the user will need to be in control. This could be for example by requiring the user to arrange the tiles in his tileset a certain way (like as a blob tileset), or putting the tiles on a certain "template map" to tell Tiled what tile belongs where. Of course a border analysis could speed up this step in many cases.

So incidently, it was probably confusing to refer to the paper about using Wang tiles for image and texture generation. This site provides a much better overview of the different tile configurations that would be interesting to support in Tiled.

[MoctezumaDev]

Yeah that's exactly what I thought, it would be useful but it could easily live as an external tool that could be complementary to Tiled. Tiled from my point of view is not about the image synthesis and more about the tessellation of previously generated images.

The idea for Tiled that I had is more like the one @bjorn points to in the blob tileset.

[vikasTmz]

@bjorn This link cleared out some of my queries. Thanks!

But I want to revert back to my earlier question in the first post.

Is there any particular reason for why the current Texture synthesis is done using tiling?

Other than the increased performance tessellation offers in lesser Memory bandwidth and CPU overhead, is there any reason in it being used behind it's aesthetic quality?

@leonidaX I understand that altering the resources of the artist/game-level designer will not be right for an editor, but the goal of texture synthesis is to only generate a higher resolution texture without any pixelation/aliasing/creating any other artifacts or altering the texture all together. But this will take up more processing time.

With reference to the below screenshot from the isometric_grass_and_water.tmx file, how will the Blob Tileset solve the repetitiveness problem if the textures can't be modified?

I think my confusion is with respect to the context of usage of Wang Tiles in the current Tiled environment i.e when/how is the user expected to use it and how should it be integrated with the current UI. I was mainly elaborating on image quilting to solve the repetitive tile layout, but I can see the Blob Tileset offers some interesting features like randomized maps and fits better with the current implementation.

[bjorn]

Other than the increased performance tessellation offers in lesser Memory bandwidth and CPU overhead, is there any reason in it being used behind it's aesthetic quality?

Are you asking about why one would use tile maps at all? I think they are still popular in games today because of their easy to work with structure, which enables fast rendering and efficient content editing. Of course, more interesting techniques exist today and I would certainly be interested to explore them in terms of editor features, but that's an entirely different topic of course.

With reference to the below screenshot from the isometric_grass_and_water.tmx file, how will the Blob Tileset solve the repetitiveness problem if the textures can't be modified?

The blob tileset is not primarily about solving any repetitiveness problems. The example used in the screenshot solves repetitiveness mostly by having the same logical tile included in the set multiple times in different variations. The terrain brush will pick a random one while painting.

However, when filling an area randomly, a wang tileset makes it possible to perform a more advanced randomization that allows certain features to span several tiles, since you define which edge fits to which other edge by defining their color. This is better than plain randomization per tile, which essentially assumes a wang tileset that has only a single edge color.

[vikasTmz]

the same logical tile included in the set multiple times in different variations.

Could you elaborate on this sir? Or let me know the file where this has been implemented.

[bjorn]

Could you elaborate on this sir? Or let me know the file where this has been implemented.

See the use of RandomPicker in the findBestTile function in terrainbrush.cpp. It will for example pick randomly between several full grass tiles, taking their probability property into account.

[Bdtrotte]

Just so I'm clear on the goal of this project:
The user will provide the wang tiles, and then, those will be used in the fill tool, and perhaps the brush, or terrain brush.

Is this correct, and/or am I missing any key aspects?

[bjorn]

@Bdtrotte That is correct, except if it turns out that it would be better implemented in its own tool. The important point is though that this is not about generating tile graphics.

[Bdtrotte]

Great! With that in mind I made a mock up of how this could work.

First off, once the user has the wang tiles in a tile set, there is the process of assigning the edge "color" to each tile so we can work with them. I thought this could work in a manner very similar to setting up different terrains. And in fact there could be an "edit wang tile information" button right next to it

And this interface could look something like this:

This could make it easy to to set up the wang sets from a tile sheet. Of course a stretch goal for this project could be to automate this process.

Once set up, the wang sets could be used in a number of ways. I thought a good implementation could be to add another button next to the "Random Mode" like so:

Which would make all filling, stamp brushing, maybe even terrain brushing, use the wang technique to fill in tiles, based on a selected wang set.

I'd love feedback on this layout and implementation.

Thanks,
Ben

[bjorn]

Hey Ben, thanks for exploring possible UI solutions for this feature! One thing that strikes me here is the similarity to the terrain information, which makes me wonder what the difference actually is. So far I can see two differences:

• You're marking sides, whereas the terrain information is based on corners. However, note that some Wang sets should also work on corners rather than sides, since defining a terrain-like Wang set (for example 2-corner Wang tiles) in terms of connecting sides is rather more confusing (see the section about conversion).

• The terrain information defines one list of terrains used by all tiles, whereas in your mockup you define possibly multiple "Wang sets", where each set includes its own list of colors, and I guess tiles are allowed to be used in multiple wang sets. I like the idea of separating the definition of the set from the tiles. I actually think with the terrain system, putting that information directly on the tile was a mistake and it would also make sense to move that into a "Terrain set" of sorts.

All in all, I think the systems are so similar that this project should probably include a part about unifying them, though I wouldn't try to do so from the start.

Also note that it may make sense to provide support for pre-defining the type of set, like "2-edge", "2-corner", "3-edge", "3-corner" and "blob (2-edge + 2-corner subset)". That way, there could be some feedback about the completeness. However, in the general case of an N-corner set, like the terrain information essentially is, this would be very hard.

In general, an alternative to painting the edges/corners on each tile would be to drag-n-drop the tiles into a pattern. This is how you define an Auto Tile in Game Maker Studio 2, for example.

Btw, note that on the master branch, the UI has changed quite a bit from Tiled 0.18. Terrain information is no longer edited in a dialog but rather it's a mode in the new tileset editor view.

[vikasTmz]

In general, an alternative to painting the edges/corners on each tile would be to drag-n-drop the tiles into a pattern.

But this could be automated if you were to quantifying the texture of the tile (either using statistical or spectral approach) and then map them to their corresponding template . Blob tile set has 47 tiles, so it could be a pain to assign a template for every tile. The user could have the freedom to change the pattern but would that benefit the user? (unless for errors in the automated assignment or maybe duplicate templates)

Also I've played around with this Implementation and the randomization works well but I felt the drawing tool and the usage was not intuitive. Could you point out to any software that has this implementation that you feel we could take inspiration from. I've had a look at Auto Tile in Game Maker Studio.

[Bdtrotte]

Thanks for taking a look and giving great feed back!

Btw, note that on the master branch, the UI has changed quite a bit from Tiled 0.18. Terrain information is no longer edited in a dialog but rather it's a mode in the new tileset editor view.

Thanks for pointing that out! I realized they were different in the build and release version, but for some reason never connected that I should treat them differently...

That aside, you are very right that painting each tile's edge would be very tedious. At the time I misunderstood how we would implement wang tiles (didn't consider the user would probably need to provide a complete set). So I really like the idea of drag and drop, or hopefully an automated process eventually.

In the tileset editor, there could be an option next to the edit terrain info button to edit wang info. There would be the ability to have multiple "wang sets", once one is created/selected, the main edit area could split in two (left the tile set, and right the template). There would be new options to select the tile layout ("2 edge","3 edge","blob","n corner", ect), as well as an option to auto map once a template is selected? And of course options/tools to make life easier, like something to account for rotating a tile where desirable, and such.

Also I've played around with this Implementation and the randomization works well but ...

I like the implementation, great tool for better understanding everything. I didn't before consider the ability of "drawing" to change the random layout. I really like it, and think it would make a super useful tool in tiled when paired with wang, if it was made a bit more intuitive.

I can make a mock up of this too if the description was unclear! And feedback would be appreciated.

All in all, I think the systems are so similar that this project should probably include a part about unifying them, though I wouldn't try to do so from the start.

Could you elaborate on how unifying would work? As in make them work together, or use the info from identifying edges/corners to work for both tools?

Thanks again for the initial feedback
Ben

[bjorn]

Also I've played around with this Implementation and the randomization works well but I felt the drawing tool and the usage was not intuitive. Could you point out to any software that has this implementation that you feel we could take inspiration from. I've had a look at Auto Tile in Game Maker Studio.

The implementation is great in that it demonstrates what is possible in terms of tooling, but I agree it is not intuitive. I don't know of any similar tools.

Game Maker Studio 2 basically supports 2-corner Wang sets and the Blob. Here's a screenshot showing how you define each one (it's by selecting a tile in the template, and then clicking a tile on the tileset to fill it):

The way they did it, one could imagine they could easily add more variations, for example the 2-edge set for fences/roads.

A downside to this approach is apparent as soon as you try to actually draw with these auto tiles: it does not do anything useful when you hit tiles from another set. The painting tool is only smart about what tiles it selects from the currently selected set. This may be one area where it could be problematic to unify Tiled's terrain tool with Wang sets, though a bit more annotation may fix that as well (for example keeping a "terrains" list and defining which "color" matches which terrain).

Could you elaborate on how unifying would work? As in make them work together, or use the info from identifying edges/corners to work for both tools?

I meant mostly sharing code and data structures, possible supporting the terrain use-case as an N-corner Wang set (though tile templates can't be defined for this case). However, I think it is better to first develop the support for Wang sets separately.

I like the implementation, great tool for better understanding everything. I didn't before consider the ability of "drawing" to change the random layout. I really like it, and think it would make a super useful tool in tiled when paired with wang, if it was made a bit more intuitive.

I can make a mock up of this too if the description was unclear! And feedback would be appreciated.

I would definitely not mind seeing more mockups. It really helps to get more concrete about the project.

[bjorn]

Blob tile set has 47 tiles, so it could be a pain to assign a template for every tile. The user could have the freedom to change the pattern but would that benefit the user? (unless for errors in the automated assignment or maybe duplicate templates)

When automatic assignment is implemented, indeed the freedom to change the pattern is only useful for correcting errors.

[Bdtrotte]

The game maker studio 2 layout looks a lot like what I was thinking!

it's by selecting a tile in the template, and then clicking a tile on the tileset to fill it

This seems a bit cleaner than click and drag, and a further improvement could be to make it automatically move to the next tile in the template to be filled after you set the current one. That way you don't have to click back and forth.

One other small thing I think will be very important is the ability to define an "empty" tiles edge/corner colors. In other words how the wang tile set will interact with empty tiles. (As well maybe undefined tiles?)

I will get a mock up together soon. A bit bogged down at the moment with exams, then Ill be full throttle tiled!!

[Bdtrotte]

Also some questions:

• Should the user be able to use the wang tools without filling out a complete wang set?
• Should the user be able to define a "custom" template, or change the colors of a given template (not sure when they would want to do this)?
• How do we want to implement variations of particular template tiles? I was thinking one could right click on a tile in the template and have an option to "add variation".

Thanks
Ben!

[Bdtrotte]

Here is a mock up of how the wand tile set up could be in the tileset editor.

With the idea being one clicks on a template tile (right) and then clicks the corresponding graphic tile from their tile set (left). And after assigning a tile, it could save time to automatically move to the next template tile for assigning.

The main property of a wang set is the template type. After selecting one it will lay out the appropriate template. The drop down for template would include standard wang sets (such as 2corner 2edge blob ect) as well as a custom option.

The custom option would allow setting an indefinite amount of corners/edges, which would generate the corresponding template. The full set of these quickly becomes very large, but I think it would be good to give the option. And it should be possible to work off incomplete sets to some extent.

Worth discussing is how to display assigned template tiles.

I think it's necessary to show both the original template tile, and the assigned tile. This could be done with transparency, or how I've done it as above. Would like input on what others think is a good solution to this.

Other things not shown:

• How it should look to assign an "empty" tile.
• A lot of the template tiles are rotations of other tiles. It could be desirable to assign a tile, and 90 degree rotations of the tile to appropriate template slots. There should be a clean way to do this when assigning (maybe ctrl click).

Thanks
Ben

[Bdtrotte]

Hello @bjorn, I've written the first draft of my GSoC proposal. I would appreciate feedback with any changes I should make before submitting! Mainly should I add a more detailed description of the projects goals?

The Proposal

[MoctezumaDev]

Hi @Bdtrotte thank you for the mockups, I think they are in the right direction, I probably would do it in a floating window separated from the main window. We can further discuss the flow while we approach the start of the program and try to come with a clear UI flow before starting the project.

About the template tiles, I think that you also might want to drop more than one tile into the same wang tile to have variations of the same wang tile.

I went quickly through the document, the timeline looks good and clean. I think it's a good approach.

[Bdtrotte]

Thank you for looking over it!

About the template tiles, I think that you also might want to drop more than one tile into the same wang tile to have variations of the same wang tile.

I was thinking a solution to this could be to right click a template tile, and have an option to "add variant", which adds a duplicate next to it which can be assigned as well. This way each template tile has one corresponding tile, and makes it clear to the user what has been assigned. On the other hand this could be tedious if the user wants to add a lot of variants for a large set...

Another method could be to have some hot key which auto makes a duplicate of the selected template tile. This way when assigning, the user could quickly add and assign the variants in few keystrokes.

[bjorn]

Maybe it's a crazy idea, but I thought of the option to paint with template tiles onto the tileset. It would make handling variations straight-forward. I'm not sure however how we would then handle support rotation (could be done in a little bit less flexible way by having a separate template for this).

In general, I think the display of the template should be moved into the Wang Sets dock, rather than being a split view in the main window. That way it can also optionally float.

How it should look to assign an "empty" tile.

I guess a dotted outline could do.

The custom option would allow setting an indefinite amount of corners/edges, which would generate the corresponding template. The full set of these quickly becomes very large, but I think it would be good to give the option. And it should be possible to work off incomplete sets to some extent.

Right, I think one of the main use-case for this is to cover the functionality of the terrain tool, and handling incomplete sets becomes a must then. I think GameMaker Studio 2 handles incomplete sets by just not placing any tile when it encounters a situation where it wants to place a tile with that template. The Terrain Tool instead tries to place the closest matching available tile, and then proceeds to change other surrounding tiles to match as well. Of course, that sometimes leads to strange glitches where it will change most of your map into garbage, so ideally we'd find a better solution for that eventually (but, I would also consider this a possible future improvement (or stretch goal, as you put it) and the first iteration can go the GMS 2 route).

Hello @bjorn, I've written the first draft of my GSoC proposal. I would appreciate feedback with any changes I should make before submitting! Mainly should I add a more detailed description of the projects goals?

Your proposal looks great and it's the most detailed I have seen so far! Still, we should work to refine it until the deadline and I will try to get back to you with specific feedback in coming days.

[Bdtrotte]

Still, we should work to refine it until the deadline and I will try to get back to you with specific feedback in coming days.

Great! Thank you for looking over it. I'll be sure to revise anything that needs it before the deadline!

In general, I think the display of the template should be moved into the Wang Sets dock, rather than being a split view in the main window. That way it can also optionally float.

I agree completely! Just didn't think about it as I was making the layout.

Maybe it's a crazy idea, but I thought of the option to paint with template tiles onto the tileset. It would make handling variations straight-forward. I'm not sure however how we would then handle support rotation (could be done in a little bit less flexible way by having a separate template for this).

I like this idea! Maybe it could be paired as another option for assigning. A lot of what I was aiming for was limiting how much the user has to swing the mouse back and forth between panels, but painting could also help handle certain use cases.

As I've been working with hexagonal maps a lot lately, I was thinking hex wang sets should be considered. The logic should be very similar to the standard wang tiles, and shouldn't be too much of a stretch to handle. Maybe it can be added as a stretch goal, if it's not though of as an immediate priority.

[bjorn]

Great! Thank you for looking over it. I'll be sure to revise anything that needs it before the deadline!

Be sure to submit your proposal through the official channel now. There is no need to wait with this since you can submit it as a draft.

I like this idea! Maybe it could be paired as another option for assigning.

If there is enough time we can try both approaches to see which one works best, but I think we should aim to implement one mode well in the end and not try to make this a user choice. It would make things rather more complicated without much benefit.

As I've been working with hexagonal maps a lot lately, I was thinking hex wang sets should be considered. The logic should be very similar to the standard wang tiles, and shouldn't be too much of a stretch to handle. Maybe it can be added as a stretch goal, if it's not though of as an immediate priority.

That would be a stretch goal indeed, but at least we should take into account isometric staggered maps already. This should not be a big issue since the Terrain Tool was already fixed up to work for such maps.

[bjorn]

@Bdtrotte I've had a closer look at your proposal and provided some feedback. I couldn't resist to make a bunch of small edits, feel free to take them or to make your own adjustments, but in general I think you need to pay a bit more attention to detail. More importantly though is to use some images given the visual nature of the project.

[bjorn]

@Bdtrotte There's only a week left to submit proposals. Please don't wait until the last moment to submit, so that there is still time to give more feedback.

[Bdtrotte]

Absolutely! I'll try to get everything in soon. I was having some delays getting a proof of enrollment, which is required to submit the proposal. As well last week was my finals week, so I wasn't able to refine my proposal just then. I'm on it now, and will by the end of today have they refined version ready for review, at least on here if not through gsoc quite yet.
Ben

[Bdtrotte]

I have updated, uploaded, and shared the draft on the summer of code site!

[Bdtrotte]

One thing a user may want, is to proceed with an incomplete wang set. In this case, when brushing individual tiles or filling, it is possible to not have a tile available to fill a space (non matching anyway). So I was wondering what you think would be a good way to handle this. In my mind there are three possibilities.

1. Don't fill, and throw a message to the user that the set is incomplete.

2. Randomly fill, or have the user choose a tile to use when there is no match. I think this is similar to how the terrain brush handles the similar case.

3. It may be that the wang set actually can tile a plane, but the current layout wont work. So It could go through and change already placed tiles to allow the current space to be filled correctly. This could of course lead to unintended results though... For filling an area, this strategy could be useful (as the changes wouldn't have to affect tiles placed by the user). In any case, this method would be more complicated, and resource hungry.

2 seems like the best solution to me, though I'm interested in additional feedback.

[Bdtrotte]

A necessary idea in this project will be to identify a tile with a wangID. This is an number to identify which "color" edges/corners the given tile has.

A rather direct way to accomplish this is to think of each color as a number, and each edge/corner as a digit. Then we effectively have a unique ID in a base equal to the number of colors. By converting to base 10, we have consecutive IDs for every tile; if there are 64 base tiles, the first will have id 0, the last id 63. Details with pictures can be found at this page in the "Bitwise Tile Index section".

This works very nice when there are only two colors, as bitwise operations can be used to easily parse the id for info on the individual corners. Though when in a higher base (such as three) or when corners and edges get involved, it becomes a bit more complicated.

Another solution with few downsides is to use each digit of an int (represented in hex) as a particular edge or corner, regardless of the number of colors. The obvious downside being that with this method wangIDs wont be consecutive. This however isn't necessary for most (if any) use cases, and even if it is, one can quickly convert to the above id system. In the general case, this will make finding info about particular edges/corners, and constructing wangIDs, much simpler.

A major advantage to the above comes with rotation. To get the id of a rotated wang id, one can simply bit shift the original id, and move the truncated bits afterwards.

Specifically speaking, info would be stored in the following way:

int wangID = xHGFEDCBA

  |H|A|B|
  |G|_|C|
  |F|E|D|

My plan is to move forward, and work with the second second system. If anyone has any thoughts on this, I'd be glad to hear them!

[bjorn]

@Bdtrotte I think your choice of implemention for the wangID is reasonable, and it is of course similar to the way terrain information is stored with the tiles.

I realize the terrain information is pretty much handled as a raw integer as well, but I would suggest you to wrap the wangID in a class, like class WangId { unsigned value; };, so that functions to get a color or rotate the colors can be members of this class.

One thing a user may want, is to proceed with an incomplete wang set. In this case, when brushing individual tiles or filling, it is possible to not have a tile available to fill a space (non matching anyway). So I was wondering what you think would be a good way to handle this. In my mind there are three possibilities.

I think option 1 would be the best for now, where the message could be in the status bar so that it is noticeable but not too annoying. The terrain brush actually implements option 3, which can indeed lead to unintended results. ;-)

[MoctezumaDev]

Yes, I also was suggesting Ben an iterative approach on this, probably the third option would be just a nice to have and should remain an optional behavior. If he can achive the first point it would be a nice progress.

And I also like your approach to represent enumerate the possible wang tiles.

[therahedwig]

Ah, I am not sure where to leave feedback, but I was testing the wang tile brush in the latest appimage...

The good:

• Setup is tedious but straightforward.
• I had no crashes nor noticed any bugs in my fiddling about. This is commendable.
• The filling mode worked exactly as advertised. No problems here.

The bad:

• Setup is pretty tedious.
  • Click dragging sides to be marker a color for example... I had hoped that if I were dragging over the top of tiles to mark all the top-parts with the color, it ended also doing the sides.
  • There's no way to remove a single marking, only all colors on a single tile. I attempted clicking again, right clicking, middle clicking, ctrl+clicking etc.
  • Hopefully we'll be able to "copy paste" wang tile configurations somehow from tileset to tileset, or at the least some kind of common preset to color tiles with.
• In painting mode, wang tiles can only paint edges and corners, seperately. This was super-confusing. I had hoped for something like the terrain brush, where putting down the color it would adjust the surrounding tiles to make sure it would fit the center.

Finally, it'd be great if there were some instructions on how to use. ( It's a pity gsoc submission time is over, because I have done gsoc myself in the past, and a manual page makes for a nice finisher on the submission page :) )

[Bdtrotte]

Thanks for trying it out! There actually is documentation on Wang tiles in Tiled's docs!

[therahedwig]

Ah excellent, Tiled's site has changed so rapidly lately(last year) I never noticed there was a readthedocs.

[bjorn]

Thanks for your feedback, @therahedwig! It would definitely be good to improve some of those pain-points before the 1.1 release. Of course I hope @Bdtrotte will have a bit of time or at least some ideas, but unfortunately GSoC is indeed over and he will surely have other commitments coming up now.

Click dragging sides to be marker a color for example... I had hoped that if I were dragging over the top of tiles to mark all the top-parts with the color, it ended also doing the sides.

I admit I ran into the exact same issue. I think it could be solved by "locking" into a certain side until the mouse exists a certain region. For example when you press down to change the top side, it won't switch to any other side until you exit the top half of the tile.

There's no way to remove a single marking, only all colors on a single tile. I attempted clicking again, right clicking, middle clicking, ctrl+clicking etc.

Yeah, the terrain editing mode has a button for this, but the similar button for the Wang mode erases the information for the whole tile. I'm not sure what the logic was behind this, maybe @Bdtrotte can comment on it.

Hopefully we'll be able to "copy paste" wang tile configurations somehow from tileset to tileset, or at the least some kind of common preset to color tiles with.

That's a very good idea. Maybe it could be possible to capture the Wang information from multiple tiles, in order to then paint with the whole captured data elsewhere. Though, there is a problem with matching colors and that possibly you want to paint with the same "structure" but with different colors... Not sure what's the ideal approach here yet.

In painting mode, wang tiles can only paint edges and corners, seperately. This was super-confusing. I had hoped for something like the terrain brush, where putting down the color it would adjust the surrounding tiles to make sure it would fit the center.

Essentially, are you saying there shouldn't be separate colors for edges and corners? I wondered a bit myself what about this because I've seen terrain tilesets that may be better served by a single set of colors for both corners and edges. What do you feel about this, @Bdtrotte?

[Bdtrotte]

Yeah, the terrain editing mode has a button for this, but the similar button for the Wang mode erases the information for the whole tile. I'm not sure what the logic was behind this, maybe @Bdtrotte can comment on it.

This is something I meant to fix for awhile, but kept getting pushed back and lost somewhere along the way... Originally the whole tile is erased as pattern assigning was the first to be introduced, and support for individual corner/edge erasing was never added.

Essentially, are you saying there shouldn't be separate colors for edges and corners? I wondered a bit myself what about this because I've seen terrain tilesets that may be better served by a single set of colors for both corners and edges. What do you feel about this, @Bdtrotte?

I considered it too, though in general I wanted to make the tool as general as possible, though I suppose a mode could be added where both corners and edges share colors, and could be assigned at the same time...

[therahedwig]

I have to admit I don't quite see the usecase for having edges and corners seperated, but I am otherwise neutral to it.

My personal feling is that I have a map, I fill it with one color (like, grass tiles), and then press on a square with another color, and the wang algorithm should choose how to resolve that? Like, with only the edges and corners, I can press with the edge brush on a square, and it'll give me a nice "path", but when I draw two paths around it, it does not in any way try to resolve the little corner that's there.

Okay, thinking about it, I can see the usecase for seperate edge and corner brushes, but I suspect the main use case is a singular brush that allows you to draw nice patches of tiles. (Akin to rpgmaker esque autotile).

As for the copying.. maybe some kind of filling tool for the wang id/colors?

Personally, I use this template: https://opengameart.org/content/seamless-tileset-template
Which makes for the following kind of tilesets:

(Now, my dirty secret is revealed, I am primarily someone who modifies LPC tiles)

I would personally like to be able to define a sort of... stamp or something? maybe with selections and a color fill tool. Other solutions are fine too, but doing these kind of tiles is a bit... fiddly.

I think the shared edge+corner drawing mode is a bit more important, as while making the tilesets is fiddly, it ought to be a thing you do once, right?

Oh, BTW, I did get one crash, when changing the color of a id-set(closing the dialog). As this is an appimage, I cannot get a backtrace from it.

[therahedwig]

Oh oh oh, playing with it some more I have two dumb feature requests.

1. When a wang tile transition won't draw because it is missing, could we maybe get some feedback about which one is missing? Like, in the overlay somehow?
   
   Because I am puzzling which one is missing here(it tries to draw grass...)

2. This one is even more in feature request territory, but for the "patterns" maybe some mode where a pattern, if it is already in the given tileset, is hidden or made semi-transparent? That way it can function as a "tick-off" box of tiles that need to be added to the tileset to be... uh... wang-tile complete.

[bjorn]

This one is even more in feature request territory, but for the "patterns" maybe some mode where a pattern, if it is already in the given tileset, is hidden or made semi-transparent? That way it can function as a "tick-off" box of tiles that need to be added to the tileset to be... uh... wang-tile complete.

The already assigned patterns are already displayed slightly darker. Or do you mean something else?

[therahedwig]

Oh darn it, I never noticed that. I feel dumb now.

[bjorn]

Since this feature is actually merged, I think it's time to close this issue and open separate issues for any remaining work and possible improvements. Please feel free to keep discussing general stuff here, but also please help by opening new issues since it's hard to keep track of stuff otherwise.

Thanks for all your hard work on this @Bdtrotte! Of course I hope you will find time for making further changes, and you're welcome to stay around in any case!

[bjorn]

I've opened the following issues so far based on suggestions by @therahedwig:

• Make it easier to set up Wang tiles Make it easier to set up terrain #1729
• Improve feedback when using Wang tiles Improve feedback when using Wang tiles #1730

@therahedwig You also mentioned a crash. Could you open an issue about this and try to include detailed steps for reproducing it?

[therahedwig]

Well, it's weird, I was able to get a crash with the same appimage with the same file on one occasion and not on another. I need to do further testing to figure out what exactly is going on there, and I'll make an issue when I find a reliable test case.