Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich Arbeite momentan an der Umsetzung eines Papers link.
Das Problem bei Vektorgrafiken sind die quadratischen und kubischen Bezierkurven, welche üblicherweise durch Rastergrafiken oder Approximierte und Tesselierte Vektoren dargestellt werden.
Beide Lösungen sind natürlich Auflösungsabhängig, wenn man bei einer Textur näher ran geht, wird sie Pixelig/Matschig und bei der 2. Technik sieht man beim ranzoomen die einzelnen Triangle.
Die eine Variante benötigt desweiteren Texturlookups, blending und Texturspeicher, wärend die 2. nur ne menge vertexdurchsatz frisst und ein bischen Speicher für die zusätzlichen Vertice.
Es gibt allerdings auch eine weitere Lösung, welche im Paper gezeigt wird.
Dabei wird die kubische und quadratische Bezierkurve über ein Pixelshader und ein Preprozess realisiert.
Der Preprozess berechnet die Stützpunkte in Texturkoordinaten um unter eine Handvoll bestimmter Bedingungen.
So bindet man zum zeichnen einen Shader und gibt der OpenGL pipeline das normale mesh mit den berechneten texturkoordinaten und alles ist fein.
Diese Technik benötigt also wenig Speicher(vertice+texcoords) da keine Texturen oder größere tesselierungen an den Kurven passiert.
Der Shader ist sehr kurz und sehr flink.
Vertexshader:
float v=pow(gl_TexCoord[0][0],3.0)-gl_TexCoord[0][1]*gl_TexCoord[0][2]; //oder float v=-1.0*(pow(gl_TexCoord[0][0],3.0)-gl_TexCoord[0][1]*gl_TexCoord[0][2]); wegen konkav und konvex
if (v<0.0) discard;
gl_FragColor=vec4(0.0,0.0,1.0,1.0);
}
Das schlimme am ganze ist der Preprozess, da man einmal die Texturkoordinaten berechnen muss und das hats wirklich in sich, da schon in 5 verschiedene Kategorien von kubischer Bezierkurve unterschieden wird, einige noch Zerlegung von einer kubischen Bezierkurve in 2 Benötigt(damit doppelpunkte aus dem Bereich 0>n<1 auf 0 oder 1 rutschen. Man braucht einiges an Mathefunktionen und das Paper ist nicht gerade TAK2004 freundlich geschrieben -_- . Der Preprozess läuft nur einmal durch, also wenn man z.B. eine TrueType(nutzt quadratische bezierkurven) File konvertieren will oder ein svg(unterstützt beide aber Tools nutzen kubische bezierkurven), dann macht man das einmal und nutzt das darraus entstandene OpenGL kompatiblen Daten. Nicht des so trotz hab ich die Shader und den größten Teil des Codes schon umgesetzt bekommen, wie man an folgenden Screenshot sehen kann. http://karmarama.linuxprofessionals.org/upload/CubicBezier_GL.png Rot und Blau sind feste Farben, im Shader, um zu sehen ob konkave und konvexe kurven korrekt umgesetzt wurden. Die 2 Fälle, die man in 99% der Fälle vor findet habe ich bereits fertig aber die weiteren 3 kommen noch(z.B. linie=alle punkte auf einer geraden). Das ganze möchte ich dann für meine neue GUI und Schriften benutzen.
edit: Oc2k1 hat mich gerade vor dem Implementierungswahnsinn von dem AA, wie es im Paper vorgeschlagen wird bewahrt und wir haben gemeinsam ein AA per Shader eingebaut. Bild Links, blauer Teil wird mit AA Shader verarbeitet und rechts, der rote Teil, ohne. Der neue Shader ist gigantisch größer geworden xD
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich hab den Code mal ein bischen aufgeräumt und angefangen ein SVG Loader zu schreiben aber ich musste leider fest stellen, dass es wohl eines der katastrophalsten Formate ist, was ich je gesehen habe. Ein XML Format und man braucht trotzdem noch ein Parser, weil man auf die dumme Idee kam, eine weitere Struktur in den XML Tags zu verwerden, dabei denke ich an das Path->d Attribute, welche dann so fancy Werte wie "m 0,0 c 100,50 150,75 z m 85,3 l 34,12". Ich hab leider keine Zeit, mir die mühe zu machen dafür ein Loader zu schreiben, noch dazu sind alle bisher geschriebenen Loader fest in die Programme und Bibliotheken eingebettet, so das ein recyceln eines vorhandenen Codes bisher nicht möglich war. Wenn wer eine Idee hat, bzgl. Loader oder anderem Vektor Datenformat, welches Problemloser zu laden ist immer her damit.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
Es gibt nur ein SVG standard, dass ist SVG 1.1 und diese art von Datenlagerung ist in allen Versionen so.
Ich hab schon ne menge libs uns software angeguckt, die svn nutzen und es gab mal vor langer zeit eine lib die nur das interpretieren gemacht hat, wurde aber eingestellt.
Der Fall das w3c ihren validator für svg entfernt hat, weil der c code nicht ausreichend gut war sagt schon einiges über die komplexität des formates aus.
Man muss auch sagen, dass es total schlecht implementiert wurde, man bekommt das gefühl als ob wer zeit mit der notation verbracht hat und dann dazu gezwungen wurde es in xml zu pressen.
@glvg the problem is that i use c++ ^^
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
All we need are 3 points a from, a control and a to point.
The texture coords here are easy as they always are:
0,0 for the from point (first point)
0.5,0 for the control point (second point)
1,1 for the to point (third point)
(not so easy is to understand why these values work )
with the actual vertex coords we determine where and how the quadric spline is drawn.
Now on to the cubic spline (not working yet)
For this we need 4 points so drawing a triangle is not good enough, we need 2 (source: http://www.mdk.org.pl/2007/10/27/curvy-blues (he also shows of arb program shaders!))
Also we need different texture coords to match the 2 triangles. E.g. the texture coords on the to point can not be 1,1 for the first triangle.
Who dares to explain the way texture coords are calculated in plain english? Or show of a basic set of working texture coords for an basic curve like shown in svg docs: http://www.w3.org/TR/SVG11/paths.html#P ... erCommands I thought it was difficult but doable to draw a cubic spline using GL_LINES and triangulat that, but this is almosy undoable.
Also wo can shine some light on this. (i dont mind if you explain it like to a ten year old )
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2623 Wohnort: Berlin
Programmiersprache: Go, C/C++
It work only correct if you don't change the vertex koordinates else it will deliver wrong curves.
At the moment i have to write the OpenGL3 Tutorial collection, work for part-time-scientists on the high level programming for a.i., graphic algorithm, ... and also work on my engine.
If you want, i can give you my testcode because i have no time at the moment to finish the stuff.
I implemented cubic bezier curves but no quadric.
I also tried to implement line drawing and find a solution drawing lines with static and relative width.
If you want draw Lines with a width of 1-2pixel you can use the basic shader and modify it a little bit but for lines with linewidth on 30xpx and above the precision of the algorithm and a problem with the sign switch made it me impossible, so you can create the line with a second layer and build it with vertice and the basic shader.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Di Jul 01, 2003 18:59 Beiträge: 887 Wohnort: (The Netherlands)
Programmiersprache: fpc/delphi/java/c#
See PM.
Also i got the quadric curves to work, but not the cubic curves.
Have a read on my posting on the quadratic ones.
And yes the fact that my cubic one worked is only the case for the example i posted, with other vertex coords new texture coords are needed.
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.