Wieso verzerrt Polyvector das verwendete Sprite ?

[Kitty Hello]

OK, probier's mal wie Hemlos das gemacht hat mit einem Triangle Fan (mode = 0 ?? )

[Trabant 500]

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.

[Kitty Hello]

OK, ich nehm' mich der Sache nochmal an...

Methode 1: Quad in kleinere Teile aufteilen.
http://www.papervision3d.org/demos/LinearMapping/

Methode 2: Shader ( )

Methode 3: Kapier ich net
http://forums.tigsource.com/index.php?topic=2541.0

[Schranz0r]

Dann bleibt dir wohl nur methode 1

[Trabant 500]

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.

[Schranz0r]

ist doch sinnlos, da du eh jede Ecke selber erstellen musst mit Polyvector

Mach dir einfach ne Funktion, dann sollte alles klappen

[Trabant 500]

Wieso ist ein Befehl der ein Quad, mit einer vom User einstellbaren Anzahl an Unterteilungen, erstellt sinnlos ?

[Schranz0r]

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.

[Trabant 500]

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.

[S.O.P.M.]

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...

[Schranz0r]

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... 

[S.O.P.M.]

Buuuhuuhuu
Ok, dann ist das eine Sache, die man einfach mal so akzeptieren muss

...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

[Trabant 500]

Also ich kann Dir da nicht zustimmen Schranz0r. Ich kann mir nicht vorstellen, daß irgendjemand ein unkontrollierbar verzerrtes Sprite haben will. 
Warten wir mal ab was Gernot dazu meint.

[Schranz0r]

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

[Trabant 500]

Darum geht es doch gar nicht, sondern um eine GLBasic-interne Funktion diesen Fehler zu beheben !