長い間考えていたので、パーソナライズとライブ壁紙で旅を始めることにしました。 この分野は、たとえばゲームと比較してかなり制限されているが、同時に、作者がユーザーに何らかのアイデアを示す機会を残すことに同意する。 まず第一に、私はプログラミングの観点から面白いことをしたかったのです。まあ、あまり一般的ではありませんでした。
次のことが判明しました。
実装について少し
シミュレーション、レンダリング、およびインターフェイスの一部はC ++で記述されています。
シミュレーションは、粒子ベースの粘弾性流体シミュレーションで説明されている粒子システムとダイナミクスに基づいています。 アルゴリズムはわずかに単純化され、2次元の場合に実装されます。 システム全体が粒子とその環境との相互作用に基づいて構築されているという事実に基づいて、最も重要な部分はこの環境の検索メカニズムです。 この検索についてさらに詳しく考えてみましょう。
そのため、入り口には、何らかの方法で空間に分散された粒子の配列があります。 私たちの目標は、各粒子が特定の固定距離Rにあるすべての隣接粒子を選別することです。
完全な列挙を避けるために、スペースを同じサイズのセルに分割します。 これにより、すべてのパーティクル間ではなく、隣接するセルに属するパーティクル間のみで、潜在的な近傍を検索できます。 セルサイズは、距離Rの倍数として選択されます。
次に、 Counting sortを使用して、配列をセルで並べ替えます 。 速度に加えて、ソートをカウントすると、必要な部分合計のセットが得られます（各セルについて、以前のセルにあるパーティクルの数がわかります）。
ここで、すべての潜在的な近傍を並べ替えるために、配列内の必要な間隔（数はセルサイズの最初の選択に依存します）を順番に読み取る必要があります。 必要な要素へのオフセットは、ソートプロセス中に取得された部分的な合計に基づいて簡単に計算されます。 この例では、これらは半間隔です：[0、3）、[4、9）、[11、14）、距離Rに一致するセルサイズ。
ソート後、上記の記事のダイナミクスに従って、すべてのパーティクルの位置が更新されます。 更新されたデータがレンダリング用に送信されます。 シミュレーションに参加するパーティクルの数に関しては、それらの数はほとんどなく、最高レベルの品質では1000のみです。
レンダリング
OpenGL ES 2.0に基づいています。 9パス（青色の2方向の垂直/水平）で構成されます。
- スプライトを持つ個別のテクスチャ（画面解像度よりもサイズが小さく、サイズは品質設定によって決定されます）で、すべての粒子を描画します。
結果
- 高確率のぼかし：
結果
- （強度に基づいて）不要な部分を切り取り、表面を形成します。
結果
- 小さい係数でぼかします。
- 小さい係数でぼかします。 1つのパスで、アーティファクトなしで目的の効果を達成することはできませんでした。
結果
- 最後のパスでは、背景とともに表面を描画します。 また、法線は強度に基づいて計算されます。
- 屈折：
結果
- 内側と外側の影：
結果
- ミキシング：
結果
- 照明：
結果
- 屈折：
インターフェース
ネイティブインターフェイスの存在は、必要性によって決まりました。 実際には、ライブ壁紙は2つのモードで表示できます
- ホームまたは/およびロック画面。
- プレビュー
最初のモードではすべて問題ありませんが、プレビューモードでは、アクティビティは非標準的な方法で動作します。 このモードでは、オーバーラップすると、ライブ壁紙の更新と描画のサイクルが停止します。 そして、何をブロックするかは問題ではありません（この動作の合理的な説明が見つかりませんでした）。 その結果、半透明のアンドロイドダイアログを使用してセットアップしても、目的の双方向性を維持できません。
コメントとフィードバックをお待ちしております。 ありがとうございます！