#360

KimiruHamiru wrote:

・「-100,0,0」みたいなデータを、どうやって用意するか(＝モデリング)の情報
・データの持ち方の情報(定義ブロックの引数に数字を書いていくのではなく、リストに全部突っ込んでおくとか、その場で計算で作るとか)

が欠落していること

恐らくそれは、チュートリアル通りに使っているだけ -> チュートリアルを作れるようになる
と言った感じになるための、地味に大きめな壁ですかね。
いっぱい数学の公式を覚えていても、基礎がなってないと、公式以外の手法で解けない人（大学数学とかの高度なものになると置いてかれるやつ）みたいな感じ？。なんか違う気が…。

高校数学当たりまで理解していれば、原理をある程度理解できるので、それで3Dオブジェクトは空間図形である事が分かります。
これで簡単なものならモデリングできます。

リスト関係については、簡単なものはプログラミングをかじっていれば、少し複雑なものは、自分で考えてもいいですし、obj, mtlなどを参考にするのもありです。


ただ、空間図形関係は、脳の空間把握関係部分の発達具合などにもよるので、全然わからない人でも、ある時突然わかるようになったりします。なので、チェックを込めてまずは数学の勉強からですかねぇ。やはり基礎は大事です
応用とは、基礎があってこそです。ChatGPTに頼ってても一定以上の物は作れないのと同じです


私はCG関係の本をいくつか持っていますが、scratchでよく使われる形式と同じ理論系統で分かりやすい本は、行列や空間図形は基礎知識として、「3次元CGの基礎と応用」という本ですかね。ただ、その実装方法であるモデリング情報やらデータ形式などは、この本に載ってないですね

長々話してますけど、こういうミッシングリンクになっている基礎知識は、今ならChatGPTに聞けばどんな基礎知識が足りないか教えてくれると思います

僕の作った（チュートリアルを見て）3Dの立方体があるのですけど、中に入ると壊れます。どうしたら良いですか？
壊れ方としては、中に入ると、前後をつなぐ線が横に真っ直ぐになってしまうんですよ。
これですね↓
https://scratch.mit.edu/projects/1208999723/

UT0315 wrote:

僕の作った（チュートリアルを見て）3Dの立方体があるのですけど、中に入ると壊れます。どうしたら良いですか？
壊れ方としては、中に入ると、前後をつなぐ線が横に真っ直ぐになってしまうんですよ。
これですね↓
https://scratch.mit.edu/projects/1208999723/

2025/08/28時点の「【3Dengine】ver.0.5」
https://scratch.mit.edu/projects/1208999723/
に関しては、
「ニアクリッピングプレーン( near clipping plane )」の値を
「0」ではなく、正の値(1でも0.1でも)にする
と正常に（すごくきれいに）動いているように見えます。

余談気味ですが：
「クリップが発生した時に色を変える」とかやってみると、多分デバッグしやすいです。私はそうしてデバッグしました。

「参考にしたチュートリアルが何か」を書いておくと、対応しやすい人が多いかなと思います。
コードの感じからするとたぶん、
Yukku氏の「Yukkkuの3DEngineチュートリアル」
https://scratch.mit.edu/projects/470897319/
ですよね。

もう一つ余談なんですが、

2025/08/28時点の「【3Dengine】ver.0.5」
https://scratch.mit.edu/projects/1208999723/
に関しては、（指摘の部分以外すごく安定して動いているので）

変数「ニアクリッピングプレーン」を
「画面にスライダ表示して100以上にして、ｗキーで前進して突っ込んでみる」

とかやってみると、

「Zクリッピング」が「何をやっているか」
「辺が、ニアクリップ平面を貫通する位置にある場合に、辺の「平面より近くの部分」を切り捨てて、線が途中で途切れる

という様子が、きれいに観察できるので、楽しいかもと思います。

0というのは人間の目で言えば黒目（黒く見える、瞳の穴）に画面が張り付いてるような状態と考えられるので、
遠近法の「近いと大きく見える」の仕組みが「距離０だとXYは無限に大きくなる」ということになってるのかなと思います。

あともう一つ質問です！3Dオブジェクトの後ろを映らないようにしたいのですがその辺りのプログラムはどうしたら作れますか？

UT0315 wrote:

あともう一つ質問です！3Dオブジェクトの後ろを映らないようにしたいのですがその辺りのプログラムはどうしたら作れますか？

「3Dオブジェクト」をワイヤフレーム（辺のあつまり。針金細工のようにみえる描画方法）として扱って書いている場合、
短い答えはたぶん
「できない。ワイヤフレームという描画方法は、そういうものだから、理論上でもできない」
ということになるかなと思います。
前提として「面を塗りつぶす必要がある（最低でも“どこにに面がある”という情報が必要）」と言っていいかなと思います。

ちょっと緩い表現ですが
四角い折り紙を二枚机に置く場合、奥の紙が手前の紙に隠れるのは、紙に「面がある」から
なので、
四角く折り曲げた針金を２つ机に置く場合、手前の四角針金の「面の部分」が奥の四角形を隠すことはない
といった意味の話です。

１）三角形（多角形）の面を塗りつぶす話
をクリアしたうえで、
２）立体図形の各三角形の、どっちが“手前”かを考える話
について考えて
３）どれが手前かわかったら、奥から順番に描いて行けばいい
といった手順が必要になるかと思います。
細かい話や変則的な話もありますが、それも含め、このトピックで何度か出ていて実装例も見つかるはずなので、探してみるとよいかと思います。

「一つの３Ｄオブジェクトの中の、奥にある面を描かない仕組み(culling)の話題」の場合はもう少し話が違ってきますが、
いずれにせよ「三角形の面について考える」の部分はクリアする必要があります。


「“どこにに面がある”という情報」についてちょっと補足すると、

ワイヤフレームの描画を考える時
「頂点の位置」のほかに
「どの頂点とどの頂点のの間に辺があるか/ないか」の情報
が必要
となるのは、当然といえば当然です（既に実装されてると思うので、知っていると思いますが）。
その部分で手抜きしてコードを書くと、こんな「ななめの線」
https://scratch.mit.edu/projects/712019656/
が出てきます。この場合、「頂点の位置はあってるけど辺のつなぎの情報がない（余計なのも全部ある）」です。

面の場合も同様で、面を扱うには、
「頂点の位置」のほかに
「どの頂点とどの頂点のの間に辺があるか/ないか」の情報に加えて
「どの頂点とどの頂点とどの頂点間に面があるか/ないか」の情報が必要、という話です。

3Dの基盤はできたのですが、外面上の物の前後の関係ってどうやったら作れますか？

#367
一般的に「Zソート法」と呼ばれるアルゴリズムですね。
基本的には、描写する図形の重心座標を計算し、見かけの奥行き座標をもとに、奥にあるものから描写していきます。
https://ja.wikipedia.org/wiki/Z%E3%82%AA%E3%83%BC%E3%83%80%E3%83%BC

(この方法では、前後関係がたまに誤って表示されてしまうことがあります。特に、互いに重なり合った形であったり、図形が交差していたりする場合は難しいです)

#367
「前後の関係」という日本語がよくわかっていないのですが、「どっちのほうが前にあるかを比べる」という認識であってますか？

なら、カンタンです。どっちのほうがZ座標が大きいか、を見ればいいのです。
Z座標の比べかたはいくつかあるようです。例えば、#368で言われている「重心で比べる」方法や、1番奥のZ座標で比べる方法などです。
どれも方向は変わりません。どっちのほうがZ座標が大きいか、を見ているだけです。

しかし、3個、10個、あるいは1000個…と、多くの数のモノを比べるとなると、少し大変になってきます。
2個のモノを比べるときには「どっちのZ座標が大きいのか調べる」だけでよかったのが、多くなってくると「Z座標の順に並べる」ということが必要になってくるからです。これは「どっちのZ座標が大きいのか調べる」よりも、ずっとずっと難しいです。


ここからは、いかにして「Z座標の順に並べる」のかを説明します。

「Z座標の順に並べる」ためには、まず、必要なことがあります。それは「モノのZ座標をまとめる」ことです。情報がまとまっていないと、並べるなんてできっこないですからね。そのために多くの人はリストを使います。
ちょっと説明内容がズレていますが、#102あたりの投稿が参考になるかもしれません。

「モノのZ座標をまとめる」ことが終わったら、やっと「Z座標の順に並べる」ことができます。
この「並べる」とは専門用語で「ソート」と呼びます。つまり「Z座標の順にソートする」とも書けるわけです。かっこいいですね。
この「ソート」の方法は、もう研究が進んでいます。カンタンなソートも、めっちゃ早いソートも、天才たちが作ってくれています。ぜひ、参考にしてみてください。
とっつきやすいのは、やはり「バブルソート」です。最初に作ってみるのならコレでしょう。

3Dゲームを作っているのですが、いまこの「ソート」に悩まされています。
配置したいポリゴンが18000個近くあるのでこれ全てをソートしようとしたらとても処理が遅くなっていまいます。
3Dゲームのソートに使う定義ブロックにおいて「画面を再描画しない」にチェックを入れるのがどうしても必須になるのです。
この定義ブロックにバブルソートのように18000回近くの繰り返しの入れ子をすると、処理が重くなるのは当然の話しだと思うのですが、一回の18000回の繰り返しなら処理は比較的早くなるので、繰り返しを一回しか使わないような、天才的なソートの方法があったら教えてほしいです。

#370
(つらつら書きましたが、結局は線を引いた部分だけ読むだけでも事足ります。)

ちょっと説明がめんどうになってしまうので、最初にO( )という概念を説明しようと思います。

O( )は「ランダウの記号」とか呼ばれるやつで、中の式をざっくりと表したものです。ソートのあたりでは、計算量を表すのによく使われます。
正確な定義がしっかりとあるんですが、長くなる気がするので自分で調べてください。
ソート元のデータ量(要するに、リストの長さ)をnとして表すことが多いです。なので、ここでもそうします。
O( )の中身にはO(n)とか、O(n log n)とか、O(2ⁿ)とかが入ったりします。
(ちなみに、ランダウの)

バブルソートの平均計算量はO(n²)です。つまり、1万の長さのリストをソートするには、平均で1万×1万、つまりだいたい1億回計算する必要があるわけです…。そりゃ、重くなりますね。実際、このソートが使われることはほとんどありません。

@ramen575さんが求めてるソートの平均計算量はO(n)です。こんなソートは…いまだ見つかってません。見つかってくれれば、プログラミング界隈から大感謝されることでしょう。

でも、O(n²)よりかははるかに速いソートが存在します。「クイックソート」「マージソート」「ヒープソート」などです。これらの平均計算量はO(n log n)です。関数グラフを書いてくれるサイトとかに突っ込めば、劇的に軽くなることがわかるでしょう。

つまり、「クイックソート」「マージソート」「ヒープソート」とかがとても優秀で速いということです

「じゃあ、どれを使えばいいんじゃあ！！」そう思うかもしれませんが、それは自分で考えてみてください。考えるポイントは「計算量(最悪の場合、平均、最良の場合)」「空間計算量」「実装の難しさ」です。
ちなみに、「空間計算量」とは、計算にリストをどの程度使うか、です。

(余談です。計算量がO(n)のソートはいまだない、と書きましたが、実はウソです。ただし、3Dを作るには使えなさそうなソートだったり、ふざけたソートだったりします。なので、省略しました。)

色々教えてくれてありがとうございました。
正確でなくてもポリゴン同士の重なりがなんとなく正しく見えたらそれで良かったので、なんとかうまくいきました。

あともう一つ聞きたいことがあるのですが、3Dで点や線を描画するのはなんとなく方法はイメージできますが、面がどう描画してるのか分かりません。
見た感じ三角形の中に内心を書いて三角形の外枠を隙間なく塗りつぶしてるように見えるのですが、具体的にどう計算しているのかが分かりません。

#373
私の昔の投稿で書いた記憶があります。それを見てみると、なにかわかるかもしれません。わかりにくいと思いますが…。
わかりやすく書いてみたプログラムもあります。参考になるかもしれません。

3D作りてーペンで

pen down作りてー
pen up