Suchergebnisse

Hallo, ich entwickle im Moment eine GDI+ 3D-Engine. Funktioniert _relativ gut, auch Clipping et cetera wurden bereits implementiert. Der Ansatz für Clipping war folgender: I.) Prüfe ob Vertex hinter der Kamera ist ( einfache Planar-Rechnungen, á la, wenn lambda negativ ist dann ja) II.) wenn ja => ziehe von sichtbaren Vertizes eine Gerade zum unsichtbaren Vertex, bis Kollision mit Ebene. wenn kollidiert, merke neue Vertex-Position, projiziere auf Bildschirm. Es entsteht nun ein Quadrangel, ( was…

NearPlane ist auf 5.0, deswegen sieht das so komisch aus, desweiteren ist FOV PI/2 . Ansonsten: Gute Idee, schaue mir das _mal an. Edit: "Unterteile ein Trapez in zwei Dreiecke und berechne an den Eckpunkten(da wo geclippt wird) dieser neuen Dreiecke interpolierte Koordinaten über perspektivisch korrekte baryzentrische Interpolation ausgehend vom ungeclipptem Dreieck." Wie denn? Das geclippte Dreieck ist deswegen geclippt, weil eine oder zwei Vertizes außerhalb des Frustum liegen. ( andernfalls …

V4 und V5 werden bereits erfolgreich berechnet. Das Clipping ist ja kein Problem. Was ein Problem ist, ist, dass wenn ein Vertex geclippt wird, weil es hinter der Kamera ist, es nicht mehr möglich ist, seine Bildschirm-Koordinate zu bestimmen. Denn um die Bildschirm-Koordinaten eines Vertex' zu bestimmen muss sie projiziert werden, wenn sie hinter der Kamera ist, wird sie falsch projiziert. In der Tat krieg ich bei der Projektion den Z-Depth, der interessiert für das Clipping aber nicht, denn ic…

Also die Idee über baryzentrische Koordinaten funktioniert_, war auch schon zu erwarten: vb-paradise.de/index.php/Attachment/41700/ Hier wird aber eben das projizierte Dreieck bereits bearbeitet. Wenn man es vor der Projizierung macht, müsste man ja die Operation zwei mal durchführen. Kann man das vermeiden..? Die Rede ist schließlich von GDI+ Hier der Code von SetPixel: C#-Quellcode (25 Zeilen) mit C#-Quellcode (19 Zeilen) entnommen aus gamedev.stackexchange.com/a/23745/99830

Hallo, lieben Dank für deinen Ansatz! Soweit also funktioniert es folgendergestalt: Drei Vertizes ( mit Position als Vektor4 repräsentiert) werden definiert. Zuvor wurden World, View und Projektion-Matrizen multipliziert. Nun wird Position des Vertizes N mit w*v*p transformiert. Weil Position des Vertizes N nun mal eine Position ist, ist w = 1.( w=0 ist eine Richtung, soweit ich das richtig las). Nun erhalten wir den projizierten Vertex mit Komponenten Position(x,y,z,w). Jetzt wird auch häufig i…

tut mir leid, falls ich dich nerve, hat mir aber sehr weit geholfen, danke! Dann habe ich nur noch eine letzte Frage_: Bei deiner Illustration oben mit Clipping-Plane und den 5 Vertizes: Ist das nach, oder vor Multiplikation mit Projektions-Matrix? Und falls nach: Nach oder vor C#-Quellcode (3 Zeilen) ? Also gemeint ist, die Überführung in Bildschirmkoordinaten. Weil projiziert man ein Vertex, dass hinter der Kamera ist, wird falsch projiziert. Deswegen ja diese ganzen Fragen haha

Das hab ich nicht selber geschrieben, das ist die Source für [Monogame] Viewport.Project. Da wird eben world*view*projection, und dann eine gewisse Zahl berechnet, alle Komponenten durch diese dividiert und dann eben X Y Z in Bildschirmkoordinaten übersetzt: C#-Quellcode (31 Zeilen) Das "float num = source.X * matrix.M14 + source.Y * matrix.M24 + source.Z * matrix.M34 + matrix.M44;" ist meines Erachten die W Komponente! Also statt das, könnte man auch: C#-Quellcode (14 Zeilen) berechnen. Ist - z…

Du dividierst also im ganzen Prozess zwei mal durch W? Ah deswegen W' = 1/W denn, W = 1/W' also 1/(1/W) = W Gibt es da irgendwelche Papers zu? Finde nur Forum-Artikel die auch zum Teil aus Fragmenten bestehen. Hab das jetzt eigentlich auch nur intuitiv programmiert, funktioniert_ schon, ist aber eben trotzdem nicht richtig, weil mein Clipping-Algorithmus VOR der eigentlichen Projizierung stattfindet und so wichtige Informationen einfach verloren gehen. Was oben imho mir keinen Sinn macht ist fol…