Unity 2021.3.16f1 インストール

Ocurus 2 を購入したときに Unity をインストールしていたのだが、ストレージを圧迫していたので削除してしまった。
いま・・・ Ocurus 2 はほとんど使っていない・・・(モノが悪いとかではなく、忙しかったのだよ)。

それからデスクトップPC も買い替えたし、ThinkPad T460s は人に譲ってそろそろ新しいのを買おうか、などと思っていたのだが、デスクトップPC だとコタツに入ったまま使えないのだよね。
そう、私はコタツで Unity の勉強したいがためだけにインストールをすることにしたのだ。

---

サイトからツールをダウンロードして、はいはいと進めていくと 2021.3.16f1 バージョンだった。

ツール自体は毎月リリースがある。

じゃあどれがいいんだよ、となるので LTS がある。
いや、そんな理由ではないと思うけど、LTS がないと安定したリリースが難しいし、サポートも受けにくいだろう。

Unity QA - LTS Releases - Unity
https://unity.com/releases/editor/qa/lts-releases

リストを見ると 2021年3月(だと思う)が最新のようだ。

しかし上から順に見ると、最後にリリースされたのが 2023年1月18日で 2020.3.44f1 だ。
2020年の 44版なのか？ 日付じゃなかったのか？？

いろいろわからんが Hub が進めてきたし、バージョンにこだわれる情報もないのでいわれたとおりにやっておく。

最初から Android 向けもインストールさせてほしいところだが、別々だった。

Android Studio はインストールされているので、そこの SDK なんかを使えばよいのだろう。
面倒だったのだ、いろいろ考えるのが。
それに SDK と一言で書かれてもバージョンが分からんしね。
にしても 2GB 近く持って行かれるんだねぇ。。。

 

そして私の ThinkPad T460s はもう7年も前のモデルだ。
Unity の開発環境をインストールするにはなかなか、かなり、けっこうつらいものがある。

 

Unity のインストール後なのかどうか忘れたが、JDK がいろいろインストールされていたので手動で削除した。
普段は JDK を使わないので Android Studio にインストールされているやつだけで十分なのだ。
が・・・ Unity で Android のビルドをしたときに怒られてしまった。
Unity のインストール時に既にインストールされていた OpenJDK のパスが設定されたのかな？
これは Edit > Preferences... > External Tools で Unity インストール時に使われている JDK を使うようにチェックすればよさそうだ。Android SDK のパスも Unity インストール時ではなく Android Studio でインストールされているパスになっていた。

Unityで見る位置を変えるのは右クリックしてドラッグ

めったに使わない Unity なので、いつも使い方が分からない。

オブジェクトの裏を見たいだけなのに！

https://learn.unity.com/tutorial/bolt-sceen-view-manipulator?uv=2019.4&projectId=5f0e8e30edbc2a1549c23a2c#5f0e9174edbc2a1a53868584

右クリックしてドラッグだった。
この手の操作って、トラックボールだとやりづらい機種がある。私の使っているケンジントンの手の平でボールを転がすタイプだとちょいと面倒だった。

 

あと、シーンビューの右上に出ているあれ。
「右クリックしてドラッグ」がわからないときに、あれをぐりぐりドラッグしたら視点が変わってくれないかと期待したのだがダメだったのだ。
正面向いたりなんかはできるようなのだが、あれは一体何なのだ？

シーンギズモ
https://docs.unity3d.com/ja/2020.3/Manual/SceneViewNavigation.html#gizmo

シーンギズモ、と呼ぶそうだ。

• X, Y, Z をクリックして視点を軸の方向にする
• 戻すときは右クリックして Free

他にもあるが、覚えられる気がしない。。。

Linuxでcompose upできたからといってMacでできるとは限らない

お仕事で Dockerfile や docker-compose.yml を書いていた。

自分の環境(Ubuntu 20.04)・・・OK。
Github Actions・・・OK。

ということでレビューしてもらったのだが、Mac の人がコンテナが立ち上がらなかった、ということがあった。

 

まずは落ち着くことだ。
しばしばあることなので、慌てないで良い。

 

docker の管理内で収まる範囲なら、そういうことはあまりない。
今まで見てきた中でそういうことが起きるのは、

• イメージを作ってコンテナを実行させる過程のどこか
• 永続化するためにファイルシステムをホスト側とつなげているどこか

が多かった。

今回は、Dockerfile で RUN してディレクトリやファイルの操作をしつつ、compose.yml の方でも volumes や entrypont を書いていて、Dockerfile でやった内容が volumes でマウントしたことで見えなくなった、みたいな感じだった。
そういう順番的なもので Linux と Mac の違いが出てくるとは思わなかったが、ドキュメントを探してもどれがどの順番で処理されるかの記述は見つけられなかった。

---

あとはありがちなのが、Permission denied だ。
未だに悩まされる。
ユーザ権限で動作する docker も experimental で出ているようだが、うまく動かない Dockerfile/compose.yml があったので使うのはやめておいた。というより、他の人が普通の docker を使っていたら混乱するので、全員合わせない限りはまだ使わないだろう。

Permission denied でどうするのがよいかよくわからんが、ユーザ指定はするようにした。
何も指定しないと root で動作するので、コンテナからしか書き込まないのであれば問題ないと思うが、ホスト側で作ったファイルを読もうとすると面倒なことになる。あと、ホスト側からそのファイルを見たいときに sudo しないといけないのが地味に嫌だったりもする。

わかりにくいのが、イメージ側が持っているユーザID とホスト側のユーザIDが一致しないときだ。
Linux で最初にアカウントを作るとだいたい 1000 から始まって、それから 1001, 1002 とユーザが追加されるごとにインクリメントされる。
ホスト側が 1001 のユーザでイメージが 1000 だった場合も権限が違うので Permission denied になるだろう。

なので面倒だが id -u や id -g で与えるようにしている。
これをうまいことやってくれるのがユーザ権限で動作する docker かもしれんが、よく知らん。

[docker] いろいろ止めて削除したいとき

docker で遊んでいると、コンテナがたくさんできていたりイメージができていたりして、全部忘れたいことがある。

docker stop `docker ps -qa` && docker rm `docker ps -qa`
docker rmi `docker images -qa`
docker volume rm `docker volume ls -q`
docker network rm `docker network ls -q`

1行目でコンテナを止めて削除。
2行目でイメージを削除。
3行目でストレージを削除。
4行目でネットワークを削除。

イメージは --force で強制しないといけないことがあるのかもしれんが、よくわからん。

それぞれ .bashrc などで alias にしておくと楽かもしれんね。

Dockerfile に USER がないときに docker run -u を指定した場合

docker run -u の説明では Dockerfile の USER を上書きすると言うことだったが、では Dockerfile に USER がなかったらどうなるかが気になった。
まあ、予想は付くが・・・。

$ docker run -v "$PWD/hello_dir:/data" -u 1002:1002  hello-test
[abc]: Hello, Docker!?
[abc]: ReadMe!

$ ls -l hello_dir/abc/
total 8
-rw-rw-r-- 1 hirokuma hirokuma  8 Jan  8 21:48 read.txt
-rw-r--r-- 1 hirokuma hirokuma 15 Jan  9 17:54 test.txt
$

まあ、そうよね。

• Dockefile に USER の記述がない場合は「USER root:root」である。
• docker run -u は USER を上書きする。

とするか、

• docker run -u はユーザ切替を行う(Dockefile の USER よりも優先される)

のような書き方が良いのかね。

そう考えると、カレントユーザになるかならないかはっきりしない USER 指定よりも、何も書かずに root になる方が気付きやすいかもしれない。下手にカレントユーザの UID と Dockefile の USER で指定したユーザの UID が一致すると、うまくいく環境といかない環境が出てきて、何が原因かが分かりづらい気がするのだ。 root になっていると「ああ root だったらダメよね」と気付きやすい。

実に悩ましい話だ。