3D-Engine mit BB2D - unmöglich??

Übersicht

BlitzBasic

Allgemein

Gehe zu Seite Zurück 1, 2

	stfighter01	Mi, Aug 11, 2004 17:28 Antworten mit Zitat
ne 3D engine schreiben ist wirklich nicht sehr sinnvoll unter bb aber trotzdem: line würd ich nicht verwenden doppelt so schneller ist ein 1.zeiliger box befehl. for schleifen sind ca halb so schnell wie unter c++ aber dennoch kein echtes problem
Denken hilft!

stfighter01

Mi, Aug 11, 2004 17:28
Antworten mit Zitat

ne 3D engine schreiben ist wirklich nicht sehr sinnvoll unter bb

aber trotzdem:
line würd ich nicht verwenden
doppelt so schneller ist ein 1.zeiliger box befehl.

for schleifen sind ca halb so schnell wie unter c++
aber dennoch kein echtes problem

Denken hilft!

	TheShadow Moderator	Mi, Aug 11, 2004 18:03 Antworten mit Zitat
Descent war für DOS!!! Das kann man absolut nicht mit Windows-Programmierung vergleichen. Heutzutage manipuliert niemand jeden einzelnen Pixel um so eine 3D-Engine zu erstellen... Deshalb wurden doch 3D-beschleunigte Grafikkarten gebaut - mit deiner Methode belastest du die CPU, nicht die GPU (die aber für Grafik optimiert wurde) Wenn du einer Grafikkarte sagst: zeichne mir ein Dreicke an den Koordinaten, dann macht es die Karte auch. Du musst nicht sagen welche Pixel diese füllen soll. Das macht man selbstverständlich auch nicht per Hand, sondern man nimmt OpenGL/DirectX-Schnittstelle. Im übrigen gab es schon so eine oldschool-demo mit BB2D-Demo bei im Beispiele-Ordner...
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

Mi, Aug 11, 2004 18:03
Antworten mit Zitat

Descent war für DOS!!! Das kann man absolut nicht mit Windows-Programmierung vergleichen. Heutzutage manipuliert niemand jeden einzelnen Pixel um so eine 3D-Engine zu erstellen... Deshalb wurden doch 3D-beschleunigte Grafikkarten gebaut - mit deiner Methode belastest du die CPU, nicht die GPU (die aber für Grafik optimiert wurde)

Wenn du einer Grafikkarte sagst: zeichne mir ein Dreicke an den Koordinaten, dann macht es die Karte auch. Du musst nicht sagen welche Pixel diese füllen soll. Das macht man selbstverständlich auch nicht per Hand, sondern man nimmt OpenGL/DirectX-Schnittstelle.

Im übrigen gab es schon so eine oldschool-demo mit BB2D-Demo bei im Beispiele-Ordner...

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	Markus Rossé	Mi, Aug 11, 2004 18:38 Antworten mit Zitat
Sieh dir doch gleich mal die Speedtipps von TheShadow an, vielleicht kannst du da noch mehr speed rausholen oder musst den Algorithmus verbessern http://www.blitzbase.de/tutorials/shadow_4.htm cu, Markus Rossé

Markus Rossé

Mi, Aug 11, 2004 18:38
Antworten mit Zitat

Sieh dir doch gleich mal die Speedtipps von TheShadow an, vielleicht kannst du da noch mehr speed rausholen oder musst den Algorithmus verbessern

http://www.blitzbase.de/tutorials/shadow_4.htm

cu, Markus Rossé

	Spectator	Mi, Aug 11, 2004 19:17 Antworten mit Zitat
ich habe die routine jetzt für writepixelfast und lockbuffer modifiziert. sie läuft jetzt tatsächlich viel schneller. dass es nicht sehr sinnvoll, weiß ich. mir geht es vor allem darum, die algorithmen, die hinter einer 3d-engine stecken, zu verstehen.

Spectator

Mi, Aug 11, 2004 19:17
Antworten mit Zitat

ich habe die routine jetzt für writepixelfast und lockbuffer modifiziert. sie läuft jetzt tatsächlich viel schneller.
dass es nicht sehr sinnvoll, weiß ich. mir geht es vor allem darum, die algorithmen, die hinter einer 3d-engine stecken, zu verstehen.

	Dreamora	Mi, Aug 11, 2004 19:18 Antworten mit Zitat
Mit welchem Zweck? Mit einer realen 3D Engine hat es ja wenig gmeinsam
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Aug 11, 2004 19:18
Antworten mit Zitat

Mit welchem Zweck?
Mit einer realen 3D Engine hat es ja wenig gmeinsam

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Spectator	Mi, Aug 11, 2004 19:53 Antworten mit Zitat
ich rede von engines der 1. generation. warum? weil ich es interessant finde. ihr wollt mich wohl demotivieren.

Spectator

Mi, Aug 11, 2004 19:53
Antworten mit Zitat

ich rede von engines der 1. generation.
warum? weil ich es interessant finde.
ihr wollt mich wohl demotivieren.

	Markus Rossé	Mi, Aug 11, 2004 20:46 Antworten mit Zitat
@spectator: Mach ruhig dein Projekt weiter und lass dich bitte nicht von anderen Demotivieren. Probier erstmal weiter und wenn du nicht mehr weiterkommst mit optimieren stell es hier ins Forum, damit andere mit dir zusammen darüber brüten können, ob man noch einen funken Speed rausholen kann Ich würde mich freuen.. cu, Markus Rossé

Markus Rossé

Mi, Aug 11, 2004 20:46
Antworten mit Zitat

@spectator: Mach ruhig dein Projekt weiter und lass dich bitte nicht von anderen Demotivieren. Probier erstmal weiter und wenn du nicht mehr weiterkommst mit optimieren stell es hier ins Forum, damit andere mit dir zusammen darüber brüten können, ob man noch einen funken Speed rausholen kann

Ich würde mich freuen..

cu, Markus Rossé

	OJay	Mi, Aug 11, 2004 22:19 Antworten mit Zitat
ich stimme mit markus überein. führe das projekt fort, und schaue wie weit du mit blitz kommst. würde hier viele interessieren... ich persönlich prognostitiere jedoch, das spätestens bei texturen schluss sein wird...

OJay

Mi, Aug 11, 2004 22:19
Antworten mit Zitat

ich stimme mit markus überein. führe das projekt fort, und schaue wie weit du mit blitz kommst. würde hier viele interessieren...

ich persönlich prognostitiere jedoch, das spätestens bei texturen schluss sein wird... Crying or Very sad

	BIG BUG	Do, Aug 12, 2004 9:50 Antworten mit Zitat
Parabellum(oder wie der hieß) hat mal eine Demo auf Blitzcoder veröffentlicht. War so eine 3D-Uhr, mit Texturemapping und Gouraud-Shading. Sah super aus, lief flüssig und war alles reines BB2D(hat er zumindest behauptet ).
B3D-Exporter für Cinema4D!(V1.4) MD2-Exporter für Cinema4D!(final)

BIG BUG

Do, Aug 12, 2004 9:50
Antworten mit Zitat

Parabellum(oder wie der hieß) hat mal eine Demo auf Blitzcoder veröffentlicht. War so eine 3D-Uhr, mit Texturemapping und Gouraud-Shading. Sah super aus, lief flüssig und war alles reines BB2D(hat er zumindest behauptet Smile

B3D-Exporter für Cinema4D!(V1.4)
MD2-Exporter für Cinema4D!(final)

	xperience2003	Sa, Aug 14, 2004 23:13 Antworten mit Zitat
hab mir jetz den ganzen tread nich durchgelesen... aber für ne 3d-engine is blitz etwas unbrauchbar (um nich zu sagen zu lame ) hinzu kommt noch, das moderne grafikkarten im 3d-benchmark schneller sind als im 2d...

xperience2003

Sa, Aug 14, 2004 23:13
Antworten mit Zitat

hab mir jetz den ganzen tread nich durchgelesen...
aber für ne 3d-engine is blitz etwas unbrauchbar (um nich zu sagen zu lame Smile

)

hinzu kommt noch, das moderne grafikkarten im 3d-benchmark schneller
sind als im 2d...

	Vertex	So, Aug 15, 2004 0:39 Antworten mit Zitat
Hi! Also ich habe mich auch schon viel im Kopf über Software 3D Engines nachgedacht. Das dies in Realtime nicht sinnvoll ist, sollte klar sein. Aber was interessant ist, ist die Mathematik die hinter solchen Dingen stehen. Falls es dich also interessiert: Alle Vertices werden als Vektoren abgespeichert. Diese Vektoren kannst du mit den entsprechenden Matricen multiplizieren, um diese zu manipulieren. Code: [AUSKLAPPEN] [EINKLAPPEN] Matrix \| a b c d \| * Vektor ( x = Vektor ( xa + ye + zi + m \| e f g h \| y xb + yf + zj + n \| i j k l \| z ) xc + yg + zk + o ) \| m n o p \| Ein Surface bzw. ein Mesh mit seinen realtiven lokalen Vertexkoordinaten multipliziert du zu erst mit einer Rotationsmatrix, diese ergibt sich aus einer Pitch-, Yaw- und Rollmatrixmultplizierung: Code:* [AUSKLAPPEN] [EINKLAPPEN] Pitch \| 1 0 0 0 \| * Yaw \| cos(a) 0 -sin(a) 0 \| * Roll \| cos(a) sin(a) 0 0 \| \| 0 cos(a) sin(a) 0 \| \| 0 1 0 0 \| \| -sin(a) cos(a) 0 0 \| \| 0 -sin(a) cos(a) 0 \| \| sin(a) 0 cos(a) 0 \| \| 0 0 1 0 \| \| 0 0 0 1 \| \| 0 0 0 1 \| \| 0 0 0 1 \| danach mit einer Skalierungsmatrix: Code: [AUSKLAPPEN] [EINKLAPPEN] Skalierung \| X 0 0 0 \| \| 0 Y 0 0 \| \| 0 0 Z 0 \| \| 0 0 0 1 \| und zu guter letzt mit einer Verschiebungsmatrix: Code: [AUSKLAPPEN] [EINKLAPPEN] Verschiebung \| 1 0 0 0 \| \| 0 1 0 0 \| \| 0 0 1 0 \| \| X Y Z 1 \| diese 3 Matrizen können durch Multiplikation zu einer Matrix verschmolzen und dann mit den Vertices mulitpliziert werden. Um eine Kamera zu realisieren, müsstest du diese Matrix nochmal mit 2 weiteren Matrizen multiplizieren, nämlich einer Rotations- und Verschiebungsmatrix für die Kamera. Hast du alle Vertices entgültig transformiert, so musst du sie für den Z-Buffer sortieren. Dies geschieht, in dem du alle Triangles durchgehst, und von den jeweiligen 3 Vertices heraussuchst, der den größten Z-Wert hat. Diesen Wert speicherst du ab mit der jeweiligen TriangleID und sortierst dann die Triangles nach den größten Z-Wert. Diese zeichnest du zuerst ein. Für das Einzeichnen musst du die 3D Koordinaten in 2D Koordinaten berechnen.: Code: [AUSKLAPPEN] [EINKLAPPEN] CameraZoom = 1 / Tan(FOV / 2) X2D = (X3D(ViewportWidth()/2)CameraZoom)/Z3D+ViewportWidth()/2+ViewportX Y2D = (Y3D(ViewportHeight()/2)-CameraZoom)/Z3D+ViewportHeight()/2+ViewportY FOV steht für Field Of View, also der Sichtwinkel der Kamera. Hast du nun für jedes Triangle die 3 2D Koordinaten, musst du schauen, ob das Triangle überhaupt eingezcihnet werden muss. Dies geschieht über Backfaceculling: Code: [AUSKLAPPEN] [EINKLAPPEN] Function culling(x1, y1, x2, y2, x3, y3) If (x1-x2)(y3-y2)-(y1-y2)(x3-x2)<0 Then Return True Else Return False EndIf End Function (liefert False zurück, wenn das Triangle gezeichnet werden muss). Ja nun hast du die 2D Koordinaten, nun kannst du per Scanline dein Triangle einzeichnen. mfg olli
vertex.dreamfall.at \| GitHub

Vertex

So, Aug 15, 2004 0:39
Antworten mit Zitat

Hi!
Also ich habe mich auch schon viel im Kopf über Software 3D Engines nachgedacht. Das dies in Realtime nicht sinnvoll ist, sollte klar sein. Aber was interessant ist, ist die Mathematik die hinter solchen Dingen stehen.

Falls es dich also interessiert:
Alle Vertices werden als Vektoren abgespeichert. Diese Vektoren kannst du mit den entsprechenden Matricen multiplizieren, um diese zu manipulieren.
Code: [AUSKLAPPEN]

Ein Surface bzw. ein Mesh mit seinen realtiven lokalen Vertexkoordinaten multipliziert du zu erst mit einer Rotationsmatrix, diese ergibt sich aus einer Pitch-, Yaw- und Rollmatrixmultplizierung:
Code: [AUSKLAPPEN]

Pitch | 1 0 0 0 | * Yaw | cos(a) 0 -sin(a) 0 | * Roll | cos(a) sin(a) 0 0 |
| 0 cos(a) sin(a) 0 | | 0 1 0 0 | | -sin(a) cos(a) 0 0 |
| 0 -sin(a) cos(a) 0 | | sin(a) 0 cos(a) 0 | | 0 0 1 0 |
| 0 0 0 1 | | 0 0 0 1 | | 0 0 0 1 |

danach mit einer Skalierungsmatrix:
Code: [AUSKLAPPEN]

Skalierung | X 0 0 0 |
| 0 Y 0 0 |
| 0 0 Z 0 |
| 0 0 0 1 |

und zu guter letzt mit einer Verschiebungsmatrix:
Code: [AUSKLAPPEN]

Verschiebung | 1 0 0 0 |
| 0 1 0 0 |
| 0 0 1 0 |
| X Y Z 1 |

diese 3 Matrizen können durch Multiplikation zu einer Matrix verschmolzen und dann mit den Vertices mulitpliziert werden. Um eine Kamera zu realisieren, müsstest du diese Matrix nochmal mit 2 weiteren Matrizen multiplizieren, nämlich einer Rotations- und Verschiebungsmatrix für die Kamera. Hast du alle Vertices entgültig transformiert, so musst du sie für den Z-Buffer sortieren. Dies geschieht, in dem du alle Triangles durchgehst, und von den jeweiligen 3 Vertices heraussuchst, der den größten Z-Wert hat. Diesen Wert speicherst du ab mit der jeweiligen TriangleID und sortierst dann die Triangles nach den größten Z-Wert. Diese zeichnest du zuerst ein. Für das Einzeichnen musst du die 3D Koordinaten in 2D Koordinaten berechnen.:
Code: [AUSKLAPPEN]

CameraZoom = 1 / Tan(FOV / 2)
X2D = (X3D*(ViewportWidth()/2)*CameraZoom)/Z3D+ViewportWidth()/2+ViewportX
Y2D = (Y3D*(ViewportHeight()/2)*-CameraZoom)/Z3D+ViewportHeight()/2+ViewportY

FOV steht für Field Of View, also der Sichtwinkel der Kamera. Hast du nun für jedes Triangle die 3 2D Koordinaten, musst du schauen, ob das Triangle überhaupt eingezcihnet werden muss. Dies geschieht über Backfaceculling:
Code: [AUSKLAPPEN]

Function culling(x1, y1, x2, y2, x3, y3)
If (x1-x2)*(y3-y2)-(y1-y2)*(x3-x2)<0 Then
Return True
Else
Return False
EndIf
End Function

(liefert False zurück, wenn das Triangle gezeichnet werden muss).
Ja nun hast du die 2D Koordinaten, nun kannst du per Scanline dein Triangle einzeichnen.

mfg olli

vertex.dreamfall.at | GitHub

	Hummelpups	So, Aug 15, 2004 1:34 Antworten mit Zitat
[Ironie]Pfff Kinderkram, habs mir schwerer vorgestellt[/Ironie]

Hummelpups

So, Aug 15, 2004 1:34
Antworten mit Zitat

[Ironie]Pfff Kinderkram, habs mir schwerer vorgestellt[/Ironie]

user posted image

	walski Ehemaliger Admin	So, Aug 15, 2004 11:22 Antworten mit Zitat
Schau dir auf blitzbase.de mal den Bresenham Algorithmus an, damit kannst du "WritePixel-Lines" etwas beschleunigen. walski
buh!

walski

Ehemaliger Admin

So, Aug 15, 2004 11:22
Antworten mit Zitat

Schau dir auf blitzbase.de mal den Bresenham Algorithmus an, damit kannst du "WritePixel-Lines" etwas beschleunigen.

walski

buh!

	TheShadow Moderator	So, Aug 15, 2004 11:23 Antworten mit Zitat
So einfach ist es nicht mit der sortierung... Das Zeichnen übernimmt doch die Grafikarte... Soweit ich weiß wird von jedem Bildpunkt eines Dreiecks ein Z-Wert errechnet und dann eingezeichnet - wenn ein anderes Dreick drüberliegt und der Z-Wert kleiner ist, dann wird es ebenfalls eingezeichnet - wenn es größer ist, dann nicht... http://www.blitzbase.de/lexikon/zbuffer.htm Zu beachten ist zudem noch das Lightning! Dazu muss man für jedes Dreieck einen Normalvektor berechnen - abhängig von der Ausrichtung wird die Helligkeit berechnet... PS: BB ein zu lahm dafür - selbst C oder ASM ist zu lahm - sowas wird immer nur per hardware gemacht - außer man will nur sowas simples wie Würfel oder Donut machen - in BB2D existiert bereits ein Beispiel - das ist auch recht schnell - hat aber nur wenige Polygone EDIT: und linien-algo wird dafür nicht benutzt - sondern Dreieck-Füllung...
AMD64 3500+ \| GeForce6600GT 128MB \| 1GB DDR \| WinXPsp2

TheShadow

Moderator

So, Aug 15, 2004 11:23
Antworten mit Zitat

So einfach ist es nicht mit der sortierung... Das Zeichnen übernimmt doch die Grafikarte...

Soweit ich weiß wird von jedem Bildpunkt eines Dreiecks ein Z-Wert errechnet und dann eingezeichnet - wenn ein anderes Dreick drüberliegt und der Z-Wert kleiner ist, dann wird es ebenfalls eingezeichnet - wenn es größer ist, dann nicht...

http://www.blitzbase.de/lexikon/zbuffer.htm

Zu beachten ist zudem noch das Lightning!
Dazu muss man für jedes Dreieck einen Normalvektor berechnen - abhängig von der Ausrichtung wird die Helligkeit berechnet...

PS: BB ein zu lahm dafür - selbst C oder ASM ist zu lahm - sowas wird immer nur per hardware gemacht - außer man will nur sowas simples wie Würfel oder Donut machen - in BB2D existiert bereits ein Beispiel - das ist auch recht schnell - hat aber nur wenige Polygone

EDIT: und linien-algo wird dafür nicht benutzt - sondern Dreieck-Füllung...

AMD64 3500+ | GeForce6600GT 128MB | 1GB DDR | WinXPsp2

	Vertex	So, Aug 15, 2004 14:24 Antworten mit Zitat
Ist aber wesentlich schneller, als dass ich jeden Z-Wert eines Pixel/Texel von den Dreiecken abspeichere, und danach dann entscheide, welcher zuerst gezeichnet wird. Führt aber beim Überschneiden von Dreiecken zu Darstellungsfehlern, da beide vollständig gezeichnet werden. Eine andere Möglichkeit wäre noch ein Dreieck - Dreieck - Clipping, wo man berechnet, ob und wo sich 2 Dreiecke schneiden, und ab diesen Punkt das eine nichtmehr gezeichnet wird und das andere angefangenen zu zeichnen. Siehe dazu folgendes: http://www.scherfgen-software....79063a8c88 Die Schnittlinie müsste dann natürlich auch in 2D umgerechnet werden. Zum Thema Lighting habe ich mir auch schon Gedanken gemacht: Smoothshading: - Jeder Vertex besitzt ein Normalvektor Beim Pointlight sieht die Berechnugn so aus: Code: [AUSKLAPPEN] [EINKLAPPEN] +++++++++++++++++++++++++++++°+++++++++++++++++++++++++++++++++++++++++++~ 0 25 255 + = Lichtstahl ° = Vertex innerhalb des Lichtstrahls mit einem Lichtwert von 25 ~ = Lichtquelle Hat der Vertex ein Vertexcolorwert von RGB 200, 150, 100 und das Licht einen Lichtfarbwert von RGB 250, 50, 50 dann wird der neue Vertexcolorwert so berechnet: Code: [AUSKLAPPEN] [EINKLAPPEN] TR = 250 / 255 * 25 TG = 50 / 255 * 25 RB = 50 / 255 * 25 VR = (200+TR)/2 VG = (150+TG)/2 VB = (100+TB)/2 VR, VG und VB ist dann die neue Vertexcolor. Beim Ambientlight wird zum Schluss der Ambientwert zu jeder Vertexcolor hinzu addiert. Also: Code: [AUSKLAPPEN] [EINKLAPPEN] VR = VR + AmbientR VG = VG + AmbientG VB = VB + AmbientB Beim direktionalen Licht wird der Lichtvektor mit dem Vertexnormalvektor verglichen: Code: [AUSKLAPPEN] [EINKLAPPEN] VR = (VR+(LNX / VNX)LR) VG = (VG+(LNX / VNX)LG) VB = (VB+(LNX / VNX)*LB) Beim Spotlight funktioniert das so änlich wie beim direktionalen Licht bloß das Abstand zu Lichtquelle, Hotspot und Falloff zusätzlich in die Berechnung einfließen. Beim Flatshading hat jedes Dreieck entweder schon ein definierten Normalvektor, oder er muss berechnet werden. Wenn er berechnet wird, dann muss man 2 Vektoren von Vertex 0 zu Vertex 1 und von Vertex 0 zu Vertex 2 bilden. Aus diesen beiden Vektoren bildet man das Kreuzprodukt. Der resultierende Vektor steht dann genau Senkrecht auf den Dreieck. Dieser Vektor kann dann genauso zum Berechnen des Lichts genutzt werden, wie ein Vertexnormalvektor bloß das die Farbe dann auf das ganze Dreieck angewand wird. walski: Beim Scanline werden vertikale Linien benötigt(natürlich nur beim Flatschading und ohne Texturemapping). Deswegen ist es schneller eine For-Next Schleife laufen zu lassen, die einen Pixel auf der X Achse einträgt. mfg olli
vertex.dreamfall.at \| GitHub

Vertex

So, Aug 15, 2004 14:24
Antworten mit Zitat

Ist aber wesentlich schneller, als dass ich jeden Z-Wert eines Pixel/Texel von den Dreiecken abspeichere, und danach dann entscheide, welcher zuerst gezeichnet wird. Führt aber beim Überschneiden von Dreiecken zu Darstellungsfehlern, da beide vollständig gezeichnet werden. Eine andere Möglichkeit wäre noch ein Dreieck - Dreieck - Clipping, wo man berechnet, ob und wo sich 2 Dreiecke schneiden, und ab diesen Punkt das eine nichtmehr gezeichnet wird und das andere angefangenen zu zeichnen. Siehe dazu folgendes: http://www.scherfgen-software....79063a8c88 Die Schnittlinie müsste dann natürlich auch in 2D umgerechnet werden.

Zum Thema Lighting habe ich mir auch schon Gedanken gemacht:
Smoothshading:
- Jeder Vertex besitzt ein Normalvektor
Beim Pointlight sieht die Berechnugn so aus:
Code: [AUSKLAPPEN]

+++++++++++++++++++++++++++++°+++++++++++++++++++++++++++++++++++++++++++~
0 25 255

+ = Lichtstahl
° = Vertex innerhalb des Lichtstrahls mit einem Lichtwert von 25
~ = Lichtquelle

Hat der Vertex ein Vertexcolorwert von RGB 200, 150, 100 und das Licht einen Lichtfarbwert von RGB 250, 50, 50 dann wird der neue Vertexcolorwert so berechnet:
Code: [AUSKLAPPEN]

TR = 250 / 255 * 25
TG = 50 / 255 * 25
RB = 50 / 255 * 25
VR = (200+TR)/2
VG = (150+TG)/2
VB = (100+TB)/2

VR, VG und VB ist dann die neue Vertexcolor.

Beim Ambientlight wird zum Schluss der Ambientwert zu jeder Vertexcolor hinzu addiert. Also:
Code: [AUSKLAPPEN]

VR = VR + AmbientR
VG = VG + AmbientG
VB = VB + AmbientB

Beim direktionalen Licht wird der Lichtvektor mit dem Vertexnormalvektor verglichen:
Code: [AUSKLAPPEN]

VR = (VR+(LNX / VNX)*LR)
VG = (VG+(LNX / VNX)*LG)
VB = (VB+(LNX / VNX)*LB)

Beim Spotlight funktioniert das so änlich wie beim direktionalen Licht bloß das Abstand zu Lichtquelle, Hotspot und Falloff zusätzlich in die Berechnung einfließen.

Beim Flatshading hat jedes Dreieck entweder schon ein definierten Normalvektor, oder er muss berechnet werden. Wenn er berechnet wird, dann muss man 2 Vektoren von Vertex 0 zu Vertex 1 und von Vertex 0 zu Vertex 2 bilden. Aus diesen beiden Vektoren bildet man das Kreuzprodukt.
Der resultierende Vektor steht dann genau Senkrecht auf den Dreieck. Dieser Vektor kann dann genauso zum Berechnen des Lichts genutzt werden, wie ein Vertexnormalvektor bloß das die Farbe dann auf das ganze Dreieck angewand wird.

walski: Beim Scanline werden vertikale Linien benötigt(natürlich nur beim Flatschading und ohne Texturemapping). Deswegen ist es schneller eine For-Next Schleife laufen zu lassen, die einen Pixel auf der X Achse einträgt.

mfg olli

vertex.dreamfall.at | GitHub

	Edlothiol	So, Aug 15, 2004 21:27 Antworten mit Zitat
Sehr hilfreiche Seite: http://freespace.virgin.net/hu...x_main.htm Da wird z.B. Scanline - Algorithmus und Gouraud - Shading beschrieben.

Edlothiol

So, Aug 15, 2004 21:27
Antworten mit Zitat

Sehr hilfreiche Seite:
http://freespace.virgin.net/hu...x_main.htm
Da wird z.B. Scanline - Algorithmus und Gouraud - Shading beschrieben.

Gehe zu Seite Zurück 1, 2

Übersicht

BlitzBasic

Allgemein

Nach Oben

BlitzBasic Portal

3D-Engine mit BB2D - unmöglich??