Ich hab im meiner Terrain-Engine das Problem, das ich keine Normalen für die Beleuchtung des Terrains habe. Deswegen möchte ich gerne erfahren, wie man Vertexnormalen berechnet (für jeden Punkt auf der Heightmap eine Normale).

Kann mir jemand einen Tipp geben? ( Ich möchte nicht irgendwie anfangen mit Dreiecken bzw. Polygonen zu hantieren, denn es muss doch eine einfach Lösung geben, die Normale aus den umliegenden Punkten des Punktes, von dem ich die Normale berechnen will, zu berechnen! )

Quellcode:O O O
O X O
O O O
Das X ist dabei der Punkt, von dem ich die Normale berechnen will!

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Kann hier KEINER Vertexnormalen berrechnen???

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

wie wäre es mit `will niemand dir die lösung in den arsch schieben?' ?

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

http://www.flipcode.com/ -> Message Center -> Search

"Gotta admit that I'm a little bit confused
Sometimes it seems to me as if I'm just being used
Gotta stay awake, gotta try and shake off this creeping malaise
If I don't stand my own ground, how can I find my way out of this place" Pink Floyd - Dogs

Naja, du weißt doch sicher, wie man von einer Ebene eine Normale berechnet.
Also bastel dir einfach aus deinen Punkten ne Ebene...

www.d3opencoop.com - A Doom3 Cooperative Mod

lol....

3 Punkte passen noch in ne Ebene, wenn ich aber mehr nehme, hab ich das Prob, das die nicht zwangsläufig (bzw nur in SEHR seltenen Fällen) in einer Ebene liegen...

Ein bisschen logisches Denken wäre net schlecht...

@sth: Danke. Ich benutzt jetzt einfach die Normalen eines Dreiecks als Vertexnormale. Ist zwar net 100% acc., aber es sieht ordentlich aus.

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Zitat:

3 Punkte passen noch in ne Ebene, wenn ich aber mehr nehme, hab ich das Prob, das die nicht zwangsläufig (bzw nur in SEHR seltenen Fällen) in einer Ebene liegen...

In eine Ebene passen unendlich viele Punkte, das nur nebenbei. Die Punkte für deine Ebene (wie Nicemice meinte) hast du doch vorgegeben durch ein Triangle. Wenn du nun die Normale zu einem Vertex willst, nimmst du alle Normalen der Ebenen, die diesen einen Vertex (Punkt) schneiden und errechnest das Mittel.

Dürfte eigentlich klappen.

Against TCPA | Resourcecode.de | Blender 3D | [ Darkzone | Pandorra | Alpine ]

Die 4 Punkte
(1,1,1) (0,0,0) (1,1,0) (11,1212,121.12)
liegen GARANTIERT NICHT in einer Ebene...

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Lies nochmal durch was TheVoice geschrieben hat und denke darüber nach.

www.d3opencoop.com - A Doom3 Cooperative Mod

LoL so mache ich das ja schon...

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Dürfte man nach einer Definition con Vertex fragen, und was eine Normale ist?
oder wird man dann geschlagen?
*duck*

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren

ein Vertex ist nichts weiter als ein Punkt
eine Normale (zu einer Fläche) ist eine Gerade die senkrecht auf der Fläche steht (gleichzusetzen mit nem Lot)

/edit: ohoh nachdem was the_viking hier unter mir postet muss ich meine sig ändern =)

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Eigendlichs sollte man geschlagen und gesteinigt werden, aber da dies ja ein überaus NETTES Forum ist, geb ich dir mal ne Antwort:

Vertex:
Jedes 3D-Objekt besteht (wie du vielleicht weisst) aus Polygonen (Poly=mehr gon=kante (glaub ich ;) ) = Mehrkantig). Jedes Polygon ist eine Form, die aus mehreren Kanten besteht, und die Kanten bekommt man dadurch, das man 2 Punkte miteinander Verbindet. Diese Punkte heissen Vertex. Im gegensatz zu einem Vector(x,y,z) beinhaltet ein Vertex meistens noch Texturkoordinaten(u,v) oder Farbinformationen(r,g,b).

Normale:
Vektoren geben jeweils eine Richtung an. z.B. zwei Vektoren a und b sind so definiert:
a = ( 1 | 0 | 0 )
b = ( 0 | 0 | 1 )

Vektor a zeig in richtung x-Achse und Vektor b zeigt in richtung z-Achse.
Die Normale ist dann der Vektor, der senkrecht auf zwei anderen Vectoren steht. Herauskriegen kann man den mit dem Kreuzprodukt zweier Vektoren (dafür googlest du einfach mal ;)). Der einfachheit halber geb ich den Normalenvektor für die Vektoren a und b mal an:
a x b = ( 0 | 1 | 0 )

x = Kreuzprodukt

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Die Normale ist nicht der Vektor, der senkrecht zu 2 anderen (im 3-Dimensionalen) steht, sondern einer der Vektoren, die senkrecht stehen. Es gibt unendlich viele Normalen von 2 Vektoren, sie unterscheiden sich durch den Betrag und die Orientierung, aber nicht durch die Richtung.
Natürlich könnte der Fall auftreten, dass die 2 Vektoren, von denen man die Normale sucht, identisch oder zumindest kollinear sind, dann hat man natürlich ein Problem mit seiner Normalen, da das Kreuzprodukt dann ein Nullvektor ist. Soweit ich weiss ist in so einem Fall die Normale nicht definiert.

Wie man das Kreuzprodukt berechnet, hängt natürlich von der Form ab, in der man die Vektoren vorliegen hat.

Normal hat in der Mathematik (zumindest in der Geometrie) fast immer etwas mit senkrecht / orthagonal zu tun.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

Nunja mal sehn ob ich die vorgehensweise verstanden habe, du hast also einen Vertex in der Mitte und 8 angrenzende, macht 8 Dreiecke (sprich Ebenen) von denen du den Normalenvektor errechnest. Dann denke ich mal, normalisierst du die alle, addierst sie zusammen und hast somit ne gute Annäherung an den Normalenvektor des Punktes? Ist das nicht _etwas_ rechenintensiv? Ich empfehle dir, ne Prüffunktion irgend ne if blah schleife, wenn da 2 oder mehr der 8 umliegenden Punkte die gleiche "Höhe" (X-Koordinate oder whatever) haben, den Rest abzubrechen und direkt von dieser Ebene den Normalenvektor zu berechnen. Der wäre dann zumindest genau

mfg

[EDIT] Ja Moment mal, man _muss_ sogar ebenen bilden, wie will man von einem Vertex auch den Normalenvektor bestimmen, die hätten ja alle die selben Richtungen O_o. Anstatt, dass du dein Terrain aus Vertexen (Punktvektoren sind das doch oder? ) aufbaust, mach es viel mehr sinn, wenn die "kleinsten Einheiten" Dreieicke sind. Somit hast du dann auch kein Problem mit den Normalen[EDIT]

mfg 2

Ja und nochwas, die Lösung, mit der Durchschnitts Normalen für einen Vertex , wie sähe das aus? Belichtet werden die Eckpunkte der Flächen? Wo gibts den sowas O_o. Nun ich weiss nicht, wie in Vertex-, Voxtel- oder wie auch immer Enginen die Beleuchtung geht (Raytrace?) aber dieses Mischmasch mit klassischen Polygon Techniken dürfte ned so optimal sein. Denk ich. Kann mich irren. hoffe aber trotzdem geholfen zu haben :)

Zitat:

McMapper postete
ne if blah schleife

\o tanz den naziprau! o/

And more than ever, I hope to never fall,
Where enough is not the same it was before

wie nennt man das dann? So ein "Einschub" halt.. wenn das, dann das ... :D

Das nennt sich if-Bedingnung.

"tsuji-giri" (japanisch) - ein neues Schwert an einem Passanten ausprobieren

LoL... Also @Mc:
Natürlich rendere ich mein Terrain aus Dreiecke... nur Dreiecke bestehen halt auch nur aus Vertexen ;)

Aber wenn ich jetzt Pro Dreieck eine Normale hätte, dann sähe das aus wie Egoshooter aus dem Jahre '95... Flatshaded.. Und das sieht bei Terrain ziemlich sch..sse aus... Deswegen benutze ich Vertexnormalen, bei denen die Normalen der Vertexe beim rastern über das Dreieck hinweg interpoliert werden und damit jedes einzelne Pixel einen eigene Helligkeitswert bekommt anstatt das alle nur einen Helligkeitswert (den des Dreiecks) bekommen. Dann entstehen nämlich nicht diese Hässlichen Shading-Kanten an Polygonkanten.

zu deinem mfg2:
Es handelt sich hier um "dynamisches" Lighting und nicht um vorberechnete Lightmaps. Die werden bei Terrain meistens durch Raytracing errechnet, dies allerdings jeden Frame und für ein 1024er Terrain durchzuführen wäre extrem Langsam.

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446

Nun, gut ein paar Missverständnisse aufgelärt ^^ Aber dennoch, irgendwie kapier ich nicht, wie das funktionieren soll. Wieviele Vertexe pro Dreieck wird es geben? Eine fixe Anzahl? Und je nach grösse des Polygons, nehmen auch die einzelnen Vertexte immer kleinere "Flächen" an. Ich meine auch, eine Fläche mit mathematischen Punkten zu rendern ist "komisch" ein Punkt hat ja eigentlich keine räumliche ausdehnung. Oder gilt dann der Helligkeitswert, der für einen Vertex errechnet wurde bei jedem Dreick je nach grösse für eine bestimmte fläche? (Diese Fläche, wie ist die dann beschaffen? Dreieck? Rund? Sprite? Dynamische Lightmap? ) Haben diese "Flächen" dann immer eine gleich grosse ausdehnung und du musst auch noch errechnen, wieviele von denen in ein Polygon reingerastert werden können? Fragen über Fragen.

Hm, wenn ich mir deine Antwort nochmal durchlese, wenn du interpolieren willst wirst du trotzdem für jeden Vertex die selbe Normale bekommen wie für das grosse Dreieck, denn die Miniflächen, die du mit den umliegenden vertexen bilden wirst, werden alle genau die selbe "Schräglage" und somit die selbe Normale besitzen welche ja auch mit der des grossen Dreiecks identisch ist. Damit es nicht so flatshaded ausieht, müsstest du einfach schöne Übergänge zu den anderen grossen Dreicken und deren Farbwerten errechnen. Aber ob du dazu die ganze Vektor Hantiererei benötigst, weiss ich nicht. Evtl. habe ich aber auch nur wieder etwas falsch verstanden. Bitte um Aufklärung. :-)

mfg

@theDon: Bei mir haben Schleifen in C sogar immer etwas mit for zu tun...

Die Probleme von McMapper kann ich allerdings auch verstehen. In der Mathematik besteht ein Dreieck in R³ aus unendlich vielen Punkten. In C++ wird man R³ wahrscheinlich mit "double³" darstellen, damit gibt es immer noch genug Punkte in einem Dreieck um eine Lichtberechnung jedes einzelnen unmöglich zu machen (bei einer halbwegs akzeptablen Framerate).

Eine Normale alleine reicht ja auch nicht aus, um eine Ebene zu beschreiben, da ja noch die wichtige Information fehlt, wo diese Ebene sich denn überhaupt befindet.
Beispiel: Die x|y-Ebene hat (unter anderem) den Normalenvektor (0|0|1). Eine horizontale Ebene auf der Höhe 10 hat aber auch den Normalenvektor (0|0|1), genau so wie jede andere horizontale Ebene.

Der Normalenvektor beschreibt also nur das, was McMapper als "Schräglage" bezeichnet hat.

Entities: HL | HL²
Kompilierfehler
r_speeds | mehr über r_speeds

naja evtl kann er ja noch die Ebenegleichung ausrechnen lassen, mit einem Vertex kann man ja dann auch noch d ausrechnen. Dieses d kann er ja evtl auch zur Farbberechnung verwenden

Naja egal.... Schluss der Diskussion, hab eine Lösung gefunden: Normale wird aus dem Dreieck berechnet, das der Heightmappunkt an x,y sowie die Punkte x+1,y sowie x,y+1 bilden. Die werden zum Gouroudshading herangezogen und sieht ganz ordentlich aus, nur halt nicht perfekt ;). Aber ich hab im mom keine Lust alle Anliegenden Dreiecke mit Normale auszurechnen und den Durchschnitt zu bilden...

thx, cu, MfG the_viking

(( My =]=H=O=M=E=> Page! ))
Coder bei Brainshock-Interactive und bei Z-Software
My ICQ: #160959446