Alternative zu GLM
-
Kellerautomat schrieb:
aber was vollkommen anderes machen als ich dachte.
Wie wäre es mit Dokumentation lesen?
-
oenone schrieb:
Wie wäre es mit Dokumentation lesen?
Jo, bei sowas hier
if(v.length() != 0.f) v = glm::normalize(v);schau ich ganz bestimmt in der Dokumentation nach, ob v.length() tatsaechlich die *laenge* des Vektors ist und nicht die Anzahl der Komponenten.
(Tipp: Es ist nicht das, was man erwarten wuerde)
-
Kellerautomat schrieb:
(Tipp: Es ist nicht das, was man erwarten wuerde)
Nach einem Blick in die Doku ist es genau das, was ich erwarten würde. Eventuell liegt das Problem bei dir.
-
Heißt du würdest erwarten dass v.length() und length(v) etwas anderes machen? Interessant.
-
cooky451 schrieb:
Heißt du würdest erwarten dass v.length() und length(v) etwas anderes machen? Interessant.
In der Doku ist genau beschrieben, dass .length() die Anzahl Elemente zurückliefert.
Dass die geometrischen Funktionen wie in der Doku beschrieben keine Methoden sind ist schade, aber auch deutlich genug hervorgehoben. Außerdem zieht sich das konsistent durch.
-
oenone schrieb:
cooky451 schrieb:
Heißt du würdest erwarten dass v.length() und length(v) etwas anderes machen? Interessant.
In der Doku ist genau beschrieben, dass .length() die Anzahl Elemente zurückliefert.
Dass die geometrischen Funktionen wie in der Doku beschrieben keine Methoden sind ist schade, aber auch deutlich genug hervorgehoben. Außerdem zieht sich das konsistent durch.
Du hast absolut nicht verstanden worum es hier geht.
-
-
Kellerautomat schrieb:
Ich suche eine brauchbare alternative zu GLM.
GLM zielt ja darauf ab, möglichst nahe bei GLSL zu sein, und geht dadurch teilweise Kompromisse ein. Brauchst du denn dieses Feature? Ansonsten wäre vielleicht einfach eine der Linear-Algebra-Bibliotheken für C++ eine Alternative.
oenone schrieb:
Nach einem Blick in die Doku ist es genau das, was ich erwarten würde. Eventuell liegt das Problem bei dir.
Nein, liegt es nicht. Ausdrucksstärke der Schnittstellen ist ein Qualitätsmerkmal.
Gut designte APIs benötigen nur minimales Nachschlagen in der Dokumentation -- umso mehr, da es sich bei einer Vektorbibliothek grösstenteils um bekannte Operationen ohne grosse Komplexität dahinter handelt.
-
Nexus schrieb:
oenone schrieb:
Nach einem Blick in die Doku ist es genau das, was ich erwarten würde. Eventuell liegt das Problem bei dir.
Nein, liegt es nicht. Ausdrucksstärke der Schnittstellen ist ein Qualitätsmerkmal.
Gut designte APIs benötigen nur minimales Nachschlagen in der Dokumentation -- umso mehr, da es sich bei einer Vektorbibliothek grösstenteils um bekannte Operationen ohne grosse Komplexität dahinter handelt.
wie du schon selbst sagst, zielt GLM darauf ab glsl abzubilden. entsprechend ist sie ohne doku zu lesen verstaendlich wenn jemand glsl kann. ich wuerde entsprechend nichtmal dran denken dass .length existiert, geschweige denn dass es wie length(...) funktioniert.
von daher wuerde ich nicht die lib blamen, sie ist fuer graphics/3d coder gemacht die sich mit glsl auskennen, entsprechend macht der thread starter das einzig richtige, sich eine lib zu suchen die zu seinen anforderungen passt. das macht aber GLM nicht automatisch schlecht, sie macht das wofuer die lib entwickelt wird.
-
rapso schrieb:
wie du schon selbst sagst, zielt GLM darauf ab glsl abzubilden. entsprechend ist sie ohne doku zu lesen verstaendlich wenn jemand glsl kann. ich wuerde entsprechend nichtmal dran denken dass .length existiert, geschweige denn dass es wie length(...) funktioniert.
Das Problem ist, dass .length() gar nicht existieren bzw. eher .components() oder .size() heissen sollte. Dass glm::length() eine freie Funktion ist, ist schon schoen und gut so.
-
Kellerautomat schrieb:
rapso schrieb:
wie du schon selbst sagst, zielt GLM darauf ab glsl abzubilden. entsprechend ist sie ohne doku zu lesen verstaendlich wenn jemand glsl kann. ich wuerde entsprechend nichtmal dran denken dass .length existiert, geschweige denn dass es wie length(...) funktioniert.
Das Problem ist, dass .length() gar nicht existieren bzw. eher .components() oder .size() heissen sollte.
klingt als wuerde deine meinung da nicht mit der meinung der lib ersteller uebereinstimmen.
ich haette gesagt dass es ueberhaupt keine memberfunctions geben sollte wenn es glsl spiegelt.
mathematiker wuerden vielleicht sagen dass das einzig richtige .dimension waere.
java coder wuerden vielleicht sagen 'length' stimmt schon.
low level hardware coder wuerden vielleicht sagen 'size' ist die groesse in bytes und waere irrefuehrend.
etc.
code phillosophie. deswegen ist es gut wenn der threadstarter sich was anderes sucht, weise entscheidung. hier fuer oder gegen GLM zu protestieren bringt nicht viel, die lib wird von vielen benutzt die sie moegen, niemand muss sie nutzen der sie nicht mag (ist ja SEHR optional, ich z.B. hab sie noch nie benutzt).
-
rapso schrieb:
ich haette gesagt dass es ueberhaupt keine memberfunctions geben sollte wenn es glsl spiegelt.
Es gibt in GLSL aber eine .length() Methode...
-
dot schrieb:
rapso schrieb:
ich haette gesagt dass es ueberhaupt keine memberfunctions geben sollte wenn es glsl spiegelt.
Es gibt in GLSL aber eine .length() Methode...
holly cow, du hast recht, wann kam das denn rein?
von daher, noch weniger grund etwas an GLM auszusetzen.
-
rapso schrieb:
dot schrieb:
rapso schrieb:
ich haette gesagt dass es ueberhaupt keine memberfunctions geben sollte wenn es glsl spiegelt.
Es gibt in GLSL aber eine .length() Methode...
holly cow, du hast recht, wann kam das denn rein?
Gibt's schon seit einiger Zeit (iirc seit 3.30). Ich war damals mindestens genau so schockiert wie du...
