3D Berechnungs Bug?

Übersicht

BlitzBasic

Blitz3D

	Tirus Betreff: 3D Berechnungs Bug?	Mi, Jan 07, 2009 15:33 Antworten mit Zitat
Hallo Zusammen Mir ist aufgefallen, als ich versucht habe ein 3D GUI zu proggen, dass die Positionen nicht mehr richtig stimmen, wenn die Kamera weit außerhalb des mittelpunktes (0 0 0) ist. Je weiter man draußen ist, desto mehr "Ruckelt" jedes Gerenderte 3D Objekt hin und her Hier zum Veranschaulichen Code: [AUSKLAPPEN] [EINKLAPPEN] Graphics3D 640,480,0,2 SetBuffer BackBuffer() cam = CreateCamera() spr = CreateSprite(cam) MoveEntity spr, 0,0,10 While Not KeyHit(1) If KeyHit(2) Then PositionEntity cam, 0,0,0 If KeyHit(3) Then PositionEntity cam, 0,0,10000 If KeyHit(4) Then PositionEntity cam, 0,0,100000 If KeyHit(5) Then PositionEntity cam, 0,0,1000000 If KeyHit(6) Then PositionEntity cam, 0,0,10000000 TurnEntity cam, 1,1,1 RenderWorld Text 0,0, "Drücke die Tasten 1-5 um die Entfernung einzustellen" Text 0,100, "X: "+EntityX(cam) Text 0,115, "Y: "+EntityY(cam) Text 0,130, "Z: "+EntityZ(cam) Text 0,150, "Pitch: "+EntityPitch(cam) Text 0,165, "Yaw: "+EntityYaw(cam) Text 0,180, "Roll: "+EntityRoll(cam) Flip Wend End Ich habe zwar bereits eine lösung für dieses Problem, indem ich alles um die Kamera bewege, aber trotzdem wollte ich mal wissen, ob jemand weiß wieso das so ist. MfG Tirus

Tirus

Betreff: 3D Berechnungs Bug?

Mi, Jan 07, 2009 15:33
Antworten mit Zitat

Hallo Zusammen

Mir ist aufgefallen, als ich versucht habe ein 3D GUI zu proggen, dass die Positionen nicht mehr richtig stimmen, wenn die Kamera weit außerhalb des mittelpunktes (0 0 0) ist.

Je weiter man draußen ist, desto mehr "Ruckelt" jedes Gerenderte 3D Objekt hin und her

Hier zum Veranschaulichen

Code: [AUSKLAPPEN]

Graphics3D 640,480,0,2

SetBuffer BackBuffer()

cam = CreateCamera()

spr = CreateSprite(cam)

MoveEntity spr, 0,0,10

While Not KeyHit(1)
If KeyHit(2) Then PositionEntity cam, 0,0,0
If KeyHit(3) Then PositionEntity cam, 0,0,10000
If KeyHit(4) Then PositionEntity cam, 0,0,100000
If KeyHit(5) Then PositionEntity cam, 0,0,1000000
If KeyHit(6) Then PositionEntity cam, 0,0,10000000

TurnEntity cam, 1,1,1
RenderWorld

Text 0,0, "Drücke die Tasten 1-5 um die Entfernung einzustellen"

Text 0,100, "X: "+EntityX(cam)
Text 0,115, "Y: "+EntityY(cam)
Text 0,130, "Z: "+EntityZ(cam)

Text 0,150, "Pitch: "+EntityPitch(cam)
Text 0,165, "Yaw: "+EntityYaw(cam)
Text 0,180, "Roll: "+EntityRoll(cam)

Flip

Wend

End

Ich habe zwar bereits eine lösung für dieses Problem, indem ich alles um die Kamera bewege, aber trotzdem wollte ich mal wissen, ob jemand weiß wieso das so ist.

MfG Tirus

	NightPhoenix	Mi, Jan 07, 2009 16:02 Antworten mit Zitat
Ich kanns dir ehrlich gesagt auch nicht erklären, ich kenne diese Erscheinung aber auch schon länger. Es ist aber nicht richtig es einen Bug zu nennen Das ist sowas wie eine Gleitkommaungenauigkeit. Man könnte sagen: je weiter du die Kamera (nicht Spieler, es kommt auf die Kamera an) vom Zentrum (0/0/0) wegbewegst desto ungenauer wird die berechnete Position. Ich glaub mir hat das mal jemand damit erklärt, dass die Genauigkeit der Stellen nach dem Komma nahe dem zentrum sehr hoch sind, umso weiter du dich von ihm entfernst umso ungenauer kann dies bestimmt werden. (Beispiel) so könnte die Ungenauigkeit/Abweichung bei z=100 bei 0,0001 liegen... bei z=100000 liegt sie beispielsweise bei 0,1. Eine Ungenauigkeit von 0,1 heißt dass die soll-position mit +/- 0,1 Variabilität vorliegt. Mit anderen Worten: Das ganze ruckelt in dem bereich, bzw. "springt" hin und her. Das ist überall in 3D so Irgendwann ist die Ungenauigkeit übrigens groß genug dass dein Bildschirm einfach nur noch schwarz wird Übrigens 2: Man kann diese Ungenauigkeit nicht durch unterschiedliche Skalierungen umgehen oder vermindern. Die Ungenauigkeit bleibt dem Größenverhältnissen entsprechend So mal wieder viel Senf gelabert, ich hoffe du kannst den Kern herauslesen

NightPhoenix

Mi, Jan 07, 2009 16:02
Antworten mit Zitat

Ich kanns dir ehrlich gesagt auch nicht erklären, ich kenne diese Erscheinung aber auch schon länger.
Es ist aber nicht richtig es einen Bug zu nennen Wink

Das ist sowas wie eine Gleitkommaungenauigkeit.
Man könnte sagen: je weiter du die Kamera (nicht Spieler, es kommt auf die Kamera an) vom Zentrum (0/0/0) wegbewegst desto ungenauer wird die berechnete Position. Ich glaub mir hat das mal jemand damit erklärt, dass die Genauigkeit der Stellen nach dem Komma nahe dem zentrum sehr hoch sind, umso weiter du dich von ihm entfernst umso ungenauer kann dies bestimmt werden. (Beispiel) so könnte die Ungenauigkeit/Abweichung bei z=100 bei 0,0001 liegen... bei z=100000 liegt sie beispielsweise bei 0,1.
Eine Ungenauigkeit von 0,1 heißt dass die soll-position mit +/- 0,1 Variabilität vorliegt. Mit anderen Worten: Das ganze ruckelt in dem bereich, bzw. "springt" hin und her.
Das ist überall in 3D so Wink

Irgendwann ist die Ungenauigkeit übrigens groß genug dass dein Bildschirm einfach nur noch schwarz wird Wink

Übrigens 2:
Man kann diese Ungenauigkeit nicht durch unterschiedliche Skalierungen umgehen oder vermindern. Die Ungenauigkeit bleibt dem Größenverhältnissen entsprechend

So mal wieder viel Senf gelabert, ich hoffe du kannst den Kern herauslesen

	Tirus	Mi, Jan 07, 2009 16:19 Antworten mit Zitat
Jo ich denke ich weiß was du meinst, ist wohl wie (oder eher genau) bei der float zahl, hat 4 bytes stellen, und je größer die ganze zahl wird, desto weniger stellen werden hinter dem komma gespeichert. Da ist wohl meine lösung alles um die Kamera zu bewegen wohl die einzige die was bringt. Auch wenn das die Kollisionsberechnung erschwert... Jedenfalls danke für die Antwort

Tirus

Mi, Jan 07, 2009 16:19
Antworten mit Zitat

Jo ich denke ich weiß was du meinst, ist wohl wie (oder eher genau) bei der float zahl, hat 4 bytes stellen, und je größer die ganze zahl wird, desto weniger stellen werden hinter dem komma gespeichert.

Da ist wohl meine lösung alles um die Kamera zu bewegen wohl die einzige die was bringt.

Auch wenn das die Kollisionsberechnung erschwert...

Jedenfalls danke für die Antwort

	Tankbuster	Mi, Jan 07, 2009 16:23 Antworten mit Zitat
Nja, aber welche normale Mensch benutzt schon eine Spielwelt von 10000x10000x10000 oder mehr? Richtig: Niemand und wenn doch, dann nichtmehr, nachdem er dies hier gelesen hat: .... Übrigens, das ist ein Rechenfehler Das kann man einfach rausfinden, indem man "EntityZ#(spr,1)" ausgeben lässt. Es sieht so aus, dass bei dem Float, der zurückgegeben wird, sich höchstens die 6te Stelle verändern kann. Also... Aus 1.00006 wird immer 10 folgendes: Code:* [AUSKLAPPEN] [EINKLAPPEN] 1.00006 10.0006 100.006 1000.06 10000.6 100006.0 1000060.0 10000600.0 100006000.0 Alles was nach der 6 steht, ist immer 0. Das habe ich auf jedenfall bei meinen Test rausgefunden. Da sieht man ganz deutlich, dass es zu ziemlich großen Ungenauigkeiten kommt, wenn man so eine riesige Zahl einsetzt. Bei einer 7-stelligen Zahl (z.B. 1000060.0) ist die kleinste Einheitsveränderung also 10.0 . Das heißt, dass das Sprite sich auchnicht weniger als 10.0 bewegen kann. Eine Bewegung von z.B. 0.1 ist garnicht möglich. Daher entsteht auch das ruckeln Bei kleinen größen wie 100.006 kann das Sprite sich aber noch um 0.001 bewegen, also sieht es flüssig aus Ich hoffe ich konnte helfen... MFG: Tank
Twitter Download Jewel Snake! Windows\|Android

Tankbuster

Mi, Jan 07, 2009 16:23
Antworten mit Zitat

Nja, aber welche normale Mensch benutzt schon eine Spielwelt von 10000x10000x10000 oder mehr?
Richtig: Niemand Wink

und wenn doch, dann nichtmehr, nachdem er dies hier gelesen hat: .... Laughing

Übrigens, das ist ein Rechenfehler Wink

Das kann man einfach rausfinden, indem man "EntityZ#(spr,1)" ausgeben lässt.
Es sieht so aus, dass bei dem Float, der zurückgegeben wird, sich höchstens die 6te Stelle verändern kann.

Also...

Aus 1.00006 wird immer *10 folgendes:
Code: [AUSKLAPPEN]

1.00006
10.0006
100.006
1000.06
10000.6
100006.0
1000060.0
10000600.0
100006000.0

Alles was nach der 6 steht, ist immer 0. Das habe ich auf jedenfall bei meinen Test rausgefunden.

Da sieht man ganz deutlich, dass es zu ziemlich großen Ungenauigkeiten kommt, wenn man so eine riesige Zahl einsetzt.

Bei einer 7-stelligen Zahl (z.B. 1000060.0) ist die kleinste Einheitsveränderung also 10.0 . Das heißt, dass das Sprite sich auchnicht weniger als 10.0 bewegen kann. Eine Bewegung von z.B. 0.1 ist garnicht möglich. Daher entsteht auch das ruckeln Wink

Bei kleinen größen wie 100.006 kann das Sprite sich aber noch um 0.001 bewegen, also sieht es flüssig aus Wink

Ich hoffe ich konnte helfen...
MFG: Tank Wink

Twitter
Download Jewel Snake!
Windows|Android

	NightPhoenix	Mi, Jan 07, 2009 23:26 Antworten mit Zitat
Zitat: Nja, aber welche normale Mensch benutzt schon eine Spielwelt von 10000x10000x10000 oder mehr? Richtig: Niemand Also ich bin bei den Anfängen meines 3D Spaceshooters schon nach (reale Maße) 100km auf diese Grenze gestoßen... und ich baue auf ne Spielwelt von 10 millionen kilometern ^^ (gibt keine Level) Was ist mit Gothic 3, deren Welt sprengt diese Grenze auch bei weitem. Also vorsichtig mit der Aussage dass das kein normaler Mensch benutzt Ich hab mal gehört, dass fast jedes kommerzielle Spiel da draußen mit dem "Welt wird um die kamera bewegt" Prinzip arbeitet, eben um das "Ruckeln" zu verhindern. Ach und meinst du wirklich, dass das ein RechenFEHLER ist? Das würde ja heißen dass das Programm was falsch macht, also anders als es sein sollte. Klingt für mich eher wie beabsichtigt, wenn es immer genau die X. Stelle nach der 1. Zahl ist. Ich vermute mal eher das wurde mit Absicht eingebaut um das Näherungsverfahren (was wohl die meisten Programme benutzen - übrigens auch Taschenrechner) für die CPU einzuschränken. Man könnte sicherlich auch Floats mit 20 Stellen berechnen, nur würde die CPU dafür wesentlich länger brauchen. Mmmh... könnte man Blitzbasic nicht damit auch beschleunigen? ^^ 5 stellen floats reichen ja vielleicht auch

NightPhoenix

Mi, Jan 07, 2009 23:26
Antworten mit Zitat

Zitat:

Nja, aber welche normale Mensch benutzt schon eine Spielwelt von 10000x10000x10000 oder mehr?
Richtig: Niemand

Also ich bin bei den Anfängen meines 3D Spaceshooters schon nach (reale Maße) 100km auf diese Grenze gestoßen... und ich baue auf ne Spielwelt von 10 millionen kilometern ^^ (gibt keine Level)
Was ist mit Gothic 3, deren Welt sprengt diese Grenze auch bei weitem.

Also vorsichtig mit der Aussage dass das kein normaler Mensch benutzt Smile

Ich hab mal gehört, dass fast jedes kommerzielle Spiel da draußen mit dem "Welt wird um die kamera bewegt" Prinzip arbeitet, eben um das "Ruckeln" zu verhindern.

Ach und meinst du wirklich, dass das ein RechenFEHLER ist? Das würde ja heißen dass das Programm was falsch macht, also anders als es sein sollte. Klingt für mich eher wie beabsichtigt, wenn es immer genau die X. Stelle nach der 1. Zahl ist.
Ich vermute mal eher das wurde mit Absicht eingebaut um das Näherungsverfahren (was wohl die meisten Programme benutzen - übrigens auch Taschenrechner) für die CPU einzuschränken. Man könnte sicherlich auch Floats mit 20 Stellen berechnen, nur würde die CPU dafür wesentlich länger brauchen.

Mmmh... könnte man Blitzbasic nicht damit auch beschleunigen? ^^ 5 stellen floats reichen ja vielleicht auch

	Noobody	Mi, Jan 07, 2009 23:44 Antworten mit Zitat
Das liegt daran, wie Floats aufgebaut sind. Eine normale Float hat 4 Bytes, wovon ein Teil Exponent und ein Teil Mantisse ist - die Aufteilung kann variieren. So beschreibt die Mantisse die eigentliche Zahl und der Exponent, wo das Komma liegt, sozusagen. Von 3.14159 wäre nun die Mantisse 314159 und der Exponent -5 (314159*10^-5 = 3.14159). Daher ist es begrenzt, wieviele Kommastellen eine Float hat (je nach dem, wieviele Bits für die Mantisse verwendet werden). Man kann daher auch nicht einfach ein paar Stellen wegstreichen, um die Rechenzeit zu verkürzen - die 32 Bit muss man ja trotzdem füllen (wegen der Prozessorarchitektur und so). Und 20 - Stellige Kommazahlen gibts schon, die heissen 'double' in den meisten Programmiersprachen Das gibt es nur leider nicht in B3D.
Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

Noobody

Mi, Jan 07, 2009 23:44
Antworten mit Zitat

Das liegt daran, wie Floats aufgebaut sind.
Eine normale Float hat 4 Bytes, wovon ein Teil Exponent und ein Teil Mantisse ist - die Aufteilung kann variieren.
So beschreibt die Mantisse die eigentliche Zahl und der Exponent, wo das Komma liegt, sozusagen.

Von 3.14159 wäre nun die Mantisse 314159 und der Exponent -5 (314159*10^-5 = 3.14159).
Daher ist es begrenzt, wieviele Kommastellen eine Float hat (je nach dem, wieviele Bits für die Mantisse verwendet werden).
Man kann daher auch nicht einfach ein paar Stellen wegstreichen, um die Rechenzeit zu verkürzen - die 32 Bit muss man ja trotzdem füllen (wegen der Prozessorarchitektur und so).

Und 20 - Stellige Kommazahlen gibts schon, die heissen 'double' in den meisten Programmiersprachen Wink

Das gibt es nur leider nicht in B3D.

Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. -- Wernher von Braun

	hectic Sieger des IS Talentwettbewerb 2006	Mi, Jan 07, 2009 23:47 Antworten mit Zitat
NightPhoenix, komerzielle Spiele laden Levelelemente im Hintergrund so, dass man es nicht bemerkt. Ältere Spiele laden mit Ladepausen. Man kann komerzielle Spiele nicht mit einem Einmannprojekt und Blitz3D vergleichen. Die Außsage von Tankbuster stimmt also in dem Sinne, dass man die Koordination nicht zu groß werden lassen darf. Dein "Welt wird um die kamera bewegt" -Prinzip ist also genau das, dass man eben den Spieler auf Koordinate 0,0,0 setzt und ggf. Levelelemente nachlädt. Die Sichtweite beträgt somit allerdings nie die Rundungsgrenzen von Floats. Das alles ist im übrigen mit Blitz3D doch etwas schwiriger umzusetzen. Außerdem würde ich gerne wissen wie du bisher 100km Leveldesign hinter dir gebracht hast. Und vor allem wie du dir 10Gm vorgestellt hast. Eine Weltumrundung am Äquator hat übrigens etwa 42Mm. Deine Levelplanung beinhaltet also die Ausmasse über 238 Weltumrundungen an Leveldesign. Mit Lichgeschwindigkeit würde man (für Außenstehende) diese Strecke erst nach etwa 33 Sekunden erreichen. Es entspricht auch etwa 12,5mal die Strecke zum Mond und zurück.
Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

hectic

Sieger des IS Talentwettbewerb 2006

Mi, Jan 07, 2009 23:47
Antworten mit Zitat

NightPhoenix, komerzielle Spiele laden Levelelemente im Hintergrund so, dass man es nicht bemerkt. Ältere Spiele laden mit Ladepausen. Man kann komerzielle Spiele nicht mit einem Einmannprojekt und Blitz3D vergleichen.

Die Außsage von Tankbuster stimmt also in dem Sinne, dass man die Koordination nicht zu groß werden lassen darf. Dein "Welt wird um die kamera bewegt" -Prinzip ist also genau das, dass man eben den Spieler auf Koordinate 0,0,0 setzt und ggf. Levelelemente nachlädt. Die Sichtweite beträgt somit allerdings nie die Rundungsgrenzen von Floats. Das alles ist im übrigen mit Blitz3D doch etwas schwiriger umzusetzen.

Außerdem würde ich gerne wissen wie du bisher 100km Leveldesign hinter dir gebracht hast. Und vor allem wie du dir 10Gm vorgestellt hast. Eine Weltumrundung am Äquator hat übrigens etwa 42Mm. Deine Levelplanung beinhaltet also die Ausmasse über 238 Weltumrundungen an Leveldesign. Mit Lichgeschwindigkeit würde man (für Außenstehende) diese Strecke erst nach etwa 33 Sekunden erreichen. Es entspricht auch etwa 12,5mal die Strecke zum Mond und zurück.

Download der Draw3D2 V.1.1 für schnelle Echtzeiteffekte über Blitz3D

	NightPhoenix	Do, Jan 08, 2009 15:36 Antworten mit Zitat
@Hectic: Was du sagtest wusste ich bereits wiedermal krittisch von dir ^^ Nungut ich muss mich mal verteidigen, weil du mich anscheinend nicht richtig verstanden hast... Ich hab nur gesagt, dass Gothic3 auch das "Welt um den Spieler bewegen"-Prinzip benutzt, anders können sie auch nicht arbeiten. Ich hab hier nie irgendwas von Levelplanung oder Objekte nachladen oder ähnlich über G3 gesagt. Es ist nicht so dass ich ein RPG programmiere wo jeder Meter mit Objekten ausgefüllt ist. Meine Objektdichte ist anhand des Faktes, dass es ein Spaceshooter ist relativ gering (vielleicht so alle 100km ein Objekt, alle 50000 km ein Planet - die sind nicht real groß) Ich stelle mir 10Gm nicht vor, sie sind integriert. Mit dem Schiff in mehreren Sekunden tatsächlich an die simulierte Koordinate z=1000000000 zu fliegen ist also möglich. (Bei mir bewegt sich die Welt auch um das Schiff drumherum, sind also nicht die realen Koord.) Ich fülle diese Stellen nicht aus, sie sollen nur befliegbar sein. Es ist also keine Frage des Leveldesigns, nur der Handhabung Aber genau das ist es, ein gigantisches Level und es funktioniert ohne nennenswerte Geschwindigkeitsverluste

NightPhoenix

Do, Jan 08, 2009 15:36
Antworten mit Zitat

@Hectic: Was du sagtest wusste ich bereits
wiedermal krittisch von dir ^^
Nungut ich muss mich mal verteidigen, weil du mich anscheinend nicht richtig verstanden hast...
Ich hab nur gesagt, dass Gothic3 auch das "Welt um den Spieler bewegen"-Prinzip benutzt, anders können sie auch nicht arbeiten. Ich hab hier nie irgendwas von Levelplanung oder Objekte nachladen oder ähnlich über G3 gesagt.

Es ist nicht so dass ich ein RPG programmiere wo jeder Meter mit Objekten ausgefüllt ist. Meine Objektdichte ist anhand des Faktes, dass es ein Spaceshooter ist relativ gering (vielleicht so alle 100km ein Objekt, alle 50000 km ein Planet - die sind nicht real groß)
Ich stelle mir 10Gm nicht vor, sie sind integriert. Mit dem Schiff in mehreren Sekunden tatsächlich an die simulierte Koordinate z=1000000000 zu fliegen ist also möglich. (Bei mir bewegt sich die Welt auch um das Schiff drumherum, sind also nicht die realen Koord.)

Ich fülle diese Stellen nicht aus, sie sollen nur befliegbar sein. Es ist also keine Frage des Leveldesigns, nur der Handhabung Wink

Aber genau das ist es, ein gigantisches Level und es funktioniert ohne nennenswerte Geschwindigkeitsverluste

	hectic Sieger des IS Talentwettbewerb 2006	Do, Jan 08, 2009 16:02 Antworten mit Zitat
Ups, sorry, ich habe mich bei deiner Aussage ''3D Spaceshooters'' verlesen. Ich habe anscheinend dein Beitrag zu schnell gelesen und das ''Space'' übersehen. Bei einem Spaceshooter sind natürlich die Dimensionen in Ordnung. Sorry Hab ja nichts gesagt.

hectic

Sieger des IS Talentwettbewerb 2006

Do, Jan 08, 2009 16:02
Antworten mit Zitat

Ups, sorry, ich habe mich bei deiner Aussage ''3D Spaceshooters'' verlesen. Ich habe anscheinend dein Beitrag zu schnell gelesen und das ''Space'' übersehen. Bei einem Spaceshooter sind natürlich die Dimensionen in Ordnung. Sorry Embarassed

Hab ja nichts gesagt.

	Tirus	Fr, Jan 09, 2009 14:41 Antworten mit Zitat
Ich wollte noch fragen wie das dann spiele machen, in denen man 2 Kameras hat (eine zur beobachtung), wird dann alles für jedes Bild 2x verschoben?

Tirus

Fr, Jan 09, 2009 14:41
Antworten mit Zitat

Ich wollte noch fragen wie das dann spiele machen, in denen man 2 Kameras hat (eine zur beobachtung), wird dann alles für jedes Bild 2x verschoben?

	NightPhoenix	Fr, Jan 09, 2009 16:44 Antworten mit Zitat
Wie meinst du das mit den 2 kameras und einer zur Beobachtung? Sowas wie mit einer spielt man und mit der anderen Beobachtet man dann die anderen Spieler wenn man tot ist (so wie in Egoshootern?)?

NightPhoenix

Fr, Jan 09, 2009 16:44
Antworten mit Zitat

Wie meinst du das mit den 2 kameras und einer zur Beobachtung?
Sowas wie mit einer spielt man und mit der anderen Beobachtet man dann die anderen Spieler wenn man tot ist (so wie in Egoshootern?)?

	Tirus	So, Jan 11, 2009 20:12 Antworten mit Zitat
Ne, ich dachte eher sowas wie ne kleine Überwachungskamera, in einem kleinen fenster an der ecko oder so. Also eine 2te Kamera die etwas anderes beobachtet und das Bild dieser Kamera gleichzeitig auf einem kleineren Bereich auf dem Monitor angezeigt wird.

Tirus

So, Jan 11, 2009 20:12
Antworten mit Zitat

Ne, ich dachte eher sowas wie ne kleine Überwachungskamera, in einem kleinen fenster an der ecko oder so.

Also eine 2te Kamera die etwas anderes beobachtet und das Bild dieser Kamera gleichzeitig auf einem kleineren Bereich auf dem Monitor angezeigt wird.

	BtbN	So, Jan 11, 2009 21:46 Antworten mit Zitat
Da die GraKa keine Kamera kennt(die kennt nur ihre Matrix), werden immer alle objekte um die Kamera verschoben. Die B3D-Kamera ist nur eine vereinfachung. Mehrere Kameras(= Mehrere rendervorgänge) erfoerden somit auch, dass alle Objekte für die andere Kamera neu positioniert(Mit der Kamera-Matrix der zweiten Cam verrechnet) werden.

BtbN

So, Jan 11, 2009 21:46
Antworten mit Zitat

Da die GraKa keine Kamera kennt(die kennt nur ihre Matrix), werden immer alle objekte um die Kamera verschoben. Die B3D-Kamera ist nur eine vereinfachung.
Mehrere Kameras(= Mehrere rendervorgänge) erfoerden somit auch, dass alle Objekte für die andere Kamera neu positioniert(Mit der Kamera-Matrix der zweiten Cam verrechnet) werden.

Übersicht

BlitzBasic

Blitz3D

Nach Oben

BlitzBasic Portal

3D Berechnungs Bug?

Betreff: 3D Berechnungs Bug?