2025年11月19日水曜日

フォントの拡張

絵文字まで含めてフォントを考える。

絵文字はどうしても正方形に収めるという、無意識の制約が発生してしまうのであるが、もしかしたらそう言った制約も不要では?というアイデアである。
大きなタワーとか、大きな橋とか、色々。

フォントや絵文字である以上、アイコニックにして「一発で誰でも【それ】と視認できる」ようにすることが命題のため、正方形に入り切らない場合は縮尺を変えたり、はみ出した部分は見切ってしまってたりする。

しかし、そう言った切り捨ててしまってた箇所も情報としては持ってていいのでは?というアイデアである。

また、絵文字の大元(オリジナル)はあっても良いが、それを「どう見せるか」(最終系)はある程度幅があっても良いのでは?というアイデアでもある。

具体的には、大元(オリジナル)となる情報(画像)がベースにあって、それをどのアングルからとか縦の縮尺とか横の縮尺はどれくらいでとか画角を決めて最終系にすれば良い。
これによって、これまでは単純に正方形からはみ出した部分は切り落としてただけであるが、そう言った入りきらない情報まで救い出すことが可能となる。

またこれは、2D (平面) に限らずに 3D (立体) や 4D (3D動画) にも拡張可能となる。
現在の絵文字時点でも、ほとんどの絵文字はオリジナルは3Dであるが、絵画のプロはプロの技巧でアイコニックに3Dを2Dに変換して描いている、とも言える。
この辺をもう少し真面目に(本気に)取り組みましょうという話である。

究極を言えばオリジナルは全て3D (4D)で良いはずである。
それをどのように2Dの最終系にアイコニックにアウトプットするかは、縮尺やポストプロセスの処理とも言える。(それこそAIで学習可能な領域。絵画師の商売が上がったりになってしまうかもしれないが^^;(ここに限った話ではないことはご承知の通り))

「アイコニックに視認しやすいように」という命題を差し置いて、フローだけ抜き出せば、
・オリジナル情報
・ポストプロセス(縮尺や効果(フレアとか)や色合い等の調整)
・最終画角(カメラ)
と言った感じになるだろう。(ものすごく単純化して書いた)
この辺はプロの現場のアニメーション制作フローや、3Dゲーム・アニメのフローと同様のことである。それぞれにプロが活躍してる通り。

これを真面目にフォントと絵文字にも適用しましょう(とりあえずやってみましょう)というアイデアである。
かなり先進的なアイデア・仕組み・機構なのであるが、公表することで特許関係の利権は誰も取れなくなるため、それよりも公表して共有することでオープンソースで広まった方が良いと思ったため、勿体無いがここに公表する。


ーーーーー
ここまで考えると、実は本来の「文字としてのフォント」も全く同じことが逆適用可能であることが分かってくる。

無論ほとんどのフォントは大元(オリジナル)は3Dである必要はないかもしれないが、敢えて3Dをオリジナルにしておくことで得られるものもあるだろう、ということ。
ここまでいくと「文字の発祥」的な考古学とか、または「なぜこのデザインになった」的な人類の美術史とかデザインの起源的な分野になってくると思うが、実は文字も3D的な考察によって得られるものがあるはずである。(また新たな分野を発掘してしまった^^)
ある程度まで文字が確立された以降は自然と2D的なものという共通認識が出来上がって、現存している文字のおそらく80%とか90%とか99%は2Dなのだろう。(誰も文字が実は3Dでは?と発想する人さえいないだろう。)
文字が確立する前とか、そもそも【文字】と言う概念を勝手に作ってああだこうだ言ってること自体が烏滸がましいことであって、本来はもっと自由なものであった。
おそらく文字の概念ができる前の人からしたら、「勝手に2次元に縛り付けるな!」と怒ることであろう^^;
2Dと言う共通化(及び当然【文字】と言う共通化)を手に入れた反面、文字以前の3D的な概念を捨ててしまったのである。
※この考え方もあらゆる分野に応能可能。我々は技術を手にする一方で見えなくなってしまった点はものすごくたくさんある。淘汰的観点からは「そっちを削ったほうがこっちは実際上うまくいく」と言うものであって、実際には極小解に囚われているだけかもしれない。
技術の発展によって、「実は現在の極小解よりもより安定した解が見つかった!」と言ってパラダイムシフトが起こるものである。
これまでは生身の我々を用いて実生活を通してそういったシフトを行ってきたわけではあるが、これからはここに書いた通り「極小解と思ってたけど違うんじゃない?」と言うムーブメントによって、本当に驚くほどたくさんの広い領域でパラダイムシフトが発生するのである。

ーーーーー
色々と考察は尽きないが、技術屋的な視点では、単純に全てを同じ仕組みで統一できるので美しいですよね?というだけはあるが。

壮大な計画にはなってきたが、ここにその一端を記す。

ーーーーー
応用としては、上記で「アイコニックにすることは差し置いて」と書いた通りであるが、ポストプロセスを置き換えれば、目的に応じて自由自在にアウトプットは調整可能である。
「絵文字にふさわしい」アウトプットをお望みであれば、絵文字の「答え」を学習させてポストプロセスを作成すれば良い。(まず最初に作る仕組みはこれになるだろう。)
企業やお店やゲームなどの「テーマ」に沿ったものがお望みであれば、テーマさえ学習さえすれば、絵文字まで含めて一瞬でテーマに沿ったフォントと絵文字が出来上がる。
(このアイデアのすごいところは「奥行き」まで含めてポストプロセスでテーマに沿った調整が可能な点。)
「それ以外に何があるんだ?」とちょっと考えるが、もはやフォントや絵文字の概念にとらわれる必要さえ無くなってくるのである。

このアイデア・仕組み・機構の可能性は無限大であるため、ここに特許関係も無効化しておいたため、世界の知恵と技術で大いに活用・発展させていただければと思う。

ーーーーー
また、本来のフォントに舞い戻ってきても、可変幅フォント(プロポーショナルフォント)は実は上記で言うところの第三工程の最終画角の動的変更処理であることが分かる。
前後の文字もパラメータにすれば前後関係で動的に調整が可能になる。
これは大いに絵文字にも応用が可能。

更に3D化及びデザイン的な点に踏み込めば、これまではフォントデザイナーさんのセンスに頼っていた点が、3D的な「意味を持った」数値として、人間の知覚として最も安定・安心・納得する調整が可能になってくる。
(そしてこの考え方は、従来の2D的なフォントの文字感調整にもフィードバックが可能。「3D的にこうだったたため、2Dとしてこれがしっくりきていたんだ!」と再認識が生じる訳である。)

※もしかすると、いきなり3Dで実装するのは大変なので最初は従来の2Dフォントにおいて、ここに挙げた超・動的かつプログラム可能で数値に裏打ちされた「人間にしっくりくる」フォントシステムが作られるのかも、と思った。


2024年12月15日日曜日

画面サイズ確認

 現在の画面サイズを確認できます。

※Javascriptの機能で取得できる値ですので、実際の画面サイズとは異なる場合があります。

No.項目幅 (Width)高さ (Height)備考
1screenスクリーンサイズ
2screen availdスクリーンの有効幅
3devicePixelRatioOSの表示スケール
4スクリーン解像度表示スケールから逆算したスクリーン解像度

使用しているJavascript変数
1. screen
    window.screen.width
    window.screen.height

2. screen avail
    window.screen.availWidth
    window.screen.availHeight
    画面のウェブコンテンツに利用することができる範囲のサイズ。
    タスクバー(Windows)やDock(Mac)などを除いた範囲。

3. devicePixelRatio
    window.devicePixelRatio
    解像度と物理ピクセルの解像度の比。OSで設定してる値。
    Windows: 設定 → システム → ディスプレイ → 拡大縮小とレイアウト
        例: 150%にした場合、devicePixelRatioは 1.5 となる。
    Mac: System Settings → Displays → Advanced... → Show resolutions as list で解像度一覧が表示される。
    Android (Android 13の場合): 設定App → 画面設定 → 表示サイズとテキスト → 表示サイズ
   adb でAndroid端末に接続すればより細かい設定が可能。

4. スクリーン解像度
    表示スケールから逆算したスクリーン解像度。
    つまり、1.screen × 3. devicePixelRatio

参考: MDN Web Docs

2023年11月19日日曜日

【Unreal Engine 5.2】macOS で新しいバージョンの Unreal Engine に更新されなかった

macOSでUnreal Engine 5.3.0 を入れて使っていた。
数ヶ月前に UE 5.3.1 や UE 5.3.2 がリリースされたというニュースは見ていたが、私の Epic Games Launcher では通知が来ておらず、「あれ?Windowsだけが対象なのかな?(UE 5.0, 5.1, 5.2 では、そんなことなかったけど。。)」と思っていた。

作業では「My Projects」からプロジェクトを起動して作業するだけで、問題なく使えていたためあまり気にせずにいた。
しかしThird Person Projectで試したいことがあって、「Engine Versions」側から「Launch」をクリックすると、「Queued」と表示され、いくら待っても起動できなかった。
Epic Games LauncherとかOS再起動とかしてもダメだった。

ネットを検索しても UE 5.3.1, 5.3.2 が macOS 対象外という情報はやはり出てこない。
何か私の環境がおかしいと思い、以下を実施したところちゃんと UE 5.3.2 も出てきてインストールできました。
・Epic Games Launcher で一旦 UE 5.3.0 をアンインストール 
(Launch ボタンの右の🔽 → Remove)
・Epic Games Launcher 再起動


画面サンプル。本来は赤枠の箇所辺りに⚠️New Version of Engine Available みたいな表示が出るはず。

(考察)
そういえば UE 5.3.0 を使ってる時に、マーケットプレイスで取得したもの(Launcher 上だと「VAULT」)でバージョンアップの通知が来ており、探してみたが一体どれなのか見つからないことがあった。2 〜 3 回見直したが結局見つけられなかった。(数が多いと探すのが大変… この辺改善できないでしょうか?😅)

なんかその辺からおかしかったのかもしれない。
(何かのダウンロード不正が知らぬ間に起きており、そのせいでキューが詰まってた感じですかね?)

かなりレアケースだと思いますが、同じような症状の方の一助になれば幸いです。


2023年9月5日火曜日

macOSで日本語入力する際に気になること

かなり細かい話だが、macOSで日本語入力していて、いつも気になってしまう点がある。

それは、は行を入力する場合で、「h」をタイプすると小文字の
hが画面表示され、母音入力待ち状態になる訳だが、
「Iビーム」つまりカーソル位置を表す「|」縦棒と重なって
hが大文字のHに見えてしまうのである。

勿論一瞬なのではあるが、どうしても視覚が認識してしまうのであるから
しょうがない^^;

なので「おやっ!?知らず知らずの内に、キャップスロックを入れてしまったかな?」
と毎回不安になってしまうのである。

おそらく共感してくれる方もおられるだろうと思う。
(他のOSはどうなってるんだろう?またたったこれだけのために
 改善とかしてくれるものなのだろうか?)

※もしもこれを「読むこと」によって、これまで気になって無かったにも関わらず
気になり出してしまうこともあるかもしれないため、ご注意ください。
逆に言うと、これまでは無意識の違和感だったものが、これによって理由が
明確になった、とも言えるかもしれません。

※Windowsで確認したところ、Iビームが長かったり太かったりしており、入力文字とIビームは区別できるため気にならなかった。
macOSの場合はどうも入力文字とIビームが、線の太さや大きさが似通ってしまっているため、本稿の通りの視認上の問題が出てきてしまっているようである。

物書きさんとかデザイン関係の方だとこの辺の視認的な感覚も一般の人よりは研ぎ澄まされているので、余計に気になるのではないだろうか?
そしてmacOSはデザイン分野とかアート分野にシェアが広いようなイメージがあると思うので、尚更この点について些細なことではあるが「大丈夫かな?」と心配になった次第である^^;

(それとも本稿の問題点はそこまで気にする人はほとんどいないのだろうか?…
 まぁ慣れと言えば慣れの問題かもしれないが、まっさらな状態で気付いた「おやっ!?」という点は人の感覚の発現なので何かしら微かな違和感が潜んでいるはずで、そういう点は大切かと思いました。(アート分野の方であればなおさらその辺の感覚は大切にされてるはずでは!?))

-----
Macの日本語変換について。
スマート変換で入力してると、最初は意図した通りの変換が表示されてるのだが、変換を確定せずに入力を進めていくと先頭の方の変換がずれることがある。
変換修正するために矢印キーで先頭に戻ろうとすると、なぜか該当部分の単語(文節?)が増殖してしまい、毎回泣きそうになる。。。ユーザ離れしないためにも早急に修正を望む。

あと変換精度も色々言われてるのでここでは深く突っ込まないが、「にじ」と打って変換しても「二次」が候補にすら出てこなくて、これまた泣きそうになった。
心を無にしてShift + 左キーを押して「二」と「次」で一字ずつ変換してます✌️




2023年8月15日火曜日

macOSでのウィンドウ切り替え操作について

Macで作業していて、YouTubeの解説動画を見ながら作業をしたいことがある。

解説動画の文字が小さい場合はフルスクリーンにして見るのだが、解説動画の通り操作するため動画を一時停止してコマンド+タブ(⌘ + →| )で、作業用アプリケーションに切り替える。

ここまでは良いのだが、解説動画の続きを見ようとして再度コマンド+タブを押すと、フルスクリーンにしたYouTube画面には戻ってくれず、別のアプリケーションに切り替わってしまう。
これを実に何百回も性懲りも無く繰り返してしまうのである。。。😢
(多分同じお悩みをお持ちの方は、実は相当数の方がおられるのではないかと感じる。)

これは、Mac的には「操作スペース(英語:Spaces)」が異なっているため、コマンド+タブでは切り替えられないらしい。
「操作スペース」を切り替えるには、別のショートカット:コントロール+右矢印( ^ + → ) で切り替えるのがMacの流儀となっているらしい。
(ショットカット設定はシステム設定(System Settings) → キーボード(Keyboard) → キーボードショートカット(Keyboard Shortcuts...) → Mission Controlで確認できる。 (Move left a space / Move right a space ))
(また、Macbook Proなどトラックパットがある場合は、4本指スワイプでも切り替えられますね。)



※Windowsにも同じように、Windowsキー+タブで「デスクトップ」を切り替えられる機能がありますね。Windowsの場合もデスクトップが異なるとALT + Tab ではアプリケーションを切り替えられることは不可能ですね。


そこまでは分かったのだが、しかし、YouTubeをフルスクリーンにしただけで「別の操作スペースに移動された」ということは、一般ユーザーにはあまり直感的ではないと思うのだがどうだろうか?(その辺の直感性とかUXとかはむしろAppleが一番嫌うはずでは???)

ということで、もちろん議論に議論を重ねた上でのApple精神みたいなものに則った上での「答え」として世の中に出してはいるのだろうが、それでも多くのユーザの「直感」とは少しズレてる(失礼!)という点で書いておくこととする。

切り口を変えていうと、Appleがユーザに求める操作は、
・ユーザ自身で対象画面をフルスクリーンにしたかどうかを記憶しておくこと!
・フルスクリーン(別の操作スペース)に切り替える場合は、コントロール+→
 それ以外はコマンド+タブで画面を切り替えること!
ということを暗黙的に求めている、ともいえよう。

しかしユーザとしては作業に集中したいのに、いちいち「このYouTubeは細かい文字がないからフルスクリーンにはしてない、こっちは細部を見たいのでフルスクリーンにした」を覚えておかなければならず、コントロール+→ と コマンド+タブ を押し間違えると、ものすごく時間の浪費を感じるのである。

ということで、いろいろ書いてしまったが、言いたいこととしては、崇高なApple精神を曲げてもらう必要は全くないのだが、初期状態ではなくても良いので、回避策を公式に用意しておいてもらいたいと思ったばかりである🙇‍♂️

※そこまで考えるとAppleが考える方針と照らし合わせると、「フルスクリーンにしただけで別のスペースになる」というのが果たして方針・定義通りなのか?という問題とも思えてくる。ユーザの同意とか明白な認識のもとに別スペースにしたかどうか?ということ。

2023年8月12日土曜日

【Unreal Engine 5.2】PCG(Procedural Content Generation)がリリース

Unreal Engine 5.2でPCG(Procedural Content Generation)がリリースされました。

この機能はプロシージャルに、つまり数値だけ与えれば自動的にコンテンツ(メッシュとか)を生成してくれる機能です。

これを見て、私も同じことを既にブループリントで作ってたので、ついにEpic社も私の真似を始めたのだと思いました^^(絶対にそんなわけはないのだが。加えて既に多くの方が同じことをブループリントで作っていたことでしょう。。)

こちらが自作PCGを使って作成したビデオ👇 最後の増殖シーンで使ってます。


同じことをやりたい場合は、今後は公式のPCGを使えば良いので詳細は割愛するが、一応以下が作ったブループリント。


クリボー(あ、言っちゃった)をだんだん早くスポーンさせたかったので、スポーンスピードも変えれるという画期的機能も実装済みである!これも多分PCGで真似するだろう(あ、もうされてる!?)

もちろん、Line Traceを使って、地形に合わせた接地処理も行なっている!
※一部、木の途中に生えてしまったクリボーもいますが😅

また、ブループリントクラスをスポーンしてます!1人ずつのクリボーがブループリントとなっており、スポーンと同時にちょっとずつ大きく成長するスクリプトが組まれているため、大量のクリボーが一斉に生えてくるアニメーションが作成できました。
という点でも画期的!
※PCGでもStatic Mesh以外もスポーン可能???
→「Spawn Actor」で可能でした!!!


以上、何の役にも立たない読み物記事でした^^;

(紹介) タイプ音で入力内容を予測する機能

私のアイデアを書いてるブログに、キーボードのタイプ音で入力内容を予測する機能のアイデアを発表しておいたが、どなたかがついに実装されたらしいので、こちらのブログでも紹介しておくこととする。