TigerCub2023 wrote:

頂点計算をもとにした3dエンジンを作っているのですが、色のデータがうまく行きません。

起動直後の状態から

[ピッチ v]を(-4)にする

とかで確実に再現する

ようなのでしばらく観察してみたのですが、

四角形を描くにあたって、
三角形２つを塗りつぶしたあと、
四角形のフチドリをstrokeする部分、

コードで言えば

ペンの太さを(2)にする
＜略＞
ペンを上げる

の辺り

を削除すると色の異常は起きなくなるようです。
現状、何が起こっているか特定できてない(あと塗りつぶしのロジックをちゃんと読めてない)のですが、
直観的には「塗りつぶしの手順の問題(ソートなどはうまく行っている)」のように思えました。

補足。
「ちゃんと読めてない」ので想像も混ざるのですが、現行のロジックは

四角形を描く
もし「中を塗るくらい面積がある」なら
　色指定
　四角の中を塗りつぶす
四角のりんかくを２ピクセルの線で描く

という手順になっているために、「一つの四角形がせまい（小さい、細い）場合」に、
「色指定をしないで線を描く」ということが起きているのかなと思いました。

これを

四角形を描く
色指定
もし「中を塗るくらい面積がある」なら
　四角の塗りつぶす
四角のりんかくを２ピクセルの線で描く //（不要なら何もしない）

などとすれば良さそうな気がします。

このプロジェクトについてなのですが、
obj file を読み込むときに 角度も設定できるようにしたいです。しかし、回転行列の計算順序によって差が生まれてしまうため、x,y,zそれぞれの向きがおかしくなってしまいます（分かりづらいです。ごめんなさい）。どうすれば解決できるでしょう

>> #243
回転軸の取り方と角度の基準をちゃんと定義していますか?
例えばロール・ピッチ・ヨー角による表現があります。
https://www.sky-engin.jp/blog/eulerian-angles/#toc4
https://qiita.com/harmegiddo/items/96004f7c8eafbb8a45d0

Mario-098 wrote:

このプロジェクトについてなのですが、
obj file を読み込むときに 角度も設定できるようにしたいです。しかし、回転行列の計算順序によって差が生まれてしまうため、x,y,zそれぞれの向きがおかしくなってしまいます（分かりづらいです。ごめんなさい）。どうすれば解決できるでしょう

「回転行列の計算順序によって差が生まれてしまう」について、数学的なことは実のところよくわからないのですが、

差し当たって現状のプログラム（スプライト「obj compiler」の定義「compile obj」のコード）だと
objファイル中の「頂点エントリ（「v 1 2 3」みたいな行）」
を、
「１要素ずつ」処理している
のが
問題をむずかしくしているように見えます。

つまり、
１つ(x座標のデータ)処理したら
次のデータ(y座標のデータ)を扱うときには、
直前のデータ(x座標のデータ)を忘れる仕組み
になっている

ために、
「回転操作(z軸回転ならx,yの、最低でも２値を同時に扱う必要がある)」
が、やりにくい、という話に見えます。

「x,y,zを、３つとも、まとめて扱う」かたち
にすれば、話は簡単になる(回転操作については、表示側でやってるのと同等になる)、ように思います。

「３つ同時に取り出す」のは
https://scratch.mit.edu/projects/293583919/
とかでやっているので、参考になるかもと思います。

別な切り口としては、「一通り、リスト「頂点情報」を完成させて、その後」で、
「完成した頂点情報リストから、x,y,zとしてデータを３つずつ取り出して、回転操作をして、同じところに書き戻す」
というのもあり(回転操作については、表示側でやってるのと同等に書ける)と思います。

Mario-098 wrote:

obj file を読み込むときに 角度も設定できるようにしたい

については、元データの由来とかにもよりますが、

Blenderで扱えているなら、
・Blenderの機能で、メッシュデータの方を回転する
・Blenderの機能で、objエクスポートする時にx,y,z軸を入れ替える
というのも、目的によっては、現実的かもしれません。

こんな感じのマインクラフト作ったんですけどシードを乱数にしてるはずなのにわりと既視感がある地形が多く生成されます。なぜでしょうか
Minecraft ver.2.0.0

スプライトを3次元上で回転させるとなると、

 横に() ％伸びる

必要になりそうですかね？
廃止されてしまったのですが代用法はなさそうですね…
どうすればいいですかね…
(どうやらscratchはチューリング完全らしいので、一応代用法はないとおかしいはず)

チューリング完全は計算可能性の話であって、機能の話ではありません。

となると

自分 wrote:

横に()％伸びる

必要

という結論に至りますかね…

joban657 wrote:

 横に() ％伸びる

必要になりそうですかね？
廃止されてしまったのですが代用法はなさそうですね…

過去に実装されていましたっけ？
なお、このブロックの話については提案トピックで実施済みです。

inoking wrote:

joban657 wrote:

 横に() ％伸びる

必要になりそうですかね？
廃止されてしまったのですが代用法はなさそうですね…

過去に実装されていましたっけ？
なお、このブロックの話については提案トピックで実施済みです。

ありましたね。”横に伸びる”がありました。（scratch1.4だったかな…。）

Scratch 1.4にそのようなブロックはありません。なにかがあるという主張をする場合は、検証可能な方法も示すようにお願いします。

joban657 wrote:

スプライトを3次元上で回転させるとなると、

 横に() ％伸びる

必要になりそうですかね？

スプライトを3次元上で回転させるためには
「均一な拡大縮小だけじゃなく、変形させる」のはたしかに必須と思います。
ただ、3D一般には「正方形を長方形にする」ような変形だけじゃなく「台形にする(とかさらに複雑な変形)」も必要になるので、
「横に伸ばす」ような形で表現するよりは「y軸回転する」みたいな形で表現する方が、直接的に扱える気はします。

などといいつつ、

変則的ですが、

その「正方形を長方形にする」ような変形だけで「スプライトを3次元上で回転させる」試み

として、こんなプロジェクト
https://scratch.mit.edu/projects/674042774/
もあります(Switch modeボタンを、1回押すと3D表現、2回押すと「タテヨコにつぶれる」画像)。
「魚眼レンズの効果」で「スプライト全体の端っこがつぶれて見える」のを利用して、３Ｄ表現に使おうと試みています。
限界はありますが場面によっては実用も可能かもしれません。

_PAERIA wrote:

本格的な３ｄの描写を伝授していただきたいです。２ｄで頂点決めるのとかはわかるんですが、その後が。。。

本格的なとは？

_PAERIA wrote:

本格的な３ｄの描写を伝授していただきたいです。２ｄで頂点決めるのとかはわかるんですが、その後が。。。

遠近法やら、移動、回転やら、大規模プロジェクトの作り方やら、いろんな話があるかと思いますが、

私は「点の個数」が「本格っぽさに重要」
と思うので、その側面からちょっと書きます。
私の3Dプロジェクト
https://scratch.mit.edu/studios/5903410/
は、ほぼすべて、こんな感じの構造になっています。

@greenFlagがクリックされたとき
model
<>まで繰り返す
draw
end
定義 model
[モデル v]のすべてを削除する
(1)回繰り返す
[x v]を(0)にする
[y v]を(0)にする
(x)を[モデル v]に追加する
(y)を[モデル v]に追加する
[x v]を(100)にする
[y v]を(0)にする
(x)を[モデル v]に追加する
(y)を[モデル v]に追加する
end
定義 draw
消す
[ptr v]を(0)にする
(2)回繰り返す
[x v]を([モデル v]の((ptr)+(1))番目)にする
[y v]を([モデル v]の((ptr)+(2))番目)にする
点を動かす (x) (y)
x座標を(x)、y座標を(y)にする
スタンプ
[ptr v]を(2)ずつ変える
end
定義 点を動かす(x) (y)
[x v]を((((1)*(x))+((0)*(y)))+(マウスのx座標))にする
[y v]を((((0)*(x))+((1)*(y)))+(マウスのy座標))にする

実際のプロジェクトでは3Dなのでzとか出てくるほか、
モデルの作り方
の辺りは、やり方も複雑さもめちゃくちゃ幅があるので各プロジェクトでいろいろですが、
共通部分として基本にあるのは
・最初に「モデルを決める」。決めた形は、以後変化しない。
・物の位置や向きは変わる。それは計算で決められる。計算は、定義「点を動かす」の部分だけを工夫すればいい。
という考え方です。

肝心の「点を動かす」の部分で、どういう計算で何ができるか、実際どうやってるか、は長くなるのでここでは説明しませんが、
「モデルの各点のすべて」を、「ひとつずつ」、「同じ計算で」動かす。それで何でも表現できる。はずだ
という考え方が一つ大きなポイントで、
点の数を2個から50個とか、3000個とか、30000個に増やしても「点を動かす」の部分は全く複雑にならない
というメリットがあります。

こういう構造のプログラムで典型的なのは
https://scratch.mit.edu/projects/639384394/
辺りかなと思います。

#250

初めてこのディスカッションフォーラムを使うので
少し変になるかもしれません…(返信をどうやればいいかも分からん…)

[横 v] に (0) %伸びる

は現在代用案として、下のようなプロジェクトがあります。
https://scratch.mit.edu/projects/674042774/
このプロジェクトではハッキングコスチュームを使うことで魚眼レンズの効果で形を変えています

#257の最後に書いた
https://scratch.mit.edu/projects/639384394/
についてちょっと補足しておきます。

このプロジェクトの
スプライト「apple」の「リンゴの動き」は、
「３Ｄとは関係がない、ステージ上の回転」です。

定義「pers」の処理は「遠近法」＝「遠くを小さく表示する」ですが、
これさえなければ、このプロジェクトはほぼ２Ｄです。
例えばこれ

定義 pers (x)(y)(z)(w)
[x v]を((x)/(w))にする
[y v]を((y)/(w))にする
[z v]を((z)/(w))にする

を、こうする

定義 pers (x)(y)(z)(w)

と「表示は２Ｄ」になります。

（今回は「遠近法を使わない」ので詳しいことは説明しませんが「zが大きい(遠くにある)ならwが大きくなる＝各座標をwで割ると全体が小さくなる(遠くに見える)」という仕組みです遠近法のヒミツは、「wの値」となる

((1)+((0.3)*((z)/(100)))

という式にあります）
—-
ともあれ、もうこれは２Ｄです。

「z軸回転」と呼んでる処理は、「zは固定してxとyだけ動かす」処理です。つまりは、
「ステージ上の回転＝リンゴの動きをそのまま使う」です。

「x軸移動」の処理は、
「ステージ上の移動＝リンゴの動きのxの位置だけそのまま使う」です。
「y軸移動」の処理は、
「ステージ上の移動＝リンゴの動きのyの位置だけそのまま使う」です。

この形であれば、３Ｄの話は全く出てきません。
変数「z」は確かにそこにあるのですが、
表示で使っている(青い「動き」ブロックで利用している)のはxとyだけです。
何ならScratchエディタで、無造作に変数zを削除しても正しく動くはずです。

で、

ステージのことを「xy平面」と呼ぶとして、
「xy平面」上の「動きを計算で表現できる」なら、
「xz平面」でも「yz平面」でも、「同じ形の計算をすれば同じように動く」はずだ。

つまりは、
２Ｄで動かせるなら、３Ｄ化はもう遠くない
といった考え方で作られています。

3D運転シミュレーターで島式ホームを作りたいのですが、どう再現したら良いでしょうか？

-自己紹介-
　僕はドラえもんと鉄道が好きな2011年4月生まれの人です。他に好きなアニメはSPY×FAMILYとポケモンで、一番好きなJRの鉄道は常磐線E531系です！
　scratchには学校でやっていて、面白かったし、友達もやっていたから2022年6月12日(日) 3:43:08に参加しました。


23940325クイズ！
ドラえもんの登場人物で一番好きなのは誰でしょう？(選択)
①ドラえもん
②のび太
③スネ夫
④ジャイアン
⑤しずか






正解は②でした〜！のび太が一番好きです！心優しいし強い(？)から。
最終更新:7月2日(日)21時34分
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん
ドラえもん

23940325 wrote:

3D運転シミュレーターで島式ホームを作りたいのですが、どう再現したら良いでしょうか？

「3D運転シミュレーター」というと
やり方もいろいろ、
やることもすごくいっぱい
あるような気はするのですが、

基本的な仕組み
そういったプロジェクトでよく使われている「3Dの仕組み」を
まだ書いたことないなら、まず、
https://scratch.mit.edu/projects/639695894/
みたいな、わりと単純なプロジェクト(スプライトの数もブロックの数も少ないようなプロジェクト)を元に、
コードを読んでいじってみる、
片っ端から数字を変えてみる、
テキトウにブロックをはずして何が起こるか観察してみる、
ということをやってみて、ある程度分かってきたら、実際に書いてみる、のが良いと思います。

絵を変えてみて仕組みを観察する
こういった仕組みのプロジェクトで「何を描くか」の部分で重要なのは
「コード」よりも「コスチューム、絵の部分」です。

コードの部分は大雑把に言えば、

絵を、最初は小さく表示して、大きくしていく
ことで「近づいているように見せている」わけですが、

この時、「元の絵の部分部分」の動きを見ていくと、
下にある地面や線路は下へ、上にある空や雲は上へ移動していきます。
「島式プラットホーム」で特殊なのは「左右対称じゃなく、右とか左にしかない」、という部分かと思いますが、
上下と同様に、
右にあるものは右へ、左にあるものは左へ移動していきます。
仕組みとしては特にそれ以上考える必要なないのではないかなと思っています。
これも絵(上のプロジェクトの場合絵ですらないですが)を色々書き足したり消したりしてみて、
「どう動いて見えるのか」観察してみると、
方針が立つかなと思います。

絵を変えてかっこよくする
コードと動きの関係が見えてきたら、あとは、
どういう絵を描くと「それっぽい」か、「かっこいい」か、
という話になると思いますが、
それは「運転シミュレータ」などのキーワードで検索すると見つかるプロジェクトで、
実際にどういうコスチュームが使われているか研究してみるのがよいかと思います。