2026
2025
2024
2023
2022
2021
2020
2019
2018
2017
2016
2015
2014
2013
2006年10月の記事
全31件 (31件中 1-31件目)
1
-
Real-Time Collision Detection 12.2.1 Computing a Vertex-to-Face Table
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/12.2.1 Computing a Vertex-to-Face Table頂点から面への変換表を計算する。ある頂点からその一部となっている面を見つけるために逆変換の表を用意します。頂点は大量の三角形の一部であるかもしれないので各頂点に関連している三角形をリンクリストで動的に管理する方法が提案されています。本文ではソースコード例で三角形のリストを頂点に持たせる方法が示されています。このあたりは事前計算で準備しておくといろいろ便利そうですね。
2006年10月31日
コメント(0)
-
Real-Time Collision Detection 12.2 Computing Adjacency Information
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/12.2 Computing Adjacency Information接続情報の計算。モデルのクリーンアップを効果的に行うために繋がっている面、辺、頂点の接続について記述されている情報が重要になります。一般的な幾何形状の記述としては三角形の表に対するインデックスで面の表を表現する形式ですがあまり効率が良くありません。すべての接続情報を保持できるのが理想ですが記憶容量の観点から効果的ではありません。そこでいくつかのデータ構造主に多様体ソリッドモデル(manifold solid model)について部分的な接続情報を保持することが提案されています。ウイングエッジ(winged-edge)やハーフエッジ(half-edge) やウイングトライアングル(winged-triangle)、四辺形エッジ(quad-edge)などがこのようなデータ構造となります。
2006年10月30日
コメント(0)
-
Real-Time Collision Detection 12.1 Vertex Welding
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/12.1 Vertex Welding頂点の結合。衝突用幾何形状がポリゴンから構築される際には接続されているべきポリゴンの頂点がうまく接続されていない場合は割れ目が生じて問題が生じます。隣接している頂点のペアを見つけて1つの頂点にまとめる作業を頂点の結合(vertex welding,vertex shifting, vertex merging)と言います。頂点がお互いに隣接していると考えられる範囲を結合許容範囲(welding tolerance)あるいは結合イプシロン(welding epsilon)と呼びます。また、ある頂点の結合許容範囲の空間をその頂点の結合隣接(welding neighborhood)と呼びます。ある頂点が結合距離の範囲内に見つかった場合は以下のような選択肢が考えられます。1.現在の頂点を以前の保持されている頂点で置き換える。2.以前の保持している頂点を現在の頂点で置き換える3.両方の頂点を半分の距離にある頂点で置き換える。これらの中で最初のものは頂点ドリフト(vertex drift)(頂点の元の位置と最終的な位置との間の距離)を結合イプシロンの範囲に収めることができます。選択肢２は結合した頂点の数に比例して最悪のケースになります。これは選択肢３も同様です。次に解決すべき問題として結合範囲内にある頂点をどのようにして見つけるかですが空間分割を行う方法やハッシュを用いる方法がここでは紹介されています。ハッシュを用いた例が本文にソースコードつきで説明されています。また、洗練されていない手法になりますが成分の絶対値の和でソートする手法もあるようです。
2006年10月29日
コメント(0)
-
Real-Time Collision Detection 12 Geometrical Robustness
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/12 Geometrical Robustness幾何学的頑健性。判定する幾何形状も適切になっている必要があります。問題なのは以下のようなケースです。・冗長な頂点、辺、面。・凹面、自己交差のある面、面積がゼロに近い縮退した面。・間違った方向を向いている片側だけの面(single-sided faces)・隣接する面の間にある穴やすき間・平面上にない面これらの形状をクリーンアップするために以下の例をこれから試していきます。・頂点の結合。・隣接している面の間にある割れ目の修正。・同一平面上にある面の結合。・（三角形分割を含む）凸切片への分解。
2006年10月28日
コメント(1)
-
Real-Time Collision Detection 11.7 Summary
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.7 Summaryまとめ。浮動少数点のエラーについて学びました。頑健な計算を行う方法についても学びました。・許容誤差を用いる手法・計算の共有を確実に行う・太ったオブジェクトで安全にエラーを避ける方法などを学びました。また、エラー境界を管理するために間隔演算について学びました。また正確演算についても学びました。
2006年10月27日
コメント(0)
-
Real-Time Collision Detection 11.6 Further Suggestions for Improving Robustness
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.6 Further Suggestions for Improving Robustness頑健性向上のためのさらなる提案。・アルゴリズムを総当たり的にテスト。結果が一致しない場合に原因を調査。・防御的プログラミング(defensive programming)を利用。assert も浮動少数点演算なことの注意。・特殊なケースに対応。たとえば縮退しているケースなど。・IEEE-754 のすべての丸めモードでテスト。・同じ値を計算するのにいくつかの異なる形式を使うのを避ける。・浮動少数点演算を原点中心に行うことでビットが無駄になることを避ける。
2006年10月26日
コメント(0)
-
Real-Time Collision Detection 11.5.3 Segment Intersection using Integer Arithmetic
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.5.3 Segment Intersection using Integer Arithmetic整数演算を用いた線分の交差。線分 S(t) = A + t(B-A),0＜t＜1, 平面 P(n・X)=d との交差を考えます。ここでは S が点オブジェクト O の位置 A から位置 B まで t によって与えられる時間間隔における線形な運動をしていると仮定します。平面との交差点を求めます。そしてこの式を調整します。ここまでの流れを本文ではソースコードこみで解説しています。m個の平面の表側にある Q を決定するために整数線形計画問題(integer linear programming problems)という手法を使います。
2006年10月25日
コメント(0)
-
Real-Time Collision Detection 11.5.2 On Integer Division
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.5.2 On Integer Division整数による除算。除算は結果をゼロに向けて丸めてしまいます。正確に計算するためには除算を取り除く必要があります。このため両辺に分母をかけるようにします。 a / b > c / d は ad - bc > 0 と等しくなります。これは行列式の符号の計算と等価になります。この符号を拡張精度を用いて明示的に計算する別の方法は連分数展開(continued fraction expansion)を用いて計算する方法です。この手法が本文にソースコードつきで示されています。
2006年10月24日
コメント(0)
-
Real-Time Collision Detection 11.5.1 Exact Arithmetic using Integers
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.5.1 Exact Arithmetic using Integers整数を用いた正確な演算。オーバーフローを避ければ加算、減算、乗算の整数計算は正確です。(除算は別に扱う必要があります)浮動少数点と異なり結合法則が成り立ちます。オーバーフローを避けるために加算および減算の場合は２つのnビットの演算結果は n+1 ビットの精度を必要とします。乗算の場合は 2n ビットの数になります。またオーバーフローを明示的に検出する方法もあります。演算をより大きな整数の型にキャストしてより低い制度による結果と比較すればオーバーフローがおきたかどうか判定することができます。（場合によっては単精度や倍精度の少数点を整数演算のオーバーフローの判定に利用することができます。）ただ型がすでにサポートされているネイティブな整数型のうち最大のものの場合はうまくいきません。符号のない c = a + b のオーバーフローは bool overflow = ( a > ~b ) としたり overflow = ( c < a ) とすることで判定できます。符号つきの場合は符号に応じて INT_MAX あるいは INT_MIN に対して比較することによって行います。あるいは加算の後で a, b が同じ符号を持ち加算の結果がそれとは異なる符号になっているかどうかを判別することによっても可能です。同様に減算や乗算の際にも考慮する必要があります。拡張精度の演算を用意するのも良いと思います。本文では 64 ビットの加算乗算のコード例が示されています。
2006年10月23日
コメント(0)
-
Real-Time Collision Detection 11.5 Exact and Semi-Exact Computation
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.5 Exact and Semi-Exact Computation正確な計算および準正確な計算。浮動少数点数は便利ですが丸め誤差を避けるのが大変です。そこで代替案として正確な演算(exact arithmetic) により処理を行います。任意の精度で演算するのが理想ですが一部の計算はブール式あるいは述語の判定を行うことで判定することができます。ORIENT2D(),ORIENT3D(),INCIRCLE2D(),INSPHERE() といった判別式を利用します。これらの式は複雑さが固定されているので必要なビット数の上限を設定することができます。これらは計算幾何学の分野でよく研究されています。
2006年10月22日
コメント(0)
-
Real-Time Collision Detection 11.4.2 Interval Arithmetic in Collision Detection
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.4.2 Interval Arithmetic in Collision Detection衝突判定における区間演算。陰関数で表されている曲面SとAABBの交差を検知する問題などは区間演算で解くことができます。曲面の関数をAABBの区間で関数を表現し二乗の項を最適化することで解くことができます。
2006年10月21日
コメント(0)
-
Real-Time Collision Dete 11.4 Interval Arithmetic
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.4 Interval Arithmetic区間演算。これは区間解析ともよばれ許容誤差を範囲[a,b]のとり得る値(a＜x＜bとなる任意のx)として記述し計算の中にそれ自体を取り込みます。区間演算は本質的に数式の真の値が計算された境界内にあることを数学的に証明することと同じです。11.4.1 Interval Arithmetic Examples区間演算の例。ここでは区間演算の例が示されています。本文で挙げられている例では計算結果の区間は真の式の範囲より大きなものになっています。複雑に囲まれている式ではエラーが爆発することで区間がすぐに役に立たなくなってしまいます。この問題は変数が式に現れるたびに新しい変数として前に出てきた式とは独立して扱われるからです。これは依存問題(dependency problem)として知られています。多くの場合は式から依存性を取り除くように式を整理することで依存問題を避けることができます。また入力空間を小さな部分区間に分割しすべての部分区間の和集合を得ることによって最終的な結果を得ることもできます。区間を部分区間に分割させる考え方は区間ニュートン法(interval Newton method)でも利用されています。
2006年10月20日
コメント(0)
-
Real-Time Collision Detection 11.3.4 Robustness of Fat Objects
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.3.4 Robustness of Fat Objects太ったオブジェクトの頑健性。先に示した通り直線および線分の交差を含む判定は浮動少数点の問題の影響を受けやすいので線分を半径だけ太らせてカプセルや円柱として扱うのが良さそうです。これらは一般的にやせた方の計算よりもコストがかかりますが頑健性ははるかに向上します。
2006年10月19日
コメント(0)
-
Real-Time Collision Detection 11.3.3 Robustness through Sharing of Calculations
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.3.3 Robustness through Sharing of Calculations計算の共有化による頑健性。ここでは直線と三角形の交差を検知する方法で計算の共有化を行わない場合に頑健性の問題が発生する例が示されています。通常は三角形のサポート平面を計算し主平面(principal plane)上に射影することのよって実行されます。これをそのまま浮動少数点演算で行うとうまくいきません。この理由として情報の欠落や連続して行われる関連している判定での情報を共有していないからです。スカラ3重積で判定する方法もありますがゼロ近辺では符号が変わることもあります。しかし両方の三角形に同じ式を適用するので結果は同じになることが保証されます。インデックスを持っている頂点の場合は辺のインデックスを順番ととらえることで辺を共有することも可能です。
2006年10月18日
コメント(0)
-
Real-Time Collision Detection 11.3.2 Robustness through Thick Planes
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.3.2 Robustness through Thick Planes熱い平面における頑健性。浮動少数点の問題を示すために本文では線分の交差の問題を扱っています。ここでは機械表現可能な格子点にスナップされることでワールド境界の外に出てしまったり線分の上にこなくなる問題について議論しています。解決法としてはこれまでのように許容誤差を用いて平面に厚みを持たせる方法が紹介されています。
2006年10月17日
コメント(0)
-
Real-Time Collision Detection 11.3.1 Tolerances Comparisons for Floating-Point Values
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.3.1 Tolerances Comparisons for Floating-Point Values浮動少数点に対する許容誤差の比較。浮動少数点を用いて計算を行う際に注意すべき重要な事実は浮動少数点を直接比較することはほぼ間違いだということです。たとえば if ( x == 0.0f ) のような判定は失敗することが多いのです。許容誤差を用いて if ( abs(x)
2006年10月16日
コメント(0)
-
Real-Time Collision Detection 11.3 Robust Floating-Point Usage
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.3 Robust Floating-Point Usage頑健な浮動少数点の利用。いくつかの欠点はありますが衝突判定のようなリアルタイムアプリケーションに対して浮動少数点演算は数値を表現するための手段としては最も便利です。注意を払うべきところとして許容誤差(tolerance)という値を考えます。また計算式の中の共通の部分を一貫して適切に共有することです。
2006年10月15日
コメント(0)
-
Real-Time Collision Detection 11.2.3 Floating-Point Error Sources
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.2.3 Floating-Point Error Sources浮動少数点エラーの要因。浮動少数点は非常によく定義されてはいるもの、その性質上不正確です。要因としてはある数が何らかの数字を基底にして正確に表現できないことにあります。2進法の浮動少数点表現では0.1は循環少数となってしまいます。したがってたいていの環境で 0.1f * 10.0f は 10.0f より大きくなります。 x / 2.0f を x * 0.5f によって置き換えることはできますが(2.0 と 0.5 はどちらも正確に表現可能です) x / 10.0f を x * 1.0f によって置き換えることはできません。切り捨てによる誤差が存在する場合は浮動少数点演算は結合則が成立しません。コンパイラは浮動少数点の定数を左側からのみ左結合の演算しの方へ結合することができます。コーディング規則として浮動少数点の定数は変数の左側に置くようにします。全体として浮動少数点演算には細心の注意を払わなければなりません。多くの場合は式を書き直すことで桁落ちのエラーを防ぐことが可能です。
2006年10月14日
コメント(0)
-
Real-Time Collision Detection 11.2.2 Infinity Arithmetic
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.2.2 Infinity Arithmetic無限演算。負の無限大、正の無限大、非数(NaN)と呼ばれる準数値(quasi-numbers)があります。これらの拡張領域のおける演算は無限演算と呼ばれます。+INF,-INFは非常に大きい数を非常に小さい数で割ったりしてオーバーフローあるいは表現できる限界によって発生します。NaNを含む比較演算はNaNに大小がないのですべて偽と判定されます。数値演算に対してはどこかにNaNが含まれていれば結果もNaNになります。したがって値の範囲を調べる際など注意する必要があります。交差判定のコードなど注意する必要があります。INFおよびNaNの例外はスティッキー(sticky)ビットをフラグと用いることでサポートされています。しかしあらゆる環境でサポートされているわけではありませんのでまず正しい挙動を確認する必要があるでしょう。
2006年10月13日
コメント(0)
-
Real-Time Collision Detection 11.2.1 The IEEE-754 Floating-Point Formats
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.2.1 The IEEE-754 Floating-Point FormatsIEEE-754浮動少数点形式。2進数の浮動少数点形式である単精度および倍精度の仕様があります。単精度は32ビット精度です。指数部は+127のバイアスを加えることで負の指数を格納することができます。倍精度は64ビット形式で指数のバイアスは1024になります。数直線上における表現可能な数値をみるとゼロ近辺にすき間があるのでIEEE標準は非正規化(denormalized)あるいは部分正規化(subnormal)されている数値を定めています。また正の無限大、負の無限大、非数(+INF,-INF,NaN)も定義しています。符号つきの0と0は等しくなります。(-0=+0)標準規格は不動少数点演算はすべてのビットに関して正しい結果を生成しなければならず機械表現可能な場合には現在設定されている丸め規則に基づいて実数を囲んでいる2つの機械表現可能な数字のどちらかに正しく丸められなければなりません。丸めのためにガードビットとスティキービットがあります。2つのガードビットは精度の余分なビットとして働きスティッキービットはガードビットだけでは十分でない場合に正しく結果が丸められたかどうかを決定する手助けとなります。丸めモードとしては・最も近い数に丸める(等距離の場合は偶数に丸める)・負の無限大の方向に丸める。・正の無限大の方向に丸める。ゼロの方向に向かって丸める丸めによって生じる問題は機械イプシロンとして知られている値と結びついています。
2006年10月12日
コメント(0)
-
Real-Time Collision Detection 11.2 Representing Real Numbers
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.2 Representing Real Numbers実数の表記方法。コンピュータで正確に表現することが可能な実数は機械表現可能な数字(machine representation numbers)あるいは単に機械数(machine numbers)と呼ばれます。実数の表記について議論する際には精度と正確さについて考えることが大切です。精度は桁がいくつかあるかで正確さはその桁数がいくつ正しいかに影響があります。また固定少数演算と浮動少数点数の表現方法があり、固定少数点は精度と表現できる範囲に制約があり浮動少数点は少数点の位置が変動します。ある意味10進数ではなく2進数の表現となります。
2006年10月11日
コメント(0)
-
Real-Time Collision Detection 11.1 Robustness Problem Types
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11.1 Robustness Problem Types頑健性の問題の種類。不正確な精度(precision inaccuracies)が問題になるケースと縮退(degeneracies)が原因になるものの2種類があります。縮退は問題にしているアルゴリズムでうまく扱えない特別な値や状態を指しています。まず最初に注意するべきなのは不動少数点演算によって実行される計算は丸め等の誤差の影響を受けてしまいます。縮退してしまう状況はいつでも起こり設計に原因があります。ここでは数値的な不安定さが生じる原因についてまとめます。1.変換と表記法の誤り。2進数では完全に表現できない少数の場合。2.オーバーフローおよびアンダーフローのエラー。掛け算や割り算での桁あふれ。3.丸め誤差。乗算を繰り返すと精度が落ちる。4.桁落ちのよるエラー。ほぼ等しい値での減算や小さい数と大きい数での加算など。5.入力のエラー。入力データそのものがまずい。縮退に対応するためにはアルゴリズムを修正する必要があります。
2006年10月10日
コメント(0)
-
Real-Time Collision Detection 11 Numerical Robustness
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/11 Numerical Robustness数値的頑健性。これは数値計算や幾何学的配置に対処する能力のことをさして用いています。頑健なアルゴリズムは数値的なエラーによってクラッシュしたりすることもないというわけです。とりわけ衝突判定のプログラムは頑健性について慎重になる必要があります。ソリッドなオブジェクトは単純にお互いに通り抜けたり地面に落下してしまっては困るからです。
2006年10月09日
コメント(0)
-
Real-Time Collision Detection 10.5 Summary
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10.5 Summaryまとめ。この章ではGPUを用いて交差判定を行いました。たいていCPU側へのリードバックが遅くなりますのでオクリュージョンクエリを用いたり双一次フィルタリングを用いてダウンサンプリングを繰り返しバッファサイズを減らす方法などが示されました。また画像空間に基づいた重なりの判定は凸あるいは凹の両方のオブジェクトに対して示され正確さの上で問題が生じることも説明されました。最後にオブジェクトの集合を刈り取るフィルタリングの手法も示されました。
2006年10月08日
コメント(0)
-
Real-Time Collision Detection 10.4 GPU-Based Collision Filtering
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10.4 GPU-Based Collision FilteringGPUに基づいた衝突フィルタリング。10.2の判定方法を発展させることで衝突フィルタリングのアルゴリズムとなります。1番目のオブジェクトをレンダリングした後の深度バッファの値よりも2番目のオブジェクトの方が前方にある場合は2番目のオブジェクトは完全に可視(fully visible)と言い交差していないと判断されます。与えられたオブジェクト集合に対して衝突フィルタリングを適用するためには、その集合の1つ1つのオブジェクトが他のオブジェクトに対して完全に可視であるかどうかを調べる判定を何回も繰り返して行います。停止する際に衝突の可能性のある集合(Potentially Colliding Set=PCS)の中に衝突の可能性のあるオブジェクトを全て含めるようにします。本文ではここまでの話を図と具体例で示しています。
2006年10月07日
コメント(0)
-
Real-Time Collision Detection 10.3 Testing Concave Objects
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10.3 Testing Concave Objects凹オブジェクトの判定。2つのオブジェクトA,B（凹でも凸でもよい）があり多面体ならば衝突時に片方のオブジェクトのある一片がもう片方のオブジェクトの内側にあります。つまりある方向(たとえば視点)から発射された光線はどちらかのオブジェクトの境界を奇数回だけ通過します。これをステンシルバッファを用いて表現すると以下のようになります。0.カラーバッファ書き込み無効。デプス、ステンシルバッファのクリア。1.デプス更新有効にして辺のみレンダリング。2.デプスより近いもののみステンシルに表側のみオブジェクトAを描きステンシルバッファを増やす。オブジェクトBの裏側のみレンダリングしてステンシルバッファを減らす。オブジェクトAとBが衝突していればステンシルに何かが残るのでこれをオクリュージョンクエリで検知します。本文ではここまでの例が OpenGL のコードで示されていて参考になります。ステンシルシャドウボリュームやCSGのレンダリングでも似たような感じになるでしょうか。
2006年10月06日
コメント(0)
-
Real-Time Collision Detection 10.2 Testing Convex Objects
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10.2 Testing Convex Objects凸オブジェクトの判定。GPUを用いた凸オブジェクトの衝突判定としては各レンダーバッファのピクセルをビュー平面に垂直な光線と見なして判定する方法があります。最初のパスでオブジェクトAをデプステストに LESS_EQUAL 指定でデプスバッファを埋めその後デプステストを GREATER_THAN に変更してオブジェクトBをオクリュージョンクエリを有効にしてレンダリングします。もしオクリュージョンクエリでオブジェクトBのピクセルが見えないならBはAの前面に完全に出ていることになります。そして2パス目は逆転して裏側の面を判定するという流れになります。本文では OpenGL のコード例が挙げられています。ただし、この例では凹オブジェクトに正確に対応できないので次節で凹オブジェクトの扱いに関して触れています。
2006年10月05日
コメント(0)
-
Real-Time Collision Detection 10.1.2 Occlusion Queries
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10.1.2 Occlusion Queriesオクルージョンクエリ。GPUのリードバックを防ぐためオクリュージョンクエリを使用するアルゴリズムに変更します。このクエリは現在のアクティブなテストを通過しているプリミティブのテストを通過している三角形のピクセル数を数えることができます。典型的な使い方としてはレンダリングの最初の方でシーンの大部分を覆い隠しているオブジェクトをレンダリングするのに適用することが挙げられます。それらをレンダリングした後に、細かいオブジェクトに対して単純なレンダリングを行います。こうすることで描画を最適化することができます。OpenGL 1.5 ではオクリュージョンクエリはコア機能になります。それ以前のバージョンでは HP_occlusion_test あるいは NV_occlision_query というベンダー固有拡張でサポートされています。
2006年10月04日
コメント(0)
-
Real-Time Collision Detection 10.1.1 Buffer Readbacks
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10.1.1 Buffer Readbacksバッファのリードバック。画像バッファからメインメモリへリードバックして衝突判定に利用する手法がいくつか提案されています。残念ながら glRedBuffer() や glReadPixels() を用いる手法は非常に低速です。GPUからデータを得るのにヒストグラムのクエリを用いる方法がいくつか提案されています。OpenGL の EXT_histgram を用いたものがあります。残念ながら利用可能であったとしてもヒストグラムの拡張がバッファのリードバックよりも高速でないことが多いです。またリードバックを減らす1つの方法として転送領域を4分の1の大きさにダウンサンプリングする方法もあります。こうすることでリードバックにかかる時間を減らすこともできます。
2006年10月03日
コメント(0)
-
Real-Time Collision Detection 10.1 Interfacing with the GPU
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10.1 Interfacing with the GPUGPUとのインターフェイス。GPUを計算装置として使う場合には元々の設計上解決しなければいけない問題があります。まずデータ構造として頂点のストリームあるいはテクスチャを用いたパケットである必要があります。またより大きな問題としてGPU上で計算した結果をメインのメモリへと動かすことです。このリードバック(readback)のため並列化が行き詰まるか失われます。多くの場合はオクルージョンクエリ(occlusion query)を用いることでリードバックを防ぐ手法をとることができます。またバッファのリードバックが必要な場合においてもリードバックのデーターの量を制限するように注意深く設計することもできます。
2006年10月02日
コメント(0)
-
Real-Time Collision Detection 10 GPU-Assisted Collision Detection
Real-Time Collision Detection という本を読んでいます。http://www.realtimecollisiondetection.net/10 GPU-Assisted Collision DetectionGPUによる衝突判定。衝突判定に関しては主に2つのGPUの利用法があり高速な画像空間に基づいた(image-spacebased)交差判定のテクニック、もしくは補助プロセッサにより数学的あるいは図形的な計算を高速化する方法があります。画像空間に基づいた手法は実装が容易でベジェ曲線や曲面などでもラスタデータに変換できるものならなんでも動作します。ただ、レンダリングするバッファの解像度次第では計算精度不足で不正確な値になることもあります。テクスチャにデータを配置することで一般的な目的の計算をGPU上のピクセルシェーダーで実行することも可能です。
2006年10月01日
コメント(0)
全31件 (31件中 1-31件目)
1
-
-
- どんな写真を撮ってるの??（*^-^*）
- ではこれはタイタンビカス？モミジア…
- (2026-07-29 05:30:04)
-
-
-
- 機動戦士ガンダム
- 『機動戦士ガンダム』RX-78ー２ ガ…
- (2026-07-22 20:36:15)
-
-
-
- 戦闘機の写真を撮るのが好き！
- ブルーインパルス
- (2026-07-29 06:30:05)
-
