LRIKI

### flex だけ、はやめよう ui-layout-2 ブランチで yoga を使った flex レイアウトをデフォルトにしてみたが、どうにも flex レイアウトはゲームでは使いづらい。 画面の上下左右にスナップしたコンテナをまずルート要素近くに用意し、flex はその中で使うことが多いだろう。(それでもほとんど StackPanel で足りるが) grid layout は欲しい。この grid も、WPF のような高さを指定できるものと Flutter のような列数だけ指定してあとは Flow にするもの、など欲しい。 ### Style vs 派生クラス そうするとやっぱり...

動機 ---------- ### なぜこれまで左手座標系だったのか？ キャラクターあるいはカメラを起点とした処理を考えやすいため。 特にピクセルシェーダで ViewSpace 上の計算を行うときに Z+ が "進行方向" と一致するためイメージしやすかった。 ClipSpace に至っては OpenGL でも DirectX でも左手座標系であり、低レイヤーに近づくほど左手座標系の方が扱いやすい。 また Lumino の開発初期にリサーチできたゲームエンジンでは、左手座標系が採用されているものが多かった。（Unity, UE4 も左手） これまではレンダリングエンジンの実装に力を入れていたため左手座標系の方が都合がよかったのだが、より高レベルの機能をサポートし始めたことで次のような問題が出てきた。 ### 左手座標系の問題点 様々な DCC ツールで作成したアセットとの相性が悪いこと。 特に3Dモデルは頂点データの他、ボーンやアニメーション等非常に多くのデータ構造を扱う必要がある。...

そもそも FileSystem が必要なのか？ ---------- Lumino の FileSystem の目的の半分は、アプリ開発でよく使用するユーティリティの提供。 エンコーディング指定のテキストファイル読み書きや、パターンマッチは std::filesystem には無いユーティリティである。 単純なファイルのコピーや削除であれば std::filesystem と機能的な差は無い。 ただし、短いパスの場合は Path 用の SSO が効くので、ln::String, ln::Path と併用する場合、全体的には std::filesystem より高速に動作する。 動機 ---------- Lumino の多くの API は発生しうるエラーをロジックエラー（ユーザーではなくプログラマが悪い）と考え、assertion または例外(選択可能)...

Lumino はメインループを内部に持つスタンドアロンのアプリケーションフレームワークのほか、別の GUI フレームワークにレンダリングライブラリとして組み込む機能も持っている。 しかし最近は対応する言語や環境が増えてきたことで、暫定的に用意したグルーコードがかなり複雑になってきている。 エントリーポイントのシンプルさはそのままサンプルコードのとっつきやすさにつながってくるため、仕様を整理する。 ### 基本方針 - ユーザーが使うクラスを増やしすぎない。 - スタンドアロンのアプリケーションフレームワークでサンプルを示すとき、コードが最小限になること。（驚き最小） - 別のフレームワークに組み込む時は、そちらの文化にできるだけ似た書き方ができるようにする。 - ゲームアプリケーションを実装する用に、 Application クラスをオーバーライドできるようにする。 - GUI アプリケーションを実装する用に、 Application クラス及び MainWindow クラスをオーバーライドできるようにする。 ### 破壊的変更 これまで `ln::Engine::initalize()` で...

動機 ---------- 現状は StaticLib としての配布のみであるが、サイズが非常に大きくなっている。 対策として DLL 配布できないか検討したい。 技術的課題 ---------- ### シンボルのエクスポート 外部に公開するクラスや関数を __declspec(dllexport) 等で修飾する必要がある。 コンパイラの差を吸収するため `LN_API` マクロが定義されているので、これを使う。 ### ビルド時とリンク時で同じバージョンのコンパイラが必要 これは StaticLib と同じ運用となる。 ### STL の制約 エクスポートするクラスは、ベースクラスやメンバ変数に STL のクラスを持ってはならない。 自分でコンテナクラスを作成したとき、そのクラスが...

`しない。` 以下、検討結果。 動機 ---------- Lumino は次の2つのエントリーポイントの作成方法がある。 - Application クラスを継承して実装する - Main() に while 等を使ってメインループを実装する Application の実装では仮想関数などの知識が必要となるため、メインループと比べてやや前提知識のレベルが上がる。 簡単なサンプルではメインループを使って実装した方がわかりやすいのでは？ 特に C と HSP3 へ対応するにあたって、継承といった概念の無い言語向けに作るサンプルが少し難しくならないか心配。 対案 ---------- ### なぜ Application クラスを使うのか？ メインループの隠蔽が必要なケースに対応するため。 Web...

[2021/1/6] やっぱり現状維持にしてみる ---------- Builder パターンの導入を始めたので、そっちで対応してみる。C++ から使うときはほとんどこのケースで足りる。 ``` auto button = UIButton::Builder() .onClicked(handler) .build(); ``` 新しめの UI フレームワークは Builder パターンないしそれに近い、副作用の少ない方法で UI要素を構築するケースが多い。これで十分な感じ。 connectXX は主に Binding を作るとき、「これはイベントハンドラの登録関数です」を強調するのに使うことにしてみる。 イベント名は過去形？ ---------- ネイティブに近いフレームワークは過去形が多い傾向。 ただ過去形に統一しすぎると MouseDowned とかなじみ無い名前になる。...

- [x] #164 書き方の整理 - [ ] 自動生成 Motivation ---------- Instancing 有効、NormalMap 有効、など、構成の組み合わせがかなり増えてきているので、自動的に作りたい。 開発中のタイトル HC4 では背景モデルに対してシェーダを適用したいが、対象は NormalMap 有無など複数の構成を書かなければならず、シェーダ開発が非効率になっている。 Proposal ---------- 現状の構成は次の通り。 PS の出力方法 (Phase) - Default - ShadowCaster -> PS...

Proposal ---------- ### Instantiate WorldObject を作るときは次のようにできるようにする。 ```cpp auto model = MeshModel::load(u"model.gltf"); auto obj1 = StaticMesh::create(model); auto obj2 = SkinnedMesh::create(model); ``` 現行↓ ```cpp auto model1 = StaticMeshModel::load(u"model.gltf"); auto model2 = SkinnedMeshModel::load(u"model.gltf");...

Proposal ---------- 法線マップテクスチャは Material に設定して使う。 ```cpp material->setNormalMap(Texture2D::load(u"normal.png")); ``` 接線ベクトルは標準頂点データとして追加する。 ```diff struct Vertex { Vector3 position; Vector3 normal; Vector2 uv; Color color; + Vector4 tangent; }; ``` `VertexTangents` は削除。 シェーダについては、法線マップ処理の有無をスイッチできるようにする。 ```diff...