Unityでドット絵がぼやける時の直し方｜設定3点と原因

Unityのドット絵がぼやけるのは、描き方が悪いからではなく、インポート時にBilinear補間とテクスチャ圧縮が既定でかかるからです。
Asepriteではくっきりしていた16x16のタイルセットをUnityに入れた瞬間にモヤッとしたとき、原因がFilter ModeのBilinear設定だと分かって脱力した経験が、そのままこの問題の本質を示しています。
症状は「全体がぼやける」「タイルやスプライトの境目に線がにじむ」「動かすとガタつく」の3つに分けて考えると、インポート設定・Quality設定・カメラ設定のどこを直すべきかが見えます。
まずFilter ModeをPoint(no filter)、CompressionをNoneにし、Pixels Per Unitをタイルサイズに揃えるところから始めれば、最も多い全体ぼやけはほぼ解消できます。

ぼやける・にじむ3つの症状をまず切り分ける

Unityのドット絵がぼやけたりにじんだりするときは、まず症状を三つに分けて見るのが近道です。
全体がぼんやりするのか、タイルやスプライトの継ぎ目に1px幅の線が出るのか、止まっていると綺麗でも動かすとガタつくのかで、触るべき設定レイヤーがまったく変わります。
ここを曖昧にしたまま調整すると、別の症状が残って「直ったようで直っていない」状態に見えることがあります。

全体がぼんやりする

この症状は、まずインポート設定を疑うのが基本です。
Unityはインポート時にデフォルトでBilinear補間と圧縮をかけるため、何も設定しないドット絵は最初からにじみます。
描き手の線が甘いのではなく、Filter Mode と Compression がピクセルを丸めてしまっているだけなので、ここを Point（no filter）と None に変えるのが最短です。
加えて Pixels Per Unit をタイルサイズに合わせ、Max Size も実寸以上にしてから Apply まで通しておくと、素材側のぼやけをかなり早く止められます。

同じプロジェクトで、全体のぼやけだけはすぐ解消できたのに、タイルの継ぎ目だけ残って数時間溶かしたことがあります。
そのとき痛感したのは、見た目が似ていても原因は別だということでした。
インポート由来のぼやけは素材単体の問題ですが、境目の線は画面上でスプライト同士がどう並び、どう描画されているかまで見ないと解けません。

タイル・スプライトの境目に線がにじむ

タイルマップや隣接スプライトの境目に出る1px幅の線は、全体ぼやけとは別系統です。
これはテクスチャブリードや補間の影響が表面に出ている状態で、Quality 設定、UV の取り方、Sprite Atlas の扱いまで関わってきます。
Project Settings > Quality で Anti Aliasing をオフにし、Generate Mip Maps も切り、Atlas 化するならパディングを足して境界へ色が漏れないようにします。
見た目の症状は小さくても、放置するとマップ全体の印象を崩すので、ここはインポート設定とは分けて考えるべきです。

このタイプは、単純に画像を高品質化しても消えません。
なぜなら、隣り合うスプライトの端が画面上でサブピクセル位置に乗ると、境界線に背景色や隣接色が混ざって見えるからです。
つまり素材の解像度より、配置精度と描画経路が効く症状です。
全体がぼんやりする章を先に直してから残る線を見れば、原因の切り分けがしやすくなります。

止まっていると綺麗だが動かすとガタつく

静止時は綺麗なのに、動かすとだけガタつくなら、問題はカメラ側です。
Unity では画面解像度が変わると表示倍率が中途半端になりやすく、その結果、スプライトがサブピクセル単位で揺れて見えます。
公式の 2D Pixel Perfect Camera コンポーネントを MainCamera に入れ、Asset Pixels Per Unit をシーン内スプライトと揃え、Reference Resolution を 320x180 や 640x360 のような 16:9 の低解像度に置くと、整数倍スケールを保ちながら表示しやすくなります。
Pixel Snapping をオンにしておけば、移動時のちらつきも抑えやすいです。
手動で運用するなら、Orthographic Size の計算を崩さないことが肝になります。
縦解像度を基準に 1:1 表示へ合わせ、拡大率は 2 や 3 のような整数に固定してみてください。
中途半端な倍率は、止まって見える瞬間だけごまかせても、動いた瞬間に破綻が出ます。
だからこそ、この症状は「画面の見え方」ではなく「カメラのスケーリング仕様」として扱うほうが整理しやすいのです。

インポート設定でまずぼやけを消す

Unityでドット絵がぼやけるとき、まず疑うべきなのは描き方ではなくインポート設定です。
Filter Mode、Pixels Per Unit、Compression、Max Sizeの4点をそろえるだけで、にじみの大半は止まります。
設定を変えたら必ずApplyまで押して、見た目が変わるところまで一気に直しましょう。

Filter ModeをPoint(no filter)にする

スプライトを選んでInspectorを開き、Filter Modeを既定のBilinearからPoint (no filter) に変えると、ピクセル間の補間ぼかしが止まり、輪郭がそのまま立ち上がります。
ドット絵がにじむ原因の中ではこれが最優先で、Asepriteで見ていたはずの硬いエッジが、Unity側だけ丸く溶ける問題を最短で断てます。
PointにしてApplyを押した瞬間、表示がAsepriteと寸分違わぬくっきり感に戻って、思わず声が出るはずです。
たった1項目で世界が変わる感覚でしょう。

Pixels Per Unit(PPU)をタイルサイズに合わせる

Pixels Per Unitは既定100のまま放置しないで、16x16タイルなら16、32x32タイルなら32に合わせます。
ここがずれていると、1枚1枚のスプライトは正しく読み込まれていても、シーン上では極端に小さく見えたり、逆に想定外の大きさになったりします。
実際、PPUを100のままにしてキャラが小さすぎるため、カメラを必死に寄せていた失敗は起こりがちです。
タイルサイズに直した途端、1ユニット＝1タイルの感覚にそろい、レベル設計もかなり扱いやすくなります。

Compression=None・Max Sizeを実寸以上に

CompressionはNormal QualityからNoneに切り替えます。
圧縮が入ると色ズレや輪郭のノイズが乗り、細い線ほど汚れて見えますが、ドット絵は容量が小さいので圧縮を切っても困りにくいのが利点です。
あわせてMax Sizeが画像の実寸より小さくならないよう確認しましょう。
64x64の画像なら64以上、標準の2048から下げている場合も、実寸を下回るとUnityが勝手に縮小してぼやけます。
設定後はInspector下部のApplyを押すこと。
押し忘れが反映されない典型ミスです。

Pixel Perfect Cameraで解像度が変わっても崩さない

解像度が変わってもドット絵を崩さないには、インポート設定だけでなくカメラ側の倍率を整数で揃える必要があります。
そこで使うのが、2D Pixel Perfectパッケージに含まれるPixel Perfect Cameraです。
URPでは標準同梱なので、MainCameraに追加しておくと、表示サイズが変わった場面でも中途半端な拡大を自動で抑えられます。
配布前に別解像度のPCで試したとき、自分の環境では綺麗だった絵が急にぼやけて青ざめたことがありましたが、このコンポーネントを入れてからは全解像度で安定し、救われました。

2D Pixel Perfectの導入とコンポーネント追加

2D Pixel Perfectは、ドット絵を画面に出すときの「最後の崩れどころ」をカメラ側で面倒を見るための仕組みです。
スプライトを正しく用意していても、Gameビューの表示倍率が半端だとピクセルがにじみます。
Pixel Perfect Cameraはそこを整数倍のスケールに寄せてくれるので、インポート後に残る微妙なぼやけをまとめて抑えられます。
MainCameraに追加するだけで効くので、最初に入れておく価値が高いです。

Asset PPUとReference Resolutionの正しい値

Asset Pixels Per Unitには、シーン内スプライトと同じPPU値を入れます。
たとえばスプライト側が16なら、ここも16です。
ここがずれると、同じ画面内でもスケールの基準が食い違い、せっかく整えた輪郭が再び崩れます。
実際にAsset PPUを適当な値にして試したときは、むしろ表示が荒れてしまい、結局スプライト側のPPU(16)と揃えた瞬間に直りました。
値の一致が肝だと痛感する場面です。

Reference Resolutionは、ドット絵を設計した想定解像度を入れます。
320x180や640x360のような16:9の低解像度を使うと、画面全体を整数倍で拡大しやすくなり、余計な補間が入りにくくなります。
つまり、見た目の美しさを「いまのモニター解像度」に合わせるのではなく、「元の絵をどの大きさで見せるか」に戻して考えるわけです。
シーンビューでは緑の実線枠がGameビューの表示範囲、点線枠がReference Resolutionとして見えるので、どこまでが基準の見え方かを確認しながら詰められます。

Pixel Snappingで境界のにじみを抑える

Pixel Snappingをオンにすると、スプライトがワールドのグリッドにスナップし、移動時のにじみが減ります。
移動中だけ輪郭がふわつく現象は、半ピクセル単位の位置ずれが原因になりやすいので、ここを揃えると歩行アニメや背景スクロールの印象が締まります。
特にキャラクターと背景の両方を動かす場面では効きやすく、細い線や境界が多い絵ほど違いがはっきり出ます。
Pixel Perfect Camera、Asset PPU、Reference Resolution、Pixel Snappingをそろえておけば、解像度が変わっても崩れにくい表示になります。

Pixel Perfect Cameraを使わない場合のカメラサイズ計算

MainCameraにPixel Perfect Cameraを追加して、2D Pixel Perfectパッケージの機能で表示倍率のズレを吸収すると、インポートを直しても残るカメラ側のぼやけをまとめて抑えられます。
Asset Pixels Per Unitはスプライト側のPPUと一致させ、Reference Resolutionはドット絵を設計した前提の解像度に合わせて決めましょう。
緑の実線枠と点線枠の見え方を確認しながら整えると、どこで表示が崩れているかも追いやすいです。

Orthographic Sizeの基本計算式

Pixel Perfect Cameraを使わず手動で合わせるなら、Orthographic Sizeは画面の縦解像度を2×PPUで割って求めます。
縦1080、PPU100ならSizeは5.4です。
目分量で5や4に変えても直らなかったのに、この式で5.4を入れた途端にピタッとくっきりした、という経験は珍しくありません。
数字に根拠があると、直感ではなく仕組みで合わせられるのが強みです。

Orthographic Sizeはカメラの縦半分が何ユニット分見えているかを表す値なので、PPUと噛み合わないと1ドットが画面上の小数ピクセルにまたがります。
その瞬間、輪郭はにじみ、線は少しだけ揺れた見え方になります。
逆に言えば、スプライトのPPUとカメラの見え方をそろえるだけで、余計な補正を入れなくても表示は安定します。
MainCameraにPixel Perfect Cameraを入れる前でも、まずこの関係を押さえておくと理解が早いでしょう。

拡大率を掛ける場合の式

ドット絵を2倍や3倍で見せたいなら、Orthographic Sizeは縦解像度÷（PPU×拡大率）×0.5で求めます。
ここでの拡大率は整数倍が前提で、1.5のような中途半端な値にすると、せっかくのドットが「なんか惜しい」ぼやけ方をします。
実際、1.5で悩んでいた表示を2に直したら、一発で解決しました。
整数倍の気持ちよさは、見た目だけでなく調整時間の短さにも出ます。

この式が効くのは、Reference Resolutionを基準に画面を考えやすくなるからです。
たとえば320x180や640x360のような16:9の低解像度を想定しておくと、どの倍率で見せたいかを決めやすく、Pixel Perfect Cameraの自動スケールとも発想が揃います。
Asset Pixels Per Unitには、シーン内スプライトと同じPPU、たとえば16を入れておくと崩れにくく、設計値がひとつにまとまります。
バラバラなPPUのままでは、倍率計算が合っていても表示の土台がずれてしまうためです。

整数倍スケールが崩れない理由

整数倍であれば、元の1ドットが画面上でも2ピクセル、3ピクセルと素直に広がります。
ところが1.5倍のような倍率では、1ドットの幅が半端なピクセル位置に落ちやすく、境界がにじんで見えます。
Pixel Snappingをオンにするとスプライトがワールドのグリッドへ吸着し、移動時のにじみも抑えられます。
緑の実線枠がGameビューの表示範囲、点線枠がReference Resolutionを示すので、シーンビューで見比べながら詰めると把握しやすいです。

手動計算は仕組みを理解するには向いていますが、解像度が変わるたびに計算し直す手間が残ります。
MainCameraにPixel Perfect Cameraを追加しておけば、2D Pixel Perfectパッケージの自動処理で整数倍のスケールを保ちやすく、複数解像度を想定する現場でも扱いやすいです。
表示の土台をコンポーネント側に任せ、スプライト制作ではPPUとReference Resolutionをそろえる。
ここまで整えると、インポート後に残ったわずかなズレまで追い込みやすくなります。

タイル間ににじむ線が出る時の対処

タイルの継ぎ目に1px幅の線や隙間が出るときは、全体のぼやけとは別に、テクスチャブリードとサンプリング設定を疑う必要があります。
床を敷き詰めたタイルマップでカメラを動かすたびに細い線がチカチカ走ると、ステージ全体が安っぽく見えてしまうものです。
まずはアンチエイリアス、次にMip Maps、そして最後にSprite Atlasとパディングを順に詰めていくと、原因の切り分けがしやすくなります。

アンチエイリアスとMip Mapsをオフにする

境界線が目立つ最大要因はアンチエイリアスです。
Project Settings>QualityでAnti Aliasingをオフにすると、移動中に浮いていた細い線がまず落ち着きます。
見た目を滑らかにするはずの処理が、ドットの輪郭に半端な色を足してしまい、タイル同士の接合部をにじませるからです。
Pixel Snappingも併用すると、カメラ移動中の座標ずれを抑えやすくなり、線の再発をかなり減らせます。

Generate Mip Mapsも同じく切っておきたい設定です。
縮小表示のたびに隣のピクセルが混ざり、タイルの端に薄い色が出やすくなるため、ドット絵ではむしろ邪魔になります。
最初はここを見落として、AAだけ切ってもまだ線が残り、原因が別にあると気づくまで時間がかかりました。
縮小前提でない素材なら、Mip Mapsは持たせないほうが素直です。

Sprite Atlasでパディングを付ける

それでも線が残るなら、UVのはみ出しが原因です。
スプライトをそのまま並べると、わずかなサンプリング誤差で隣のテクセルを拾い、タイルの端に境界線が出ます。
Sprite Atlasにまとめてパディングを付けると、この拾い込みを防げます。
とくに複数の床タイルや壁タイルを組み合わせる場面では、素材ごとの境目が見えやすいので、アトラス化の効果がはっきり出るでしょう。

この対処のよさは、単に線を消すだけではありません。
素材がひとまとまりになることで、描画の安定感が増し、移動中でも画面が締まって見えます。
Mip Mapsまで切り、パディングも足した段階でようやく線が消えたとき、Sprite Atlasの存在意義を初めて実感しました。
タイルの継ぎ目をきれいに保つには、見た目の問題ではなく、素材の扱い方そのものを整える必要があります。

それでも線が残る時の確認点

設定を詰めても消えない線は、Pixel Snappingと整数倍カメラの組み合わせを見直すと解消しやすいです。
カメラが中途半端な座標を通ると、タイルの端が1pxずれたように見え、細い隙間が出ます。
整数倍で表示し、スナッピングで位置を固定すると、移動中のチカチカした線がほぼ消えるはずです。

それでも残る場合は、タイル素材の端に余白が足りないか、アトラス化のパディングが小さい可能性があります。
ここまで来ると、単なる表示設定ではなく、素材の配置精度の問題です。
床を敷いた瞬間から安っぽく見える線は、見た目以上に印象を壊します。
だからこそ、AA、Mip Maps、Sprite Atlas、Pixel Snappingを順に揃えていく流れが有効です。

再発させないチェックリストとよくある勘違い

新しいスプライトを足した瞬間にぼやけるなら、見るべき箇所はほぼ決まっています。
Filter Mode=Point、Compression=None、PPUの統一、そしてApplyの押下。
この4点を手順として固定しておけば、毎回の「また直すのか」という往復を減らせます。
設定そのものより、確認順を習慣に落とすことが再発防止の近道です。

新規スプライト追加時の4点チェック

新規スプライトは、追加するたびに同じ条件で扱う必要があります。
Filter Mode=PointとCompression=Noneをそろえ、PPUも既存資産と合わせ、最後にApplyまで確認する流れを崩さないことが肝心です。
どれか1つでも抜けると、見た目だけが崩れて原因の切り分けに時間を取られます。

PPU統一とApply忘れの防止

PPUはプロジェクト内で基準値を1つ決め、全スプライトで揃えるのが鉄則です。
ここが混ざると、Pixel Perfect Cameraの見え方だけでなくカメラ計算そのものがずれていきます。
とくに追加直後は、Inspectorで値を変えただけで満足しやすいので、Applyを押して実体に反映されたかまで確認しましょう。
設定が合っているつもりで再びぼやける場合、実は保存前のままだった、という流れは珍しくありません。

プレビューだけぼやける誤認に注意

Gameビューが2xのような整数倍Scaleになっていないと、設定が正しくてもプレビューだけぼやけて見えます。
ここで「まだ直っていない」と判断すると、スプライトやカメラを何度も触ってしまい、不要な修正に時間を溶かします。
実際に一通り見直したあと、原因がGameビューScaleの奇数倍だった、というオチはよくある落とし穴です。
拡大率やカメラサイズを中途半端な小数にしないこと、そして表示倍率と実体を分けて確かめることが、誤認を避けるいちばんのコツでしょう。