3Dについて話し合うトピック　※最初に#1を必ず読もう※

KimiruHamiru

「内心円」という言葉をScratchのフォーラムで何度か目にして気になっていたのですが、
手元の辞書にも出ていないし、Webで検索しても信頼できるサイトでの記述は見つかりません。

内接円？
常に面の塗りつぶしの文脈で使わている？

oligami

KimiruHamiru wrote:
「内心円」という言葉をScratchのフォーラムで何度か目にして気になっていたのですが、
手元の辞書にも出ていないし、Webで検索しても信頼できるサイトでの記述は見つかりません。

内接円？
常に面の塗りつぶしの文脈で使わている？

内心円とは、心理学で使われる概念で、心理の構成要素を可視化するためのグラフの一種です。内心円は上下2つの星型でからなり、内側の点が性格の特性で、外側の点が行動表現方法に対応しています。内側の点を中心に、16の特徴を08つの特性に分けた状態で表されます。例えば、活動性の高いという性格を持ち、诚実さを重視して行動しているとします。このような性格や行動の構成要素を内心円で表現すると、8点に分割された星型になり、上半分が性格、下半分が行動の構成要素を表します。

冗談はさておき、内接円の間違いか、内心の円だと思われます。まぁ三角形の塗りつぶしでは内接円は塗らないで座標だけ使うのですが。

#160
検索してみた結果、何がどうわからないのか言ってください

Last edited by oligami (Feb. 15, 2023 09:30:49)

KimiruHamiru

tabinototyu wrote:
法線ってなんですか?

「ホウセン」と読む、数学用語です。

そっち方面では確実に通じる単語なので詳しくはぐぐるとして、おおざっぱに言えば「線とか面とかにたいして、直角に交わる線」です。
「面が向いている方向」と考えられるので、

３ＤＣＧでは

「立体の面のうち、向こう側を向いている面は見えないから、手前に向いている面だけ画面に表示すればいい、という判断基準」
「太陽の光がこの面にはこの角度で当たるから、目に届く光の量はこの程度なので画面表示色はこんな明るさ、という計算」
ちょっと変則的ですが、
「頂点に法線を定義したら、頂点の間を補間したら曲面も表現できる」

みたいな場面(こんなの https://scratch-mit-edu.ezproxyberklee.flo.org/projects/767585447/ )で、便利に使います。

buhiton

miiby5591 wrote:
※必ず、はじめに読もう※
（ry

3D以外の作品についての質問は質問コーナー5を利用してください。

現在は、質問コーナー6ですよ。リンクを変えてください。

Last edited by buhiton (Feb. 15, 2023 11:23:09)

hirayuu1414

素朴な疑問です。
3Dで面を描画するとき、明るさはどのように決めていますか。

hemihemi

hirayuu1414 wrote:
素朴な疑問です。
3Dで面を描画するとき、明るさはどのように決めていますか。

光が当たる向きをベクトルで決めておいて、面の法線ベクトルとの内積…とか使えそうですかね。
やったことないので詳しくはわからないですが

Last edited by hemihemi (April 1, 2023 01:11:16)

KimiruHamiru

hirayuu1414 wrote:
素朴な疑問です。
3Dで面を描画するとき、明るさはどのように決めていますか。

光源の位置(x,y,z)と向き(x,y,z)
面(あるいは頂点)の法線ベクトル(x,y,z)
視点の位置(x,y,z)
辺りの数値から……みたいな計算の仕方

の話ではなく、別な切り口で、

「光源(太陽光とか電球とか)の明るさの数値をどう決めているか」
ということであれば、私の場合は「実際に表示してみて、見た目がかっこよくなるような数字にしている」です。
https://scratch-mit-edu.ezproxyberklee.flo.org/projects/738375829/
なんかは光源の明るさを選べるようになっていて、０にすると真っ暗になります。
画面を見ながらいろいろ試して「0.72ぐらいがかっこいいと感じた」ので、デフォルト値をそうしています。

「面をどんな明るさで描画すればいいか」という話であれば、
究極的には「好きなように決めればいい」というのが答えになるかと思います。

全ての面を同じ色で塗りつぶせば用が済む場合もあるし(立体構造を見せるためのプロジェクト https://scratch-mit-edu.ezproxyberklee.flo.org/projects/738375829/ )
白、灰色、黒（あかるい、ちゅうぐらい、くらい）の３段階がアニメ塗りっぽくて最高にかっこいいという判断ももあるし
素材の表面の性質をリアルに再現するのがいいという場合もあるし
素材の内部の性質をリアルに再現すると半透明の材質の時に超絶かっこいいという場合もあるし

曲面がグラデーションになるのがいいという場合もあるし
ポリゴンのさかい目がくっきりしているのがいいという場合もあるし

です。
「リアル」方面に進むと計算時間が長くなってくるのでアニメーションとかは不可能になったりもします(表面の反射とかシビアに計算すると、こういうレベルで時間がかかる https://scratch-mit-edu.ezproxyberklee.flo.org/projects/425020125/ )が、
どう決めているかといえば「好きなように決めている」です。

hirayuu1414

お二方とも、ありがとうございます。
今作ってる作品の解決の糸口が見つかった気がします。

pupon

(多分)初めてこのトピックに投稿するのですが、三角形の一部の点だけ(1個、2個)が自分よりも後ろにある場合ってどう描画すればいいのですか?
(直線の場合はわかります)

追記
すみません、自己解決しました

Last edited by pupon (May 4, 2023 08:35:03)

KimiruHamiru

pupon wrote:
(多分)三角形の一部の点だけ(1個、2個)が自分よりも後ろにある場合ってどう描画すればいいのですか?

・頂点が一つでも画面外とか後ろの時は、そもそも三角形を描画しない
・問題が起きにくいように３Ｄモデル（シーン）の方を調整する（端的には、「大きい」三角形を使わない、近づきすぎない）

のが大正解（それで必要充分で、きっちりやってもメリットが少ない）

と個人的には思ってるのですが、

その上で、
きっちりやる場合どうするか、現実の場面では実際どうやってるか、については

Youtubeの「三葉レイのCG技術チャンネル」の
【ラスタライズ】ソフトウェアラスタライザをつくってみた
https://www.youtube.com/watch?v=gQx4PyKpQh0
の「クリッピング(18:09-30:22)」のあたり

が、手がかりになるかも、と思います。
「クリップ」というのはＣＧの用語で「画面の四角（計算上は立方体）に合わせて切り取る」みたいな意味です。

動画中の、
「奥行きじゃなく上下左右の辺と接触した場合の、多角形化、三角形化、という処理手順(24:01-25:24)」
「「壁の三角形」が画面端とか奥行きの境界に触れた時にうまいことゆがむ様子(28:40-30:22)」
辺りの映像は、
どういう処理をするかイメージする助けになるかなと思います。
私は内容についてあまり理解していませんが、動画の音声を消して眺めても参考になるかも、と思います。

pupon

#170
ありがとうございます。ですが、自分で解決できたので大丈夫です。
それとは別で質問なのですが、
それぞれの三角形で、一番手前にある頂点のz座標でソートするようにプログラムを組んでいるのですが、奥にあるはずの三角形が手前に描画されることがあります。(三角形が交差していたり、重なっていたりしていません)
「一番手前にある頂点のz座標」の代わりに何を使えばいいのですか。

Last edited by pupon (May 4, 2023 09:51:46)

KimiruHamiru

pupon wrote:
それぞれの三角形で、一番手前にある頂点のz座標でソートするようにプログラムを組んでいるのですが、奥にあるはずの三角形が手前に描画されることがあります。(三角形が交差していたり、重なっていたりしていません)
「一番手前にある頂点のz座標」の代わりに何を使えばいいのですか。

「重なっていない」のであれば奥も手前も描画順序に関係ないのでは？と思います。
「重なっている、とは何か」というのがポイントのような気もします。

ステージ上に描画される２つの三角形が部分的なり完全に重なってるとして、
恐らく求めてる回答（２つの三角形の、この情報をこう加工すれば、２つの三角形がどう重なって見えるか解決できる、といった計算方法）は、私は持ってないです。
（あらゆる状況に対応できる方法は、理論上でも、そもそも存在しない、３つの三角形が互いに隠しあうようなケースもあるから、三角形を順番に一つずつ描いて行く方法自体に理論上の限界がある、と思っています）

確実なのは「全ピクセルについて、全三角形までの距離を記録して、各ピクセルについて一番近い三角形だけ１ピクセルずつ描く」
で、いまどき実用されてるリアルタイムCGは、この方法でやってるはずです（ただ、通常はGPUというかAPIが最初から持っている機能(depth buffer)を使うので、このやり方のコードをわざわざ一から書いたり読んだりする機会はすごく少ないかなと思います）。

このやり方でやってる例は、Scratchではこれぐらい
https://scratch-mit-edu.ezproxyberklee.flo.org/projects/739705560/
しか知りません。レイトレーシングも同じ考え方（私の理解では計算順序の違い＝全ピクセルの奥行きを計算して全部記録してから描画するか、ピクセルごとに全三角形までの距離を計算しては描画するか、の違い）と言えると思うので、そっち方面から調べるのも良いかなと思います。

pupon

#172
なるほど…そもそも描画順を並べ替えるという方法では限界があるのですね…
今の技術では

KimiruHamiru wrote:
「全ピクセルについて、全三角形までの距離を記録して、各ピクセルについて一番近い三角形だけ１ピクセルずつ描く」

ができる気がしないので諦めます…

KimiruHamiru

pupon wrote:
#172
なるほど…そもそも描画順を並べ替えるという方法では限界があるのですね…
今の技術では
KimiruHamiru wrote:
「全ピクセルについて、全三角形までの距離を記録して、各ピクセルについて一番近い三角形だけ１ピクセルずつ描く」
ができる気がしないので諦めます…

最初に書きましたが、
「問題が起きにくいように３Ｄモデル（シーン）の方を調整する（端的には、「大きい」三角形を使わない、近づきすぎない）」
というのが正解（求めている解決方法）と思います。

pupon

3Dモデルの方を調整するのが難しいんですよね…(「3Dエンジン」として作っているので)

KimiruHamiru

pupon wrote:
3Dモデルの方を調整するのが難しいんですよね…(「3Dエンジン」として作っているので)

3Dモデルについては、“importer”とか“loader”とか呼ばれるのを用意するのも、一つの方法かもですね。
3Dエンジン的にも。

Blenderに標準でついてるモデル(立方体とか猿頭(Suzanne))を使えるようになったりすると強いです。
Scratchで「OBJ Importer/OBJ Loader」とか呼ばれているやつは、テキストファイルに書かれている
v 0 0 0
みたいな座標データを、リストに
0
0
0
と書き込む、といったものなので、
リストと３Ｄプロジェクトに慣れてきたなら、それ自体は自力で作るのも現実的になってきてるかも……と思ったりもします。

oligami

#176

KimiruHamiru wrote:
pupon wrote:
3Dモデルの方を調整するのが難しいんですよね…(「3Dエンジン」として作っているので)
3Dモデルについては、“importer”とか“loader”とか呼ばれるのを用意するのも、一つの方法かもですね。
3Dエンジン的にも。

Blenderに標準でついてるモデル(立方体とか猿頭(Suzanne))を使えるようになったりすると強いです。
Scratchで「OBJ Importer/OBJ Loader」とか呼ばれているやつは、テキストファイルに書かれている
v 0 0 0
みたいな座標データを、リストに
0
0
0
と書き込む、といったものなので、
リストと３Ｄプロジェクトに慣れてきたなら、それ自体は自力で作るのも現実的になってきてるかも……と思ったりもします。

そうですね。
私も昔、仕様を見ながら一から途中まで作ったやつがあったりします
https://scratch-mit-edu.ezproxyberklee.flo.org/projects/719665030/
今共有してきましたが、
https://scratch-mit-edu.ezproxyberklee.flo.org/projects/679427268/
こういうものが既にいっぱいある時点であれですね…。ちょっと魔境だなって思いました。

TigerCub2023

3dのゲームを作ろうとしてscratchWIKIの３ｄの頂点計算をもとに3dエンジンをつくっているのですが、バグが多いです。画面の後ろを書かないようにすると回転させたときに形が変な風になってしまいます。そうならないためのいい方法はありませんか？

TigerCub2023

自分が作っている3dエンジンはこれです。載せていなかったので載せました。
　　　　https://scratch-mit-edu.ezproxyberklee.flo.org/projects/866566171　

KimiruHamiru

TigerCub2023 wrote:
3dのゲームを作ろうとしてscratchWIKIの３ｄの頂点計算をもとに3dエンジンをつくっているのですが、バグが多いです。画面の後ろを書かないようにすると回転させたときに形が変な風になってしまいます。そうならないためのいい方法はありませんか？

TigerCub2023 wrote:
自分が作っている3dエンジンはこれです。載せていなかったので載せました。
　　　　https://scratch-mit-edu.ezproxyberklee.flo.org/projects/866566171　

細かいコードや目標は理解できていませんが、

「後ろを書かないようにすると回転させたときに形が変な風に」
という件については、直接には、

「後ろを書かないようにする判定（リスト「z座標」を使う）」の部分
が、
リスト「z座標」の更新の実行前に行われている

のが原因のように見えます。

現状のコードから改造するのであれば、

動きブロックやペンブロックを一切使わずに
「x座標,y座標,z座標」の各リストの更新をまず全部実行する（＝四角い壁の画面上での表示位置となる４頂点のデータを全部そろえる）

ということをしてから、

その「リストに書きこまれた値」を使って、
判定したり、動きブロックやペンブロックを使って、線や塗りつぶしの描画をする

といった形にするのが、わかりやすいかなと思います。

Discuss Scratch