What's your approach to generate tilemap collider data?

As far as I can see there a few ways:

BAD:
- using default Tilemap collider. This kills performance

BAD but different bad:
- using Composite + Tilemap colliders pair. Better performance wise but you never can get it right and neither of the options are helpful, especially if your tiles artwork has bumps and protrusions (rocks pop out or weed, etc)

BAD but different bad #2:
- sprite physics shape through Sprite editor. Dont even get me started on how awful whole thing is.

GOOD but also BAD:
- defining collider manually, using either polygon, boxes or edge. This kills your tendrils and your time.

ACCEPTABLE, but mixed:
- some people use extra tileset that contains only straight shapes with acute edges, basically boxes and "true" triangles. This way Composite + Tilemap colliders pair generates very even final collider. However, this doubles your workflow essentially. You also later need to pre-process extra data, remove fake tilemap and cook colliders, preferably into solid polygon one. This also requires custom workflow and tools (i mean, you dont have to, but then you no better than random asset flip).

GOOD but very hard:
- write your own collider generator based either on sprites or Composite collider output. This has a high entry price (you need to be math genius or you need to pay one for effective and reuseable solution) but low cost of maintenance afterwards.

"CORRECT" one:
- "lmao, Unity's free stuff always junk, just use Tiled, dummy"

 

Because default Tilemap collider generates collider for EACH tile individually? This is common knowledge. Why yes, on something like core i7 11-700k/GTX3080 you wont see an issue but when you made another 2D pixel game that barely more complex than Mario on NES and it puts on its knees PC from 2010 then you have a problem.

Yes, that it why it is better performance because you now have one collider, merged, not a few hundred of individual (or however much tiles do you have in your scene)

It was a joke.

I didnt ask for help, I asked for some opinions and what approaches other people took in this endeavor. Now, if you actually did your research you'd know that the answer is obvious - most people (read: "successful well-know projects, and not just on Unity") just use Tiled (or similar 3d party tools) instead of Unity stuff, hence the joke mentioned before. Granted, it wasnt really an elegant one, but being an ESL I am - I think I can afford it.

 

Yes, it does, you dont see it ona decent PC but try an older on or weak laptop and do profiling and you will see higher memory usage and, depending how much dynamic objects that will collider with the env, you have - higher to some degree CPU load. Does not matter how big it is - If you can take that load off to free more frame time for logic and your data - you should do that.
Also, if you read any docs or watch any talks from Unity itself on Tilemap - this is the first thing they recommend. There are probably your own words in one of these talks stating the same.

There is no reason to take simple jokes personally.

 

You are not annoying me, I just wasnt interested in recommended by Unity solutions, I just wanted to know some general info on the approach other people took and reasons why. Well, anyway, now this thread can be closed.

 

create a byte array of 0s for empty space, 1s for solid blocks, use math to compare your position with the terrain array. Crawl your tilemap to fill the byte array with 0s or 1s. Yes, this doesnt use any of the built in unity collisions

 

That wont work for partially filled tiles, say, diagonally or uneven diagonally or may be just few pixels of the tile occupy a little bit of space in the grid block. You cant really mark it as 1 it is not solid.

 

for half filled you can mark it as 2, quarter filled as 3. Basically you have 255 degrees of fullness in a byte

if 255 variations is not enough you can go further and make a ushort array then youll have 65k some variations available, if its still not enough you can make it a uint and you will have 2billion

by the way this is how terrain and collisions are done in minecraft so it works for infinite worlds

 

I see, so this is where memes like "it takes 10k$ PC to run minecraft" came from...
That being said, minecratf is developed in mind with dynamic world structure. Suggested by you approach is not really relevant for your basic pixel games with non-dynamic (or little to none) physics/collision destruction and not gonna be very relevant performance-wise as well, in my opinion. Plus you have to basically invent whole system of handling all this stuff, handle some moving objects even if rarely, etc.

 

ah, you think you will have a game with better performance than minecraft, cool story bro xd

 

I never said that, but if you unironically think that every basic pixel platformer should have Minecraft physics system I think we might have a problem here of 2 very different priority and rationality systems.

 

you might be using the wrong platform for development I think, the basic things you want out of the box do not exist in unity, you just need to browse these forums to see that no one manages to get pixel games to work as they should

 

Fair point, hence I guess is the thread with generic discussion.

 

The "classic" way to do it I suppose, would be to have a 2D array (like Rarac said), but find your tile map X position by doing a "SHIFT RIGHT" >> (way faster than division) which is why the tiles needed to be Power OF 2. So if your tiles were 16x16, you would shift by 4 leaving you with the tile #. I suppose you could have a bit which says horizontal/vertical, then some more bits deciding the "start pos" and the "slope" value (how many pixels before it shifts) and you'd be able to determine that based on your characer's position within the tile (with a bitwise AND). This all depends on a tilemap being a Power OF 2.

In the end it'd be a shift, an array lookup and a 'jmp' if we're talking about branching based on the value, and then a bit more. These are just ideas, but if you're programming for a super low end device this would probably be the way to go without using expensive DIV's (especially floating point math, if the target device doesn't have SSE).