New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting collisions for multiple tiles at once #1322

Open
adsilcott opened this Issue Jul 25, 2016 · 11 comments

Comments

Projects
None yet
3 participants
@adsilcott

adsilcott commented Jul 25, 2016

Often a large number of tiles on a sheet will have exactly the same collision boundaries and properties (basic walls, platforms, etc). It would save a lot of time if collisions could be applied to multiple selected tiles in the Tile Collision Editor.

This would likely include a popup to warn the user that individual tile collision assignments would be overwritten.

Alternatively, maybe the default behavior could be to "add" the new collision to to the tiles rather than overwriting them, along with an option to clear the previous assignments from the selected tiles. This could work well if the dialog displayed all of the selected tile's collisions superimposed on each other (uneditable unless they all matched). Not sure about the usefulness versus complexity of this approach.

As discussed in this issue:
#5 (comment)

@bjorn bjorn added the feature label Jul 25, 2016

@bjorn

This comment has been minimized.

Owner

bjorn commented Jul 25, 2016

Also related to issue #1281, which suggests to move the collision editing out of a dialog and instead allow editing collision shapes of all tiles side-by-side.

The two approaches seem not entirely compatible, unless maybe we would move to a mode where all collision info is displayed side-by-side, but there is still a separate view for editing the shapes, which would modify the info on all selected tiles.

In any case, this will be something to do on the wip/tilesetdocument branch (or on master, after that branch has merged).

@adsilcott

This comment has been minimized.

adsilcott commented Jul 25, 2016

The nice thing about the separate view approach that you mentioned, is that you could have a zoomed in view for detailed editing of the collisions, while having a zoomed out view showing you the overall tileset, which ones you've missed and which ones you are editing, and how they all fit together. I think in that way they could work well together.

Another thought: If you went with only the whole tilesheet view, then if you could create big collider objects across multiple tiles and have it split it up and assign it to all tiles that it touches individually, then if you grouped together all similar tiles on the tilesheet then you could assign them all at once, giving a similar functionality. For example put all solid tiles in one section and draw a big square across them, and group corner tiles together so you can just draw a diamond shape across all four of them, etc.

@bjorn

This comment has been minimized.

Owner

bjorn commented Jul 25, 2016

Another thought: If you went with only the whole tilesheet view, then if you could create big collider objects across multiple tiles and have it split it up and assign it to all tiles that it touches individually, then if you grouped together all similar tiles on the tilesheet then you could assign them all at once, giving a similar functionality. For example put all solid tiles in one section and draw a big square across them, and group corner tiles together so you can just draw a diamond shape across all four of them, etc.

It's a neat idea, but in this case the collision info should probably be stored as a single object group along with the tileset. But that doesn't work with image collection tilesets, nor would it allow collision info to be auto-adjusted when the tileset size is changed (I'm currently fixing that... #1315).

I'll try to go with the separate view for editing collision info for now.

@mwillson

This comment has been minimized.

mwillson commented Nov 23, 2017

Wondering if there's been any progress on this? Didn't see anything on the Roadmap and wondering if/how I could contribute maybe?

@bjorn

This comment has been minimized.

Owner

bjorn commented Nov 23, 2017

@mwillson Well, at least the wip/tilesetdocument branch was eventually merged and the collision editor is now a view that is part of the tileset editor. But no progress has been made on actually allowing to edit collisions of multiple tiles at once. And indeed, the Roadmap is pretty crowded so I would be reluctant to add it to the list currently.

So, the best way to help is probably to take a stab at implementing it yourself. You're very welcome to try it and I'm available in case you have any questions.

The tileset view already allows multiple tiles to be selected at once, and all selected tiles can be obtained from the TilesetDocument, but the collision editor only deals with the single "current tile". So that is where most of the work would need to be done. Also, please write about how you'd expect the behavior to be before you start.

@mwillson

This comment has been minimized.

mwillson commented Nov 24, 2017

Thanks @bjorn for pointing me in the right direction. I'll clone the repo and look through that area of the code. And I'll try and come up with a small proposal about what to do based on my ideas + what you guys have talked about in this thread already. I was looking at Unity's new tilemap editor btw and I think it would be nice to make something like what they have that uses the tile geometry to auto-create the colliders. Perhaps some solution that allows that and ALSO custom widely-applied collisions would be nice. Anyway, I'll write out something a little more formal later

@bjorn

This comment has been minimized.

Owner

bjorn commented Nov 24, 2017

I was looking at Unity's new tilemap editor btw and I think it would be nice to make something like what they have that uses the tile geometry to auto-create the colliders.

Isn't that exactly what Tiled2Unity is doing? If there's something that could be improved in Tiled about this feel free to open an issue with some more details.

Thanks for taking up this issue!

@mwillson

This comment has been minimized.

mwillson commented Nov 24, 2017

If Tiled2Unity does this, I was unaware. I've been using it, and as far as I can tell, it only creates the Unity collider by combining the single tile collisions you've already specified in Tiled. And that's why this is an issue. Creating those 1 by 1 is a pain, especially in the many common instances when they should all be the same anyway.

@bjorn

This comment has been minimized.

Owner

bjorn commented Nov 25, 2017

If Tiled2Unity does this, I was unaware. I've been using it, and as far as I can tell, it only creates the Unity collider by combining the single tile collisions you've already specified in Tiled. And that's why this is an issue. Creating those 1 by 1 is a pain, especially in the many common instances when they should all be the same anyway.

You said that Unity used the tile geometry to auto-create the colliders. I haven't personally used Unity so I thought what you meant was the way Tiled2Unity creates colliders from the "geometry" specified in the tile collision editor.

But now I assume you mean that Unity analyses the tile image, and creates the collider geometry based on its transparent areas? That would certainly be a useful feature.

@mwillson

This comment has been minimized.

mwillson commented Dec 5, 2017

Yes, that.s what I mean. Something to work on :)

@mwillson

This comment has been minimized.

mwillson commented Dec 5, 2017

Here's what I was thinking would be easier to implement in the short term:

Example User Flow
1.Select multiple tiles in tileset view
2.Go To Collision Editor
*There would be a button in the collision editor menu bar that says something like "copy to selected tiles"
*This button would not be active unless a collision object is selected
3.Select Single Collision Object
4.Click now-active button that says "Copy to selected tiles"
5.Celebrate! Lots of unnecessary work has been avoided.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment