タグ付けされた質問 「mesh」

多くのソースから、3DメッシュにTジャンクションを持つことは、レンダリング中にクラックが発生する可能性があるため、悪いアイデアだと聞いています。誰かがそれが起こる理由と、それを避けるためにできることを説明できますか？

19 mesh 

メッシュがあり、各三角形の周囲の領域で、主な曲率方向の推定値を計算します。私は以前にこのようなことをしたことがなく、ウィキペディアはあまり役に立たない。この見積もりを計算するのに役立つ簡単なアルゴリズムを説明したり、指摘したりできますか？ すべての頂点の位置と法線を知っていると仮定します。

19 mesh 

映画学校では、3Dモデリングのクラスで、映画のモデルを作成するときに、4つのエッジのあるポリゴンのトポロジを維持するように言われました。エッジ/頂点が4つより多い、または少ないポリゴンは不良と見なされ、回避する必要があります。一方、同じモデルがゲームで使用されている場合は、三角測量されます。 私は3Dモデリングを専攻していませんが、問題はまだ私の頭の中にあります。ゲームで3エッジポリゴンが使用されるのはなぜですか？レンダリングは速くなりますか？それでは、なぜそれがフィルムのレンダリングに使用されないのでしょうか？

13 3d  mesh  triangulation 

呼び出し元コードからの入力に基づいて3D形状を生成するクラスがあります。入力は、長さ、深さ、弧などです。私のコードはジオメトリを完全に生成しますが、表面の法線を計算するときに問題が発生します。点灯すると、計算中の不正確な表面法線により、私の形状に非常に奇妙な色/テクスチャがあります。私のすべての研究から、数学は正しいと信じています。私の技術や方法に何か問題があるようです。 高レベルでは、生成された形状の表面法線をプログラムでどのように計算しますか？私は自分のコードにiOSでSwift / SceneKitを使用していますが、一般的な答えは結構です。 形状を表す2つの配列があります。1つは、形状を構成する頂点を表す3Dポイントの配列です。もう1つの配列は、頂点を三角形にマッピングする最初の配列のインデックスのリストです。そのデータを取得して、形状の照明を支援する表面法線のセットである3番目の配列を生成する必要があります。（SCNGeometrySourceSemanticNormalSceneKitを参照） 頂点とインデックスのリストは、クラスへの入力に応じて常に異なるため、サーフェス法線を事前に計算したりハードコードしたりすることはできません。

12 lighting  geometry  mesh 

3Dスタジオ（モディファイヤ/スムーザー）でスムージングされたメッシュが、そのプロセスの前後に同じ量の頂点/面を持ち、まったく同じジオメトリになる理由を理解しようとしています。 次の例では、両方のメッシュに32個の頂点と60個の面があります。 私はプログラミング（c ++およびc＃）での作業経験がありますが、コンピューターグラフィックスの初心者です。したがって、私の予想では、スムージングされたメッシュのスムージングされた外観には、より詳細な最終メッシュを作成するために、追加の頂点、つまり三角形のサブディビジョンが必要になるということでした。しかし、そうではないようです。 したがって、私は尋ねます： 1）メッシュジオメトリの詳細を増やすことなく、どのようにスムージングが可能ですか？ 2）スムージングは​​、元のメッシュと比較して、新しいメッシュを格納するために割り当て/使用されるメモリを少なくとも増やしますか？ 説明は大歓迎ですが、参考文献（学術的かどうかにかかわらず）も高く評価されています。

11 3d  geometry  mesh  memory  model 

私はKinectフェイスAPIを使用しています。これは、フェイスイメージを作成するためにレンダリングされる三角形の頂点とインデックスの配列を提供します。 頂点の数と配列内の順序、およびkinectによって与えられるインデックスは常に一定です。 ただし、APIはUVデータと頂点法線に関する情報を提供しません。 アプリケーションでは、顔の動きによって3D空間での位置が変化するため、Kinectによって指定された頂点の順序を維持する必要があるため、3D編集ソフトウェアでUVと法線を生成することはできません。 同じ平面に頂点が非常に少ないため、頂点の位置を2D平面に投影することでUVを生成できました。 ただし、メッシュの頂点法線を生成する方法はわかりません。頂点法線がないと、面メッシュは視点からのフィーチャの深さなしで描画されますが、頂点の位置は正しいため、シルエットは表示されます。 頂点法線が存在しないため、ライティングが正しく機能しないため、現在のように見た目には機能のない淡いメッシュであることを理解しています。 では、頂点の位置と頂点のインデックスだけで三角形を作成する場合に、頂点法線を生成するにはどうすればよいですか？

11 mesh  shading  normal-mapping 

Mayaプラグイン（この質問はMayaから独立しています）を実装して、3Dボロノイパターンを作成したいと思います。 私はポイントサンプリングから始めなければならないことを知っています（このペーパーで説明する適応ポアソンサンプリングアルゴリズムを実装しました）。 これらの点から、ボロノイを適用してメッシュの3Dワイヤーを作成する必要があると思いました（（Python）scipy.spatial.Voronoiを使用しようとしましたが、期待した結果とは異なっていました）。 何か不足していますか？そのようなパターンを作成するために実装する必要がある適切なパイプラインとアルゴリズムを誰かが提案できますか？ [編集]以下は、このようにscipy.spatial.Voronoiから取得した結果を処理する例です（ここで提案されているように）： vor = Voronoi(points) for vpair in vor.ridge_vertices: for i in range(len(vpair) - 1): if all(x >= 0 for x in vpair): v0 = vor.vertices[vpair[i]] v1 = vor.vertices[vpair[i+1]] create_line(v0.tolist(), v1.tolist()) 灰色の頂点はサンプリングされた点です（元の形状は単純な球でした）： これはより複雑な形状（腕）です

10 3d  geometry  mesh  polygon 

(V1, V2, V3)通常の三角形メッシュでランダムに選択された 3つの頂点があります。これらの3つの頂点について、それらの間の測地線距離と（ダイクストラを使用して）パスを計算し、上の図のように三角形のような表面を形成しました。 これで、各パスにある頂点があり、特定の頂点から測地線距離を計算できます。 私がしたいことは、三角形のような領域にある頂点または三角形を取得することです。これどうやってするの？

10 mesh  triangulation 

私は、CPUからOpenGLコンピューティングシェーダーへのマーチングキューブの実装の移植にほとんど成功しましたが、私はまだ法線に取り組んでおらず、そのための最善の方法を考えていません。 私の実装では特にバイナリ値フィールドを扱います（まだ距離推定器を持たない3Dフラクタル関数をモデル化しようとしているため）、勾配法と前方差分法は機能しません。動作する頂点を共有しました。私のCPU実装では、ここで説明するQuilezの方法を使用して、隣接する各頂点に面法線を蓄積します。 この実装を別のシェーダーに移植することもできますが、これで発生する問題は、必要なアトミックの膨大な数です。私たちはスカラー整数型でのみアトミックを使用でき、3つの符号付き整数を合計可能な方法で1にパックする方法を考えることができないので、シェーダー呼び出しごとに3軸* 3頂点= 9アトミック追加を意味します。もちろん、それらはメモリ全体に分散されるため、1つのアトミックカウンターを9回ヒットするようなものではありませんが、それでもまだかなりのようです。 もう1つの方法は、ポリゴンごとのシェーダー呼び出しを実行して面の法線リストを作成し（おそらくこの方法でx10y10z10にパックすることができます）、次に頂点ごとのシェーダーで隣接する面の法線をすべて蓄積します。ただし、これは膨大なメモリを消費しますが、最悪の場合に対処するには、面インデックスのストレージスペースに頂点ごとに12 intが必要になります。また、特定の頂点に既に書き込まれている面の数を計算するためにアトミックに頼らずに、このストレージに書き込む方法の問題もあります。 誰でもこれを行う方法についてもっと良いアイデアがありますか？

9 opengl  gpu  mesh  compute-shader 

カーブ（つまり、ソリッドのエッジ）に属する一連の3Dポイント（ソリッドボディのテッセレーションを実行するライブラリから復元）があります。つまり、カーブはこれらの各ポイントを確実に通過します。 それにもかかわらず、ポイントセットは順序付けされていないため、この曲線を正しく描画できるようにポイントセットを並べ替える必要があります。 これらのタイプの問題に対する既知のアプローチはありますか？ 追加情報： 曲線は一般にパラメトリックです（スプライン/ベジェ、円スライスなど）。 ポイントは浮動小数点座標として与えられます。 ポイントは非常に密に詰め込まれています（ただし、それらは私が望むほど密にできます）。アイデアを与えるために、xで19単位、xで10単位、zで5単位を占める曲線の場合、曲線のセグメントの一連の点を引用します：（20.7622、25.8676、0）（20.6573、25.856、 0）（20.5529、25.8444、0）（20.4489、25.8329、0）（20.3454、25.8213、0）

9 geometry  mesh  curve 

私は学士号プロジェクトのGPUの等値面アルゴリズムを調査しています（具体的には、実数値のフィールドではなく、バイナリの入出力ボクセルデータのみに集中しています）。したがって、OpenFrameworksで古き良きマーチングキューブのCPU実装があり、それをGLSLコンピューティングシェーダーに移植しようとしている段階で、潜入する前に落とし穴を考慮しています。vertシェーダーとfragシェーダーのみを記述しました以前はそれは私にとってすべて新しいものです。 私の最初の問題は、ワークグループ内の数十または数百のスレッドにわたってルックアップテーブルを効率的に使用する方法です。GPUにはさまざまなタスク用にさまざまな種類のメモリがあることを理解していますが、それぞれがどのように動作するか、どのタイプを使用するかは完全にはわかりません。 Paul Bourkeの古典的なcopypastaテーブルは256 * 16配列なので、スカラーバイトタイプを使用する場合、これはおそらく4kbテクスチャまたはSSBOにパックできます。 問題は、異なるスレッドが互いにつまずくのを防ぐ方法ですか？各ワークグループの多くのキューブは、同じ構成を持つ可能性があるため、バッファ内の同じ場所に同時にアクセスしようとします。これに対処するための回避策または最適化はありますか？

9 opengl  algorithm  gpgpu  mesh 

メッシュ表現の場合、Winged Edgeデータ構造よりもHalf Edgeを使用する利点は何ですか？ 両方のメッシュ表現を理解していますが、唯一の違いは、ハーフエッジが方向性エッジを使用し、翼状エッジが無方向性エッジを使用することです。これまでのところ、指向性エッジを使用することの有用性を考えることはできませんが、メモリ使用量が増えるだけです。

9 mesh  polygon  data-structure  scene-graph