3D Objekte Zeichen

Robert_RS

Hallo!

Ich habe vor kurzem mit Flash MX ein erstes 3D Objekt (Würfel) erstellt. Nun habe ich für diesen Würfel immer die Eckpunkte (3D) brechnet, 2D dargestellt und dann anhand einer funktion (lineTo()) die Punkte verbunden. Genau genommen habe ich 6 Ebenen gezeichnet die zusammen die Seitenflächen eines Würfels darstellen.

Jede Ebene ist ein Objekt, welches _einen_ depth-Wert haben kann. Nun ist hiermit schwer zu arbeiten (z.B. wenn 2 Ebenen einander schneiden). Am einfachsten wäres natürlich wenn jeder Punkt ein Objekts (ürsprünglich 3D, jetzt 2D) wäre mit einem depth-Wert(= koordinate auf der z-achse *(-1)), jedoch würde das viel zu lang dauern in Flash. Vorallem wenn das Objekt auch bewegt wird.

Würde das auch mit C++ lange dauern?

Vielen Dank für Antworten
Mit freundlichen Grüßen Robert

rapso

das dauert immer lange, eigentlich ist das korrekte füllen von flächen das was heutzutage am längsten von den einzelnen arbeitsabschnitten dauert.
deswegen lässt man das eigentlich die graka machen.

aber es dürfte in c schnell genug sein um auf
-einem 486
-einem handy (Symbia)
-einem pda(ab arm100MHz)
flüssig zu laufen.

der rest ist eine frage der auflösung und des restlichen systems (z.b. speicherart, cache größe).

um da genau einzusteigen empfehle ich dir:das oder das.
das erste geht mehr auf die hintergründe ein das zweite mehr auf die fertigstellung des 'ganzen'.

ansonsten mach es, wie der rest es auch früher gemacht hat-> painter algorithmus.

rapso->greets();

Robert_RS

Hallo!

Obwohl der Großteil von dem, was ich wissen wollte, geklärt wurde, gebe es noch einige Unklarheit.

rapso schrieb:

das dauert immer lange, eigentlich ist das korrekte füllen von flächen das was heutzutage am längsten von den einzelnen arbeitsabschnitten dauert.
deswegen lässt man das eigentlich die graka machen.

Ist das so zu verstehen, dass tatsächlich jedes Pixel immer neu Berechnet wird und einen eigenen z-index hat? Denn ich würd mal denken, dass genau das der Grund ist, wieso das richtige Füllen von Flächen so lange dauert.

rapso schrieb:

Das Erste: das

Ich suche bereits seit einiger Zeit, Bücher die genau dieses Thema verständlich machen wollen, jedoch sind diese meist nicht sehr günstig vom Preis, deswegen werde ich mich noch über weitere Bücher informieren lassen. Vielen Dank für die Empfehlung.

Das zweite Buch wird noch auf sich warten lassen müssen, eben auf Grund der Kosten.

Painter Algorithmus:

Falls du meinst ich sollte das bei meinem kleinen Würfel anwenden, wäre das wenn ja, nur schwer möglich, da ich nur Fläche für Fläche zeichen kann. D.H. ich muss wissen (jetzt mal ausgeschlossen, dass sich zwei Ebenen schneiden) welche Ebene GANZ zu sehen ist. Das kann schwierig sein. Vorallem wenn manche Punkte dieser Ebene den selben z-Wert haben wie, manche Punkte der anderen. Wie gesagt jeder Punkt der Fläche hat den gleichen depth-Wert, da alle zusammen ein Objekt sind. Deswegen auch die Frage, ob man bei C++ in der Praxis für PC 3D-Spiele jedem Pixel einen eigenen Z-Index vergibt.

Vielen Dank für deine Hilfe,

freundliche Grüße
Robert

rapso

Robert_RS schrieb:

rapso schrieb:

das dauert immer lange, eigentlich ist das korrekte füllen von flächen das was heutzutage am längsten von den einzelnen arbeitsabschnitten dauert.
deswegen lässt man das eigentlich die graka machen.

Ist das so zu verstehen, dass tatsächlich jedes Pixel immer neu Berechnet wird und einen eigenen z-index hat? Denn ich würd mal denken, dass genau das der Grund ist, wieso das richtige Füllen von Flächen so lange dauert.

für jeden pixel muss man den zwert ausrechnen (das ausrechnen ist dabei das interpolieren zwischen zwei kanten), zudem macht man das mit jedem wert der pro pixel nötig ist, dazu gehören texturcoordinaten,farben,normalen,fog usw. (natürlich ist das nicht immer so, sondern applikationsabhängig)

Robert_RS schrieb:

rapso schrieb:

Das Erste: das

Ich suche bereits seit einiger Zeit, Bücher die genau dieses Thema verständlich machen wollen, jedoch sind diese meist nicht sehr günstig vom Preis, deswegen werde ich mich noch über weitere Bücher informieren lassen. Vielen Dank für die Empfehlung.

Das zweite Buch wird noch auf sich warten lassen müssen, eben auf Grund der Kosten.

an sich reicht das erste eigentlich für den einstieg. das zweite ist, wie schon gesagt, mehr darum orientiert ein spiel zu coden und nicht nur das rendern.

Robert_RS schrieb:

Painter Algorithmus:

Falls du meinst ich sollte das bei meinem kleinen Würfel anwenden, wäre das wenn ja, nur schwer möglich, da ich nur Fläche für Fläche zeichen kann. D.H. ich muss wissen (jetzt mal ausgeschlossen, dass sich zwei Ebenen schneiden) welche Ebene GANZ zu sehen ist. Das kann schwierig sein. Vorallem wenn manche Punkte dieser Ebene den selben z-Wert haben wie, manche Punkte der anderen. Wie gesagt jeder Punkt der Fläche hat den gleichen depth-Wert, da alle zusammen ein Objekt sind. Deswegen auch die Frage, ob man bei C++ in der Praxis für PC 3D-Spiele jedem Pixel einen eigenen Z-Index vergibt.

ja, bei c++ spielen setzt man in der praxis für jeden pixel (heutzutage) einen eigenen zwert (bei antialiasing sogar mehrere). doch das machen heutzutage bei fast allen spielen die graphikkarten (wenn man direct3d oder opengl verwendet).

früher war der painteralgorithmus der eigentlich meißt verwendete. dabei wird nicht pro objekt, sondern pro quad/tirangle/fläche sortiert und anschließend alles von hinten nach vorne gezeichnet.

dabei gibt es mehrere methoden das zu machen, die triviale wäre vor jedem zeichnen alle quad/triangle/flächen (nennen wir das ab jetzt mal primitive) untereinander zu sortieren (z.b. quicksort) und zu zeichnen.
eine andere möglichkeit wurde z.b. in descent verwendet, dort war die level in convexe körper aufgeteilt, sodass man einen ganzen körper zeichnen konnte ohne dass ein primitiv ein anderes verdecken könnte, die körper untereinander waren über portale verbunden und man konnte am viewerpoint durch die körper (über die portale) zum am weitesten entfernten gehen, den dann zeichnen und die rekursion eins höcher den körper zeichnen usw.
die möglichkeit die quake nutzte waren in BSP einsortierte flächen
bei nvidia auf der home ist ein beispiel mit vorindizierten flächen, je nachdem von welcher seite man sich von etwas befindet.
es gibt auch die möglichkeit sich ein pvs aufzubauen, dazu geht man an jeden möglichen ort (wobei es viele möglichkeiten für die definition 'ort' gibt, z.b. punkt in einem XxYxZ-raster) und speichert sich dort welche flächen und in welcher reichenfolge man sie sehen würde, wenn man das mal zeichnen muss, dann hat man die sortierung schonmal fertig.
es gibt noch weitere möglichkeiten, wie z.b. den s-buffer...

painteralgorithmuss heißt ja nur dass man es von hinten nach vorne zeichnet, wie man das realisiert, da gibt es unzählige wege mit vor und nachteilen.

rapso->greets();

Robert_RS

Ich meine bei dem Paitner Algorithmus, das gleiche wie du verstanden zu haben. Nur glaub ich wären es für Flash zu viele Rechnungen um richtig zu sortieren, wenn man Primitiv für Primitiv zeichnet. Weil irgendwie muss herausgefunden werden, welches Primitiv zuerst welches danach, ..., welches zuletzt gemalt werden soll.
Dadurch das ein Primitiv (hier Rechteck z.B) nicht nur einen einzigen z-wert hat.
Hier zum Beispiel müssten schon einige Berechnungen durchgeführt werden, um zu berechnen welches Rechteck zuerst zu zeichnen ist, da sie ja nicht genau hintereinander sind um es anhand des Mittelpunktes zu berechenen.

z-Achse die nach hinten in den Raum geht.
|     Fläche 1
|      /
|     /      _ Fläche 2
|    /    _-
|   /  _-
|  /
-------------- x Achse

     o o <--- Augen

Aber dadurch dass ich mich noch nie mit dem Programmieren solcher Sachen ausseinander gesetzt habe, kann es auch sein, dass ich hier etwas vollkommen misinterpretiert habe. Also falls das vollkommener Schwachsinn ist, was ich hier sage, tut es mir leid deine/eure Zeit beansprucht zu haben.

Vielen Dank für deine Hilfe! Bekam alles was ich wollte.

Freundliche Grüße Robert

rapso

klar, je besser die qualität sein soll, desto aufwendiger sind die berechnungen die man durchführen muss.

der einfachste wäre wohl die eckpunkte deiner flächen zu nehmen, ihren durchshnitts z-wert zu berechnen und anhand dessen zu sortieren, das klappte bei mir jedensfall bisher gut.

hier z.b. für eine ganzes raumschiff.

rapso->greets();

Robert_RS

Ja für den Würfel ist das wohl die einfachste Lösung.
Grüße

rapso

natürlich muss man die objekte so modelln, dass das auch klappt. aber beim modeln der objekte wenn du pro pixel einen extra z-wert berechnest ist auch einiges zu beachten, wenn es z.b. flächen gibt die zu nah aneinander liegen, reicht oft die präzision des z-buffers nicht mehr aus und es entsteht z-fighting, das heißt: in jedem neuen frame der gezeichnet wird, werden stellen mal sichtbar, mal verdeckt sein und man sieht ein flimmern.

rapso->greets();