Is there any consensus about the Pixel Per Unit setting for pixel art sprites?

I'm reading a lot of conflicting information about the Pixel Per Unit setting for pixel art games. Many people use 1 px = 1 unit and report no problems. Others use 1 game tile = 1 unit, so something like 16 or 32 pixels per unit. Many others seem to leave it to the default 100 "because that's the way that it was intended."

The designer of the modestly-sized Flamberge recommends using 1 px = 1 unit, for example.

A Unity poster (I think that it was Melvyn May) at one point said that it should not make any difference, but I cannot find this link.

Many others say that Unity physics will break with a small setting like 1 px = 1 unit, or have some kind of "jitter."

Still others say that Unity physics will become very taxing on performance because too many calculations will be made due to the processing of so many physics units.

Is there any consensus on this? Does anyone from Unity have any input into this? Any experienced developers with any input on this?

 

I am using 1 right now because I have a 1920x1080 display/coordinate system. I can see how using 100 might make better use of floating point precision (since lower float numbers have more accuracy). Also my other concern would be physics, whether things behave realistically if the scale of the coordinates are so much bigger.

 

Thank you. Yes, physics seems to be the main concern of people who say to stick with a large pixels per unit value. The little bit of physics that I've tried in my game seemed to work just fine, but I'm a beginner.

However, beyond the response from an official Unity poster that I can't seem to find now, I've never seen any "official" position on this issue that specifically talks about performance or physics. It would be great to have an answer on this.

 

For me 2D colliders around 1 unit and less don't work, so I suggest using less pixels per unit, too.

 

When you say "don't work," do you mean you simply pass through them? Have not had this issue yet, but it's troubling if this happens to anyone.

 

Box2D(the physics system) deems the colliders too small. It is some bug, like 1 doesn't work, 1.01 does, but then 1.02 doesn't again. It does this with box and polygon colliders, but there may be something messed up in my project and I'm also not using the latest version of Unity. Surprisingly on smaller colliders than one the collider works in specific scales, and if it doesn't I just use circle collider. Also for walls in my game that are 1x1 unit big I just disabled colliders altogether and use prediction of future position to not let player walk into it.

 

Thanks for this clarification. It seems like the physics is hit or miss with small pixels per unit values for some people.

 

I wouldn't recommend doing 1 pixel per unit. If you ever decided to change your art style, or if you want to use your engine on a non-pixel art game, you'd run into trouble. Especially if you're using tiles, 1 tile being 1 unit makes sense, in my opinion.

For more info, see this short article.

 

I'm using 1:1 pixels:units ration... 1920x1080 screen and those are my coordinates. Then I know that I can easily position objects to an exact pixel coordinate - the whole numbers match. This is partly because I also have some 'fake physics' is script-driven movement rather than using physics forces and this makes it easier to work with keeping track of where things are on the screen.

 

I don't think there is a "correct" way to do things, it heavily depends on the specifics and the scale of the game which setting is convenient:
-Tile based games: 1 Unit = 1 Tile (eg. if a tile is 64 pixel large, then 64 would be the Pixels per Unit (as seen in Jays blog))
-"Pixel-Games" (Pixel Perfect, Retro Pixel): 1 Unit = 1 Pixel
-Physics heavy games: 1 Unit = 1 Meter (e.g. a character could be 2 units tall, Pixels per Unit would be then round about half the pixel height of a humanoid character sprite at main resolution )
-Space Shooter: 1 Unit = Player Ship Height (in pixels)

Also like in 3D, if the transform coordinates you work with are always just small fractions or always in the thousands, then you might want to rethink your scale.

 

Thanks for this.

Ideally, you would be right. One can make arguments for 1 tile = 1 unit and 1 pixel = 1 unit for pixel art games, as one isn't necessarily more intuitive than the other. But I think that this goes beyond preferences, as some people report that having 1 pixel = 1 unit can break Unity physics. But I'm not sure if this is an issue with their project or an issue with this setting. This is why it would be great to get some official clarification on this setting.

 

I just switched over my test scene's sprites to use 100 pixels per unit and I keep getting the following error messages: "The collider did not create any collision shapes as they all failed verification." The shapes are now 1/100th of their original size, so a 32 pixel x 32 pixel box now has a box collider of 0.32 x 0.32. The object's size is 1. Isn't this a normal number?

 

One unit equals one meter in Unity default physics.
A setting of 1 pixel = 1 unit is therefore huge. For example if a Mario-like character was represented by just a small 32 pixels graphic he would be 32 meters tall for Unity physics. Of course this can be problematic if you want to build "realistic" physical behaviour.

[EDIT]
Don't know about that error. Does it appear when you add a polygon collider?

 

Yep, too small shapes, same error as me.

 

Is this for the default setting of 100 pixels per unit?

It appears when I add a Box Collider 2D or a Polygon Collider 2D to certain objects. My player character, with a Box Collider 2D collider of 0.08 x 0.04 (8 by 4 pixels) does not give me this error. I also checked the official 2D Platformer - the colliders are about twice the size, but still small, though they tend to be Circle Colliders 2D.

Circle Colliders 2D do not give me this error.

 

Tiles in my game are 32 pixels, so 32 pixels per unit.

 

And when I import the same sprite into the official Unity Platformer demo, and even reduce the Box Collider 2D down to something like 0.01 x 0.01 (1 pixel x 1 pixel, since 100 pixels = 1 unit), it works. For some reason, it doesn't work in my project, even though the Box Collider 2D is 32x as large.

 

The only part about a 1:1 pixel:unit ratio is that on the sprite importer you can just set the unit scale to a nice sensible '1', and then the sprite will be the correct size on the screen where you have e.g. a 1920x1080 coordinate system.

 

what happened if my game is 1920x1080 HD resolution ,and my tiles are 32x32px , characters less than 64, near 48px , houses 128x128 and huges castles near 200 px ...for a 1points perspective game such as Cadash (where you see the horizon and houses , village,trees and enemies... what about the math? so if my chacracter has 32x32 the corerct number willbe 0.32 x 100 = 32 ? I do not like improve or guess... I ve readen all the comments. but I am looking for types of calculation for my game for my way of doing... I use fixedupdate to control de physics. thx.

 

I am dealing with a problem that has me googling this very issue. What happened when I set pixels per unit to 1:1 was, everything felt and looked all cool and the gang until I had to write my own physics for a 2D controller. at 1:1 I have to use a gravity multiplier of 1000 just to bring the player character down somewhat fast. He still kind of floats. This breaks the fake physics in the game pretty much 50/50 as well. Everything shakes some times when I move. If I take the PPU to 16 or more all these issues magically disappear. What I hate about doing that is you have to start using decimals and S*** for all the scales and that messes up my pretty math! lol.. I am not sure why but I can report that it definitely needs some kind of counter measures to use properly. Maybe some scale script? Not sure. I'm going to use 16 ppu.

 

I use one pixel per a unit which I believe is necessary for pixel games; however I don't use physics for 2D games.

 

It's not necessary its just cleaner in inspector. However its all about powers of 2.

 

I have all my sprite sheets set to 16 ppu. This makes my collision box enter the decimal range instead of being the actual size of the physical sprite. The trade off is calculations are simpler and smaller scale. Fake physics still get messed up with massive numbers. How do you do collision detection without some sort of physics model? I'm not talking about Unity physics.

 

2D is simple because they are just rectangles, four values; x,y,w,h or left, top, width, height. You would simply check if a rectangle will be within the bounds of another rectangle and act accordingly. Anything more complicated than a rectangle can still be created and does not require Unity's tools to accomplish.