Can't Set tsx imported textures to readable

[Foxeh89]

So my goal was to; Import a tmx into the scene, and when into the scene, attach a polygon collider2d to it along side a script that will adjust the polygon colliders to be more accurate.

what went wrong is, the sprites attached to the tiles are not readable. even though i change the png files to be readable, disabled mipmaps, and full rect and etc. whatever happens to the texture when paired up with the tmx/tsx file prevents it from staying as readable.

any ideas on where i can locate the new textures and enable their read/write functions?

[Seanba]

I wonder if that's because your TSX file is using atlases? I added that option to help avoid seams but that also means the tiles are using generated textures and perhaps not the texture assets you were expecting.

Try turning off the atlas option and apply the change to your TSX. Hope that helps.

[Foxeh89]

Try turning off the atlas option and apply the change to your TSX. Hope that helps.

i tried turning it off and it took like 2 days of reimporting the file. i ended up giving up and making a script that swap the sprites with the multi sprite that was intended. which was a much faster deal.

[seanb-22ct]

i tried turning it off and it took like 2 days of reimporting the file

Whoa. That's a terribly long import time. I've never had an import take more than a couple of seconds. Is there something special about your TSX? Do you have a ton of tiles or are they especially large?

[Foxeh89]

actually, it's just a ton of tiles, around 3 thousand.

im pretty curious about how are you generating the textures without the seams though. honestly, if i had the option of just using the generated textures you have as the readable sprites. i'd rather use that.

[Seanba]

@Foxeh89, these seams are common in a modern 3D engine like Unity. It's due to floating point precision when sampling a texture. Sometimes the texel sampled is just barely outside the boundary of the tile.

Unity's answer to this is to use Sprite Atlases. Unfortunately, Unity has yet to give me an API to programmatically add/remove sprites to/from such sprite atlases. I have ST2U make their own within the imported asset.

BTW, I think I may know why your TSX takes so long to import. It's probably due to the way colliders for your tiles were set up in Tiled. If you have lot of sub-pixel vertices and edges in your colliders then the polygon clipper library has to work extra hard to combine colliders into an optimized shape.

You can see where I helped another user improve import performance here: https://github.com/Seanba/SuperTiled2Unity/issues/235

After touching just a couple of tiles I was able to bring his import time of 10 minutes to 30 seconds. Not bad for a few minutes of work.

[Foxeh89]

oh yeah, i saw this post a while ago and snapped all my pixels. but eventually, i tried to remove all of my colliders and tried to turn off "use Sprite atlas for tiles" since i was going to automate the colliders with a spritesheet that was readable. but before i even got to that point, it was just hanging for so long.

although along the way, i discovered there was an issue hiding within the code i was using to create colliders that caused unity to freeze. so i need to solve that before i come back to this.

but i did decide to just make an extra editor window button for just doing the extra work after everything else getting imported in.

[Cammin]

@Seanba

Unity has yet to give me an API to programmatically add/remove sprites to/from such sprite atlases. I have ST2U make their own within the imported asset.

It exists through SpriteAtlasExtensions and SpriteAtlasUtility.

However, I've tried using it extensively with my own importer in the past and it's really dubious to work with, even crashing Unity in some 2020 versions. Also adding the sprites into an atlas will be in a different order in the packing list most times, which muddles up source control. I opted to just not work with sprite atlases in code.

I recommend just telling the user to use sprite atlases manually to solve seams. My reasoning behind this recommendation is that it's the standard workflow for a TextureImporter anyway. It's unfortunate, but using the sprite atlas API is a huge can of worms that causes pain and suffering 😅

Your own packing strategy looks like a really good "out of the box" solution though.

[Foxeh89]

yeah, that's mostly the reason why i'm interested in an option to make the packed sprites be readable. but i've been just making a folder and slicing my spritesheets to solve my dilemma.

[Seanba]

Hi there, @Cammin. The sprite atlas utility and extensions just don't work - especially with objects that are created through scripted importers (which ST2U uses).

I'm thinking of approaching this another way: To control the way the texture sources are imported so that they have their own sprites dictated by the tileset - and have the tile objects use those sprites. I'd want to do that in way that allows @Foxeh89 to set other import properties though, like the read-write flag.