Summary

• #2 にて、作品の再生処理とオブジェクトの表示位置の変更処理を実装した
• 本Issueでは、表示した3Dオブジェクトをユーザーが操作できるように機能拡張する。具体的には…
  • ホームページと編集ページのUIの整理
  • Effectの編集（新規追加や設定値の変更）
  • Modelの編集（色やサイズの変更）

Acceptance Criteria

Reference

Summary

Acceptance Criteria

• 録画機能を作成する
• コーディングUIを見直す
• アニメーションを増やす

Proposed Method

• method 1
• method 2

Reference

• reference1
• reference2
• reference3

Summary

• プロジェクトの大まかな基本構成を作成する。
  • 本Issueの目標はブラウザ上で3Dオブジェクトを表示できるようにすること。3Dオブジェクトを表示するのみでOKで、それ以上の実装（オブジェクトをユーザー操作できるようにする 等）はIssue #2 で対応予定。

Acceptance Criteria

略

Reference

ICS簡単なThree.jsのサンプルを試そう

Summary

大規模な改修になる。UIの不具合については後日対応として進める。

Acceptance Criteria

• UIからの入力をTHREE.js用の実行データへ変更できること
• 実行データをもとにレンダリングを実行できること
• 既存のUI操作を移植すること（UXふくめて見直しは別Issueで対応）

Proposed Method

Reference

Summary

作品の定義情報をJSON出力し保存できるようにする。

現実装では、作品データ内には以下が含まれている。

• ユーザーによる定義情報
• Mesh

Meshのデータ容量は少なくないため、これも含めてJSON出力する仕様は避けたい。
ということで、作品データからMeshを切り分ける。
※ また、現仕様は管理対象オブジェクト数の増加に伴いDOMレンダーが急激に重くなるという問題を抱えている。これは、ReactのState更新対象にMeshが含まれていることが原因。切り分けることでこの問題も副次的に解消するはず。

改修内容は以下

• GeneModelがMeshを保持しないように変更。Meshをリストなりで集約管理するように修正
  → 特定のMeshに対して処理を掛ける際は、IDで走査をかける処理が必要になる（そこまで重くならないと思うけども…まじめにやるのであればオーダーを要計算）

Acceptance Criteria

• criteria 1
• criteria 2
• criteria 3

Proposed Method

• method 1
• method 2

Reference

• reference1
• reference2
• reference3

Summary

現時点では確認されていない事象であるが、JavaScriptが非同期処理で実行される言語である以上は発生が予想される。

現仕様とその問題点

前提として…本pjにおけるアニメーションというのは、一定のルールでmeshのプロパティを再計算する…という意味。

現仕様のアニメーションは、最新のmeshのプロパティ（の位置やサイズなど）を参照し、アニメーション適用後の状態を計算し更新するという実装。しかし、後続アニメーションの計算処理を実行する際に、先行アニメーションの計算が完了していないケースも考えられる。

対策案

• 各アニメーションの計算結果をリレーしていくようにする。更新を複数かけないため無駄な処理も減るはず。

Acceptance Criteria

• criteria 1
• criteria 2
• criteria 3

Proposed Method

• method 1
• method 2

Reference

• reference1
• reference2
• reference3

Summary

• GeneModelStorage内のデータをユーザーによる定義情報と現在描画されているデータに分離
• アニメーションの実行ロジックを変更（ #11 ）
• 初めから再生機能（定義情報からMeshを生成するように各所を修正）を作成
  → JSONでの作品情報保存が副次的に可能になる

Acceptance Criteria

• criteria 1
• criteria 2
• criteria 3

Proposed Method

• method 1
• method 2

Reference

• reference1
• reference2
• reference3

Summary

現状は以下の流れで再生用データを生成している。

UI入力をまとめたオブジェクト（Source） → 再生用データ（Object）

これを以下に変更する。

UI入力をまとめたオブジェクト（Source） → 作品定義のJSON
作品定義のJSON → 再生用データ（Object）

※ 作品定義のJSONは、UI入力をまとめたオブジェクト（Source）から生成することも可能であり、そのほかユーザーがテキストエディタ等で生成したもの使用する方式でもよい。要するに結合度を下げられるので、JSONの出どころは不問になる。

## Acceptance Criteria
- [ ] criteria 1
- [ ] criteria 2
- [ ] criteria 3


## Proposed Method
- method 1
- method 2


## Reference
- reference1
- reference2
- reference3

Summary

Acceptance Criteria

• criteria 1
• criteria 2
• criteria 3

Proposed Method

• method 1
• method 2

Reference

• reference1
• reference2
• reference3

Summary

• #1 にて、プロジェクトの基本構成の作成および3Dオブジェクトの表示は実装済み
• 本Issueでは、表示した3Dオブジェクトをユーザーが操作できるように機能拡張する。具体的には…
  • node-redのようなビジュアルプログラミング形式のUI → 工数がかかるため差し当たりCLIチックなUI を作成
  • プログラミング画面で3Dオブジェクトの回転スピード再生スタート時の表示位置を編集できるようにする（3Dオブジェクトの追加やサイズ変更、移動などのアニメーションは別Issueの範囲とする。UI開発までが本Issueでの主眼）

Acceptance Criteria

Reference

Summary

作品の再生管理をはじめとするコア機能を1モジュールに集約する。
以降このモジュールをGAE Engineと呼び、フロントアプリと切り分けて開発を進める。

GAEEngine具体的には以下を担う。

• JSONからの作品データ生成
• レンダリングライブラリへの適用
• 作品の再生管理

Acceptance Criteria

• criteria 1
• criteria 2
• criteria 3

Proposed Method

• method 1
• method 2

Reference

• reference1
• reference2
• reference3

UIで値を編集した瞬間に即時setState （& meshに反映？）すると以下のエラーとともにTHREE.jsが落ちる 調べてみたところ、メモリリークを防ぐためにブラウザ側でcontextを削除していると判明。

three.cjs:19610 WARNING: Too many active WebGL contexts. Oldest context will be lost.

ReactのState内でThreeオブジェクトを保持する設計がまずいかも知れない。（一元管理したかったが…）
現象確認～原因特定まで要対応。

暫定対応として、UIからフォーカスが外れた（onBlurイベント発生）際にのみsetStateすることで回避。
表向きには「ジェネラティブアート特有の、脳内でイメージした動きとの違いや、ランダム性を楽しんでほしいのでワンテンポ遅らせる仕様とした」…ということでどうでしょう。。。