Why a Z offset for Tilemap chunks?

[dbanfield]

Hi,
I recently started using the Tilemaps feature. Absolutely amazing by the way! It's going to save me an absolute ton of time.

Something confusing me atm is why each chunk of a tilemap gets a progressively more distant z value

E.g.

Chunk 0 = 0
chunk 0 1 = -1e-06
Chunk 0 2 = -2e-06
etc


The reason this is causing a problem for me, is that I want to create arbitrary individual tile sprites (outside the tilemap) and v-align them with existing tiles. It seems unity alignment works well since it will actually allow you to align to a specific tile in the tile map, but if I try and align it with a tile in chunk 0 2 for example, the alignments will make the separate sprite's z = -2e-06.


As an aside, just to give the reason why I'm creating separate tiles and aligning them with existing tiles in the tilemap, is that I have anchoring scripts for environmental features such as an elevator which will expose a game object which you can assign to be its anchor (and another game object to say where the elevator's path of movement will end). Maybe there is actually a better way to allow a user to specify the anchor as an individual tile in a tilemap? I wasn't able to find a way to have another script expose an editor value that could be assigned to an individual tile. That would be even more awesome if somehow I could do this - maybe using tile id's?

TIA for any help

Dan

[unikronsoftware]

The chunk z values are for deterministic sorting. In most cases it wouldn't matter, but if your tiles overlapped in any way, they would need to be drawn in a particular order. This is already done inside the tile map chunk by ordering sprites in a particular way.

Have you looked into instantiating prefabs with the data tab for these elevators and stuff? That might work well enough, and you won't have to care about the chunk offsets then. You can also assign data per sprite (not tile id) in the same tab.

If that doesn't work, we can of couse simply disable the offsetting - its fine to disable it as long as you know why its there and if you're sure its not going to affect you.

[dbanfield]

okay makes sense. In my situation it didn't add up, since all my tiles were the same size, and I had assumed that this was how the tilemap was designed. I suppose some use cases may demand overlapping tiles in which case the deterministic sorting would be required.

No problem regarding my setup - it occurred to me I can just use empty game objects as these markers, that way the Z value can just be ignored.