Hallo OpenGLer,


ich bin seit heute neu hier im Forum und habe wegen meinem Problem die Foren "Einsteiger-Fragen" und "OpenGL"
komplett durchgelesen (seit letztem Freitag am lesen gewesen!), wenn mir die Überschrift des Themas entweder passend zu meinem Problem erschien, oder wenn es einfach interessant klang.
Antworten habe ich in zwei Threads aber nur zu GL_QUADS gefunden und leider lassen sich die nicht auf andere Primitive
anwenden.
Das Wiki, sowie die Tutorials gehen bezüglich meines Problems momentan noch nicht weit genug.

Ich hatte letztes Wochenende wegen meinem Problem mal "delphic" angemailt, aber der hat wegen seinen Prüfungen momentan wenig Zeit und würde sich erst nach der Prüfungszeit darum kümmern.
Da ich bald eine Woche (seit Mittwoch) festhänge, hoffe ich, daß mir hier jemand helfen kann?

-------------------

Mein Problem ist, ich entwickle ein Spiel, bei dem gibt es einen integrierten 3D-Modeller. Der ist intern so aufgebaut, das jedes GL_Primitive (GL_TRIANGLES, GL_QUADS und GL_POLYGON) ein Objekt ist und sein eigenes Array mit den dazugehörenden Verticekoordinaten hat.

Wenn in dem Editor etwas rotiert wird, so berechne ich die Rotation immer auf die dazugehörenden Verticekoordinaten und benutze kein glRotate().

Wenn man mit der rechten Maustaste auf ein Primitive klickt, geht ein Popupmenü auf, in dem man unter anderem ein Texturfenster öffnen kann, in dem man die Textur und ihre Koordinaten ändern kann.
Zum besseren Verständnis möchte ich in diesem Fenster eine Vorschau auf das ausgewählte Primitive und seine Textur geben. Daher kopiere ich die Verticeskoordinaten des Primitives in ein neues Primitiveobjekt. Dieses muß jetzt aber noch gedreht werden, damit es auch zum Benutzer parallel ist, d.h. er kann die Oberfläche der Vorderseite des Prmitives komplett sehen (die Skalierung ist auch nötig damit es ins Fenster passt, aber dabei brauche ich keine Hilfe).

------------------

Ich bräuchte einen Algorithmus, der mir die Winkel ermittelt, um die ich das jeweilige Primitive jeweils auf der X, Y und Z-Achse drehen muß, damit seine Vorderseite (Frontface) vollständig vom Vordemmonitorsitzenden gesehen wird.

Am besten wär ein Algorithmus, der sich auf alle drei oben erwähnten Primitive anwenden läßt, aber falls ich für jedes Primitive einen eigenen brauch', dann geht das natürlich auch klar.


Kann das einer:?::cry:


Gruss
Alex

Du brauchst doch nur die Normale deines Faces invertieren und hast deinen Viewvektor. Dann ermittelst du den Mittelpunkt deines Primitives und brauchst dann nur noch deine Kameraposition setzen. Je nach dem wie weit du entfernt sein möchtest. Die Kameraposition liegt dann auf der Geraden mit dem Viewvektor als Richtungsvektor durch den Primitivenmittelpunkt.
Mit den entsprechenden Werten rufst du dann gluLookAt auf. Der Upvektor dürfte ziemlich egal sein. Hauptsache er ist senkrecht zum Viewvektor.

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Vorbildlich!

Ich stimme Magellan zu. Das sollte die Lösung sein.
Wie man die Skalierung berechnet, wurde auch schon hier im Forum ausgiebig diskutiert, da der Fragesteller etwas doof war (Ich beleidige hier nur mich selbst, keine anderer Personen )

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Danke! Hab's in einem kurzen Testprogramm mal ausprobiert. Theoretisch ist das eine Lösung, allerdings hilft mir das leider nicht.

Ich schrieb' ja, dass ich die Koordinaten der Vertices des jeweiligen Primitives ändern muß.
Eure Lösung versetzt aber nur meine Sicht aufs Primitive, die Koordinaten meiner Primitivevertices habe ich damit leider nicht geändert.
Die stehen ja in einem Array und sind hinterher immer noch die gleichen. Dürfen sie aber nicht.

Ich brauch' eine Lösung, mit der ich nur diese Verticekoordinaten ändere und das Primitive dreht sich dadurch zu mir.

Also nicht Camera ums Primitive drehen, sondern Primitive zur Camera drehen!

übers vektorkreutzprodukt und Skalarprodukt könntest du den genauen Winkel (ohne zweideutigkeit) zwischen Flächennormalen und Kamerasichtrichtung bestimmen. Übers Kreutzprodukt hättest du dann auch die Achse umd die du drehen musst. so kehmst du mit einer Drehung aus.

(Mann könnte auch mehrere Drehungen machen, indem mann erst den Winkel zur Normalen einer ebenen bestimmt dann in die Ebene dreht u.s.w. ... )

musst zur Drehung der Vektoren mal in die Geometry Unit gucken, da müsst das drinn sein. Drehen musst du natürlich um den "Schwerpunkt" des Primitives (erst schwerpunkt subtrahieren, dann drehen, dann schwerpunkt wieder addieren).

aber einfacher wäre wohl die form des 4ecks/ 3ecks/ Polygons zu bestimmen und dann diese in 2d vor die Kamera zu zeichnen:

du misst die erste Strecke des 3/4ecks und zeichnest die, misst dann die zweite Strecke und über Scalarprodukt und Kreutzprodukt den Winkel und zeichnest die zweite Strecke u.s.w. (bei polygonen geht das aber nur, wenn alle punkte in 1er Ebene sind)

um das zu skalieren müsstest du es nicht sofort Zeichnen sondern erst Schritt für Schritt in eine Array packen (mit 2d Koordinaten) und dann die Min/Max-wehrte ermiteln und das gantze entsprechend verschieben und die Größe ändern.

Is mir jetzt zu aufwändig um das alles zu programmieren

wenn du spezifische Fragen zur Mathematik hasst, kann ich da ja Seispiele geben.

Obs auch anders geht weiß ich nicht.

Hilft das?

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Oh:

du kannst auch ne rechtwinklige normierte Vektorbasis mit X Vektor = Normale des primitives nehmen (Y vektor bekommst du dann etwa über das Kreutzprodukt aus X Vektor mit einem Einheitsvektor (100 oder 010 oder 001) und den Z Vektor aus Vektorkreutzprodukt aus X und Y vektor) und die Punkte in diese Basis transformieren! Dann hast du mit den neuen Y,Z Koordinaten die gesuchten 2D Koordinaten. Die kannste dann super vor die Kamera zeichnen.

Wenn du willst könntest du vorher den Schwerpunkt des Primitives vorher abziehen und hättest das gantze gleich mittig. und wenn das dreieck trotzdem an alter stelle stehen soll kannste in hinterher wieder addieren u.s.w. alles sehr bequem denke ich.

Und: es geht auch mit n-ecken (musst nur ne mittlere Normale berechnen).



Das müsste reichen!

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

@geo:

Danke für dein zweites Posting. Ich hab' mich erst wahnsinnig darüber gefreut, weil ich den Eindruck bekam, daß du mein Problem gelöst hast.

Bei näherer Betrachtung funktioniert deine Lösung bei mir aber nur, wenn ich entweder ein Triangle um seine Y-Achse drehe, oder es um seine Z-Achse drehe. Als Einheitsvektor für das Kreuzprodukt aus X Vektor mit einem Einheitsvektor kann ich immer nur den "0, 1, 0" nehmen, die anderen gehen nicht.

Sobald ich aber das Triangle um seine X-Achse drehe oder z.B. auf zwei Achsen verdrehe, dann kommen keine passenden Y, Z
Koordinaten raus, die ein gleich großes Dreieck, wie mein Ausgangsdreieck beschreiben.

Mit welchen Drehungen hast du deinen Source denn bei dir getestet?

Vielleicht habe ich aber auch nur einen Fehler beim Verständnis deiner zweiten Antwort gemacht und es geht doch?
Ich könnte dir den Source meines Testprogramms mal posten, wenn du magst?
Ich programmiere allerdings in C++, aber das merkt man im Testprogramm kaum (ist eher C).
Könntest du damit was anfangen?

-------------

Ich hab' mir nochmal dein erstes Posting angeguckt und das was du da geschrieben hast:

Wie geht sowas, also den Winkel zur Normalen einer Ebene bestimmen und welche Ebene meinst du damit?
Das könnte ich sonst auch mal probieren, da ich mir drei Funktionen geschrieben habe, die jeweils ein glRotatef() um die drei Achsen ersetzen. Wenn ich die Einzelwinkel rausbekäme, dann würde mir das von daher auch schon helfen. Dreh' ich halt dreimal hintereinander, Hauptsache das Primitive ist wieder parallel zur Mattscheibe.

bei der zweiten Lösung müsste es immer klappen, bei der berechnung des zweiten vektors der basis ist es eigentlich egal, welchen vektor du für das kreutzprodukt nimmst, er muss sich nur vom ersten unterscheiden. wenn du 100 oder 001 nimmst, müsste die ausrichtung des 2d bildes am besten sein denke ich.

Poste doch mal den Code ich guck in mir heute abend an!

Die vorschläge ausm ersten poste sind denke ich zu aufwändig. Lohnt sich nicht.

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Puh!


@geo:

Ich habe seit mehreren Stunden versucht den Tipp mit den Längen zwischen den Vertices und deren Winkel zueinander aus Posting eins von dir umzusetzen. Merkwürdigerweise kommt bei mir für einen Winkel auf dem Monitor von 65° zwischen zwei Seiten eines Triangles immer rechnerisch 2.013...° 'raus. Keine Ahnung was das soll (Dabei hab' ich die Formeln mit denen in meinem Mathebuch von der Schule, mit einem Buch über Computerspieleentwicklung und mit einer Seite in der Wikipedia verglichen.)
Eigentlich sollte alles soweit stimmen, von den Formeln her, aber der errechnete Winkel ist und bleibt zu klein...
Ich hab' dafür extra fünf Funktionen aus der geometry.pas von "Mike Lischke" nach C umgeschrieben, aber kein Erfolg.


Nunja, jetzt zu deinem Mittagspost (hab' ich erst jetzt gesehen):
Also ich hab' mal mein Testprogramm (Quelltext) an dieses Posting unter dem Namen "SDL-Testapp.zip" angehängt.

Aus Verständnisgründen hab' ich Kommentare und Möglichkeiten für Überprüfungsausgaben mal drinnen gelassen. Dadurch
ist es etwas länger geworden (letztere sind auskommentiert und stehen so bei Bedarf zur Verfügung).


Tja, hoffe mal, du findest meinen Fehler
Ich mache jetzt erstmal Abendessen.
Bis dann...

P.S.: Gibt es eigentlich eine Info, wo steht, welche Dateiformate als Attachments hier im Forum zugelassen sind?
Ich hab' erst ".cpp" probiert, dann ".txt" und als vorletztes aus lauter Verzweiflung noch ".pas", aber erst bei ".zip"
lies das Contentmanagementsystem mit sich reden (ist jetzt auch tatsächlich gezippt!).

Als erstes solltest du unbedingt eine Geometrie Unit schreiben und Vektor sowie Basen als Typen deklarieren! Dann werde aus jeweils drei langen Zeilen eine Kurze aus der sofort ihr Sinn hervorgeht (BSP: Basis.w:=CrossProdukt(Basis.u,Basis.v) u.s.w.), außerdem kann man so die Funktionen 1 mal prüfen und ist sich sicher, dass sie immer stimmen.
So wie es jetzt ist, ist es unglaublich unübersichtlich (hab ich früher aber auch so gemacht).

Dann hab ich einen Fehler gefunden: Berechnung von a:


(X_VektorX statt X_VektorZ)

Ich gehe jetzt aber nicht alle Kreutzprodukte u.s.w. durch, sondern die werden wie gesagt schön in einer Funktion zusammengefasst (vielleicht findest du ja auch ne gute Geometrie Unit für C ansonsten geht selber schreiben und schritt für schritt Erweitern auch gut). Und schreib es als extra unit, dann kannst du es immer wieder verwenden.

Zur Verschiebung in X Richtung: Ich dachte man müsste das ganze Dreieck in den Schwerpunkt (=VektorMultipplication(VektorSumme(Punkt1,VektorSumme(Punkt2,Punkt3)),1/3)) verschieben, damit man es besser an den erwünschten Ort auf dem Bildschirm zeichnen kann.

Ansonsten ist es im Prinzip aber richtig.

Ach so: wenn du dann das Dreieck in 2D zeichnest darfst du natürlich die Perspektive nicht verdrehen! Sonder die muss in -Z Richtung gerade aus gucken und du zeichnest dann das Dreieck so, dass die Y und Z Koordinaten in X und Y Richtung gehen

Ich hoffe das hilft, viel Erfolg!

In Delphi könnt ich auch Code schreiben, aber denn müsstest du ja eh wieder formatieren, außerdem hast du das Prinzip.

Wenn der Code “schöner“ ist, guck ich ihn gerne noch mal durch, falls es dann immer noch nicht geht.

Hier mal n Beispiel aus meiner Physik Engine, wie schön kurz die Sachen werden:



Das wäre so wie du es machst denke ich mal sehr lang (und der teil ist noch harmlos )

Die Dateiformate werden irgendwo beim Hochladen angezeit (hauptsächlich Bilder und zips/ace/rar).

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

geo, du hast mir wahrlich SEHR geholfen!

Gut daß du mich auf den Fehler bei der Berechnung von "a" aufmerksam gemacht hast!!
Daraufhin habe ich die noch nicht von dir inspizierten Folgezeilen mit der Berechnung von "Det / a" nochmal alle auf Abweichungen untersucht. Und Volltreffer!!
Gleich die erste Zeile bei der Berechung von "vertexCoordinatesNew[0]" hatte am Ende einen Fehler bei:

Wie du siehst, ist der alte falsche Arrayindex "2" jetzt auskomentiert und durch den richtigen "0" ersetzt.
Der Witz waren dann Folgefehler. Ich habe natürlich die komplette Zeile per Copy & Paste fünfmal kopiert und dann zwar immer schön die fasche "2" durch die dann drangewesene Zahl ersetzt, nur wenn es natürlich die falsche Achse ist, dann bleibt die Achse auch trotz ersetzen des Index auf andere Werte weiterhin die Z- anstatt die richtige X-Achse.


Dein Rat mit dem Schreiben / Suchen von Funktionen und Typen im Stil der Geometryunit zum besseren Handling der Vectoren etc. ist natürlich vollkommen berechtigt Ich habe das bisher noch nicht gebraucht. Es stimmt, daß das Ganze schlecht zu lesen ist. Ich hab' das aus Zeitgründen gemacht, da es ja nur ein Testprogramm für genau diese eine Sache ist. Da wollte ich nicht zuviel Aufwand hineinstecken. Wenn ich das jetzt in mein Hauptprogramm integriere, dann wird das natürlich mit Funktionen und Objekten aus meiner selbstgeschrieben Gameobjektklasse umgesetzt. Das bleibt nicht so!

Daß ich beim Verschieben in den Mittelpunkt nur die X-Achse erwähnt habe war ja nur zu Testzwecken, da bei meinen Ergebnissen in dem Testprogramm bisher keine Translation in die anderen Richtungen brauchte, habe ich natürlich den Rest nicht implementiert.

Ich weiß gar nicht, wie ich mich bei dir bedanken soll!!
Dein Matherat ist für mich Goldwert
Woher weißt du die Mathematik eigentlich? Lernt man das im Leistungskurs Mathe?


Ich programmiere jetzt an meinem Programm schon über ein Jahr, aber bisher konnte ich noch alles selber lösen.
Du hast auf jeden Fall einen bei mir gut (hab' deshalb mal meine Kontaktmöglichkeit ins Profil eingetragen.)
Das war eine sehr unangenehme Woche für mich, weil ich zum ersten Mal nicht per Webseiten oder Google die nötige Hilfe fand.

Ich hätt' Lust, darüber eine Hilfe zu schreiben, damit es nicht anderen auch so ergeht, wie mir. Es gibt zwar besonders viele Plätze im Internet, wo Rotationen erwähnt werden, aber das sind halt andere Rotationsprobleme, weil irgendwie keiner, oder zu wenig einen 3D-Leveleditor koden, bei dem man es mit vorher nicht bekannten Polygonen zu tun hat und diese aus unbekannter Position in eine ganz bestimmte gedreht werden müssen.

Ich hoffe jetzt erstmal eine Weile ohne unüberwindbare Probleme weitermachen zu können.


Zum Abschluß einen ganz MEGAGROßEN DANK an dich
Alex

P.S.: Danke für den Hinweis über den Platz mit den erlaubten Dateierweiterungen! Das hab' ich natürlich übersehen,
weil der Link durch so gut wie gleiches Weiß, wie es auch der restliche Text hat und ohne unterstrichen zu sein genauso
wenig auffällt, wie auch die Mitteilung, die kommt, wenn man eine Datei mit unerlaubter Endung hochgeladen hat.
Die könnten z.B. in orange oder rot sein und in größerer Schrift, als der Rest. Soviel zum Thema usability.

_________________
"But how will I know when I have received enlightenment?" asked the novice.

"Your program will then run correctly," replied the master. [Tao]

Danke Danke Danke!

Wenn man ne Physik Engine schreiben will mit trägheitstensoren, bleibt einem nichts übrig als sich die mathematik so gut es geht anzueignen! Die gesamte Mechanik lässt sich sehr eindrucksvoll im 3D Raum mit Kreutzprodukt, Basen u.s.w. umsetzen.

Aber ich hatte auch nen sehr guten Lehrer, der mir (neben dem Matheunterricht) geholfen hat. Und die VektorInBasis Transformation hab ich in dieser form von mike lischke Meine Version war vom Zeitaufwand 4 mal so umständlich...

Im studium (1semester Physik) hauen wir gerade im Vorkurs Matrizen und so durch; Da dacht ich auch: kenn ich schon, OpenGL

Naja, würd das prgramm gern ma gucke wenn du vertig bist, habe zu begin auch nen eigenen kleinen Modeller und ne Mini Engine geschrieben, ist ne sehr gute Übung denke ich...

Meine ersten Physik Simulationen machen übrigens alles ohne funktionen und klassen, nur array und Schleifen Da is ne einfache Punktmassensimulation 2 mal so groß wie meine komplette Pysik Engine heute!

Georg.

_________________
Nothing, oh sweet nothing,
today we are doing nothing at all...
http://www.geo-progs.de

Wenn ich fertig bin, meld' ich mich. Geht klar

Interessant ist hierbei, daß du auch Physik studierst
Alle Menschen in meinem Leben, die mir Mathe bisher verständlich erklären konnten, waren Physiker.

Als ich an der Uni Statistik I & II hatte, wer unterrichtete das
Ein Physiker von der Uni in Bonn.

Wer unterichtete Mathe während meiner Ausbildung zum Staatlich geprüften Informatiker Softwaretechnologie?
Ein Physiker, der sogar seine eigene Firma hatte und das Unterrichten und Wissen weitergeben mehr "just for fun" als des Geldes wegen machte.

Jetzt du noch


Macht aber nix, wenigstens komm' ich damit weiter

_________________
"But how will I know when I have received enlightenment?" asked the novice.

"Your program will then run correctly," replied the master. [Tao]