Hi@All.
Ich hab das Problem das Polyvector das verwendete Sprite verzerrt, sobald die Kanten nicht parallel zueinander sind. Wieso ist das so und gibt es dafür eine Lösung ?
Kleines Beispiel bitte. POLYVECTOR arbeitet so akkurat wie alle anderen Befehle auch.
Im Prinzip habe ich das gleiche Problem wie in diesem Thread beschrieben:
Link... (http://www.glbasic.com/forum/index.php?topic=2543.msg19026#msg19026)
Meine Frage bezieht sich vor allem auf das 4. Bild, denn genau so sieht es auch bei mir aus, sobald das Sprite nicht rechteckig, sondern trapezförmig ist. Ich habe auch die Lösung von Hemlos probiert, daß man diese Fläche durch 4 Dreiecke von der Mitte zu jeweils 2 Eckpunkten, erstellt, aber das hat bei mir keine Änderung gebracht.
Naja das liegt daran, das du 2 Traingles hast mit Polyvector! Und da es KEIN 3D ist, hast du ein perspektivenproblem, da es keinen Z-Buffer gibt.
So seh ich das Problem.
Aber wieso bietet dann Polyvector die Möglichkeit der perspektivänderung, wenn der Befehl doch nicht so akurat funktioniert wie Gernot das behauptete ?
Gibt es denn eine Alternativmöglichkeit um genau sowas in 2D zu machen ? Richtiges 3D kommt für mein Projekt allerdings nicht in Frage !
Nein. Perspektivenkorrektur kann man in 2D nicht machen. Dafür gibt's 3D. Das hängt mit der orthogonalen Projektionsmatrix zusammen.
Aber Hemlos hat doch eine Lösung gepostet und Du selber sagtest, daß das der einzigste Weg sei, das Problem zu lösen ?
Andererseits funktioniert sowas in Photoshop und ähnlichen Programmen ja auch. Also wieso nicht in GLBasic ?
Wie gesagt, Du hast mit POLY 2 Triangles, wenn du jetzt die rechte Seite kleiner hast als die linke verschiebst du das rechte triangle. Nur macht die orthogonale Projektionsmatrix alles so, das es für dich als 2D sichtbar ist.
Wie das Photoshop usw macht kann ich dir leider net sagen, aber ich kenn das problem auch...
Dann ist der Befehl überflüssig, denn dann kann man damit ja auch nicht mehr machen als mit den Spritebefehlen. :(
Nein, wieso überflüssig?
Nur weil ein Befehl nicht so will, wie du dir das vorstellst, ist der noch lange nicht überflüssig!
Das ist einfach standart so, da kannst du hinschauen wo du willst...
Einzigste möglichkeit ist mit der textur zu bescheissen!
Ich meinte das in der Hinsicht, daß man mit diesem Befehl nicht mehr machen kann las mit den Spritebefehlen. Also wozu sollte er dann gut sein ?
Klar kannst du mehr machen...
- alle ecken einfärbbar
- du kannst mehrecke machen
- PNG's mit alpha komplett umfärben
- schneller als DRAWIMAGE...
Ja sorry. Da haste natürlich Recht. Aber Gernot hat ja gesagt das Hemlos Lösung die einzig richtige wäre, aber die funktioniert ja eben auch nicht.
Ja in 3D gehts schon...
da kannst ja dein "surface" drehen wie du magst
In dem Thread gings aber auch um eine 2D-Lösung. Also die 3D-befehle bringen mir bei meinem Projekt rein gar nichts bzw. will ich sie nicht anwenden.
OK, probier's mal wie Hemlos das gemacht hat mit einem Triangle Fan (mode = 0 ?? )
(http://www.glbasic.com/pix/tncenter_pt_polyvector.png.png) (http://www.glbasic.com/pix/center_pt_polyvector.png.png)
Wie gesagt hab ich das ja schon probiert, aber das funktioniert leider auch nicht. Es verzerrt zwar anders als bei 2 Triangles, aber eben trotzdem noch.
OK, ich nehm' mich der Sache nochmal an...
Methode 1: Quad in kleinere Teile aufteilen.
http://www.papervision3d.org/demos/LinearMapping/ (http://www.papervision3d.org/demos/LinearMapping/)
Methode 2: Shader ( :puke: )
Methode 3: Kapier ich net
http://forums.tigsource.com/index.php?topic=2541.0 (http://forums.tigsource.com/index.php?topic=2541.0)
Dann bleibt dir wohl nur methode 1
Wahrscheinlich wirds wohl so kommen.
@Kitty Hello
Wäre es denn möglich den Befehl POLYVECTOR zu erweitern, so daß man die Anzahl der Triangle/Quads angeben kann ? Das zu bewerkstelligen dürfte eigentlich kein großes Problem sein und ich fände es sehr nützlich und somit sinnvoll.
ist doch sinnlos, da du eh jede Ecke selber erstellen musst mit Polyvector
Mach dir einfach ne Funktion, dann sollte alles klappen
Wieso ist ein Befehl der ein Quad, mit einer vom User einstellbaren Anzahl an Unterteilungen, erstellt sinnlos ?
Weil du es speziel nur für diesen Fall brauchst...
Da GLB nicht in sinnlosen Befehlen untergehen will/wird(Das war in einen anderen Thread so in etwar Gernot's Meinung), bleibt dir einfach nur eine eigene Funktion...
Ist ja jetzt nicht so die Welt an Aufwand sich da selber ne Lösung zu schreiben ;)
Kann dir gerne helfen.
Mir solch eine Funktion zu schreiben ist absolut kein Problem und das werde ich auch machen. :)
Allerdings finde ich sowas trotzdem nicht sinnlos, weil es eben nicht nur mich betrifft, sondern jeden der diesen Befehl benutzt und die Ecken so angeben will das kein Quadrat oder Rechteck entsteht. Es gibt ja bei Polyvector die Möglichkeit die Koordinaten der Eckpunkte anzugeben und wenn man diese Möglichkeit nutzt und dann sieht das die 'Textur' verzerrt wird, dürfte jedem klar werden, daß dieser Befehl noch nicht ganz ausgereift ist, da er einen Fehler produziert. Und genau deswegen halte ich es für sinnvoll das auszubessern.
Ich muss da Trabant 500 Recht geben. Wenn man Polyvector nutzt, wird man kein Rechteck zeichnen wollen und wenn die Möglichkeit besteht, eine Textur auf das Polygon zu legen, macht es demzufolge keinen Sinn, wenn es dann zu solchen Fehldarstellungen kommt. Allerdings würde ich nichts von einstellbaren Unterteilungen halten, sondern die Funktion Polyvector sollte das von Anfang an sauber darstellen können. Warum sollte GLBasic daran untergehen? Verstehe ich auch nicht...
Wenn ein Polygon jedoch nicht genau 4 Ecken hat, dann wäre zumindest für mich klar, dass sich eine Textur dann nicht sinnvoll an die Geometrie angepasst drauflegen lässt...
Ihr versteht das wohl nicht ganz...
Der Befehl POLYVECTOR arbeitet absolut sauber!
Das ist bei OpenGL wie bei DX das gleiche...
Es wird einfach nunmal so dargestellt, jede interne Änderung hat Auswirkungen auf andere Apps, die das wohl nicht so haben wollen!
Jetzt mal Butter bei de Fische... Ich habe, seit ich hier bin, nur 2x von diesen Problem gelesen.
So dsa ich denke wenn es stört, soll sich einfach mehrere Punkte zeichnen und so glücklich werden... :giveup:
Buuuhuuhuu :'(
Ok, dann ist das eine Sache, die man einfach mal so akzeptieren muss =D
...achja, dann kann ich mir ja mal bei der Gelegenheit zur spaßigen Herausforderung machen, mir einen Algorithmus zu schreiben, der das richtig darstellen kann. Mal sehen, wie sau langsam das dann wird ;)
Also ich kann Dir da nicht zustimmen Schranz0r. Ich kann mir nicht vorstellen, daß irgendjemand ein unkontrollierbar verzerrtes Sprite haben will. :D
Warten wir mal ab was Gernot dazu meint.
Quote from: Trabant 500 on 2010-Jun-20
Also ich kann Dir da nicht zustimmen Schranz0r
Es ist so... was gibts da zum zustimmen oder nicht?!
Das ist wie gesagt in OpenGL wie DX gleich
Darum geht es doch gar nicht, sondern um eine GLBasic-interne Funktion diesen Fehler zu beheben !
Es ist doch aber kein Fehler.... :blink:
Es ist natürlich kein Fehler von GLBasic, aber dennoch ist es ein Anzeigefehler. Und diesen könnte man ja beheben.
Vielleicht äußert sich Gernot ja mal dazu !? :whistle:
Man müsste halt die softwaretechnischen Hintergründe kennen und verstehen, um nachvollziehen zu können, warum es zu einer solchen Darstellung kommt. Wenn ich z. B. "orthogonale Projektionsmatrix" lese, kann ich damit herzlich wenig anfangen. Auch danach zu googlen macht mir nicht verständlicher, was da mathematisch passiert.
Vermutlich ist es eine Funktion des OpenGL-Treibers, die nunmal aus diversen Gründen so und nicht anders arbeitet. Modifizieren ist nicht, wie Schranz0r schon meinte. Deshalb müsste GLBasic das wirklich einfach umgehen und einen eigenen, in Assembler geschriebenen Algorithmus verwenden. Aber klar, wer hat schon Bock, sich diesen Krampf anzutun...
Genau das S.O.P.M !
Es ist auch kein Anzeigefehler Trabant 500, es ist einfach so, es muss ja einen Grund geben, wieso das bei OpenGL und DX gleich ist! Die machen das ja nicht zum Spass so ;)
Wie gesagt nur weils dir so nicht passt, wirds keiner abändern...
Ist kein Fehler und bleigt deshalb so wie's ist. Deine "Vorstellung" ist nur anders, als der Treiber arbeitet. Der Treiber interpoliert die Pixel linear, und das ist gut so (wenn man ROTOZOOMSPRITE mit POLYVECTOR macht muss das so sein). Wenn man jetzt aber 3D machen will mit 2D Befehlen, mus sman halt eine "Tiefe" einbauen.
Die Pixel werden jetzt nicht mehr linear interpoliert, sondern exponentiell. Darum muss man eben mit bestimmter feinhait das Netz unterteilen um den Effekt zu erhalten.
Kannst Du so eine Funktion für Deine Zwecke machen, oder muss ich das bauen?
@Kitty Hello
So eine Funktion stellt für mich kein Problem dar. Nur mal schauen wie schnell die dann sein wird. Wenn es von vornherein in Assembler wäre (wovon ich keine Ahnung habe), wäre es mit Sicherheit schneller und das fände mit Sicherheit nicht nur ich eine tolle Ergänzung. =D
Im Prinzip weiß ich schon was Du meinst, aber wieso gibt es dann bei diesem Befehl die Möglichkeit ein Nicht-Rechteck zu erstellen, wenn es doch dann verzerrt aussieht ? :blink:
der POLYVECTOR übergibt die Vektoren so wie gegeben an die Grafikkarte. Und die verzerrt das Bild linear. Du willst aber exponential, und diese Information weiß die Karte nicht. Das kann man nicht Pauschalisieren, das ist von Viereck zu Viereck verschieden. Oder ein fünfeck - das weißt Du, weil Dein Gehirn auf einmal ein 3D Objekt "sieht" und dann weiß welche Kante wie skaliert werden muss. Der PC kann das nicht wissen.
Wenn Du's in GLBasic vernünftig machst, wird's so schnell sein als wenn ich's intern mache. GLBasic ist kompiliert.