JOGL - glTranslate - Unterschiede bei zweimal Ausführen

[Guest]

Folgender JOGL Code:

gl.glColor4f(1.f, 1.f, 1.f, 1.f);
		glut.glutWireCube(1.0f);
		
		double sum = 10000;
				
		for( int i = 0; i < sum; i++){
			gl.glTranslated(1.0, 0.0, 0.0);
		}
		
		gl.glTranslated(-sum, 0.0, 0.0);

		gl.glColor4f(0.f, 0.f, 1.f, 1.f);		
		glut.glutWireCube(1.0f);

Warum sind die Cubes nicht deckungsgleich? Der zweite Würfel liegt nicht auf dem Ersten,
sondern nebendrann.
Wo ist der Unterschied zwischen Translate X und xmal Translate?
Vermutlich findet irgendwo eine Verzerrung der Werte statt.
Setzt man "sum" hoch, wird der Fehler größer. Und irgendwie ist der Effekt abhängig vom Viewport.
Ändert man den, ändert sich auch der Fehler.

Weiß da jemand was?

-- -- muckelzwerg

 

[muckelzwerg]

*grrrr* Das ist jetzt das zweite Mal, dass ich nach dem Login nich angemeldet bin.
Wird da gerade geschraubt?

 

[Fancy]

Moin,

die im Rechner verwendeten Gleitkomazahlen haben nur eine endliche Genauigkeit. Und ohne jetzt nachsehen zu wollen, sind alle mir bekannten OpenGL Implementierungen float optimiert. D.h. selbst wenn Du Deinen Treiber mit den double Werten zumüllst, intern werden, zumindest alle Matrixoperationen, als float durchgeführt.

Solange Du dein glTranslate ausschließlich auf die Einheitsmatrix los läst, kommt es zu keinerlei Rundungsfehler. D.h. wenn Du Dir mühe gibst, kann es sogar sein, das Du Deine Würfel deckungsgleich bekommst. Sobald aber einmal irgendwas Ungerades auf die Matrix angewendet wurde, ist erstmal Essig.

Praktisch kommt so ein Fall mit 10000x glTranslate hoffentlich nicht vor.

Als kurzer Test um den Rundungsfehler im Verhältnis zwischen OpenGL und JAVA bestimmen zu können:

package fancy.jf.error;

import java.awt.Frame;
import java.awt.event.WindowAdapter;
import java.awt.event.WindowEvent;

import javax.media.opengl.GL;
import javax.media.opengl.GLAutoDrawable;
import javax.media.opengl.GLCanvas;
import javax.media.opengl.GLEventListener;

public class FloatError implements GLEventListener {

    private GL           gl   = null;

    private final double sum  = 10000;
    private final float  mv[] = new float[16];


    @Override
    public void init(GLAutoDrawable drawable) {

        gl = drawable.getGL();
        gl.glMatrixMode(GL.GL_MODELVIEW);

        
        // --- rounding error orthogonal (java) -------------------------------
        javaLoadIdentity();

        for (int i = 0; i < sum; i++) {
            javaTranslate(1.0f, 0.0f, 0.0f);
        }

        javaTranslate((float) -sum, 0f, 0f);

        System.out.println("rounding error orthogonal (java)    : " + mv[3]);
        // --------------------------------------------------------------------

        
        // --- rounding error non orthogonal (java) ---------------------------
        javaLoadIdentity();

        javaRotate(22.2f, 0f, 1f, 0f);

        for (int i = 0; i < sum; i++) {
            javaTranslate(1.0f, 0.0f, 0.0f);
        }

        javaTranslate((float) -sum, 0f, 0f);

        System.out.println("rounding error non orthogonal (java): " + mv[3]);
        // --------------------------------------------------------------------

        
        // --- rounding error orthogonal (gl) ---------------------------------
        gl.glLoadIdentity();

        for (int i = 0; i < sum; i++) {
            gl.glTranslated(1.0, 0.0, 0.0);
        }

        gl.glTranslated(-sum, 0, 0);

        gl.glGetFloatv(GL.GL_MODELVIEW_MATRIX, mv, 0);
        System.out.println("rounding error orthogonal (gl)      : " + mv[12]);
        // --------------------------------------------------------------------

        
        // --- rounding error non orthogonal (gl) -----------------------------
        gl.glLoadIdentity();

        gl.glRotated(22.2, 0, 1, 0);

        for (int i = 0; i < sum; i++) {
            gl.glTranslated(1.0, 0.0, 0.0);
        }

        gl.glTranslated(-sum, 0, 0);

        gl.glGetFloatv(GL.GL_MODELVIEW_MATRIX, mv, 0);
        System.out.println("rounding error non orthogonal (gl)  : " + mv[12]);
        // --------------------------------------------------------------------

    }


    private void javaLoadIdentity() {
        for (int i = 0; i < 16; i++)
            mv[i] = 0;
        for (int i = 0; i < 4; i++)
            mv[i * 5] = 1.0f;
    }


    public void javaTranslate(float x, float y, float z) {
        mv[3]  = mv[0] * x + mv[1] * y + mv[2] * z + mv[3];
        mv[7]  = mv[4] * x + mv[5] * y + mv[6] * z + mv[7];
        mv[11] = mv[8] * x + mv[9] * y + mv[10] * z + mv[11];
        mv[15] = mv[12] * x + mv[13] * y + mv[14] * z + mv[15];
    }


    public void javaRotate(float angle, float x, float y, float z) {

        float[] mvt = new float[16];

        float v = (float) Math.sqrt((x * x) + (y * y) + (z * z));

        x = x / v;
        y = y / v;
        z = z / v;

        float r = (float) Math.toRadians(angle);
        float c = (float) Math.cos(r);
        float s = (float) Math.sin(r);

        float[] t = new float[9];

        t[0] = x * x * (1 - c) + c;
        t[1] = x * y * (1 - c) - z * s;
        t[2] = x * z * (1 - c) + y * s;
        t[3] = y * x * (1 - c) + z * s;
        t[4] = y * y * (1 - c) + c;
        t[5] = y * z * (1 - c) - x * s;
        t[6] = x * z * (1 - c) - y * s;
        t[7] = y * z * (1 - c) + x * s;
        t[8] = z * z * (1 - c) + c;

        mvt[0]  = mv[0] * t[0] + mv[1] * t[3] + mv[2] * t[6];
        mvt[1]  = mv[0] * t[1] + mv[1] * t[4] + mv[2] * t[7];
        mvt[2]  = mv[0] * t[2] + mv[1] * t[5] + mv[2] * t[8];
        mvt[3]  = mv[3];
        mvt[4]  = mv[4] * t[0] + mv[5] * t[3] + mv[6] * t[6];
        mvt[5]  = mv[4] * t[1] + mv[5] * t[4] + mv[6] * t[7];
        mvt[6]  = mv[4] * t[2] + mv[5] * t[5] + mv[6] * t[8];
        mvt[7]  = mv[7];
        mvt[8]  = mv[8] * t[0] + mv[9] * t[3] + mv[10] * t[6];
        mvt[9]  = mv[8] * t[1] + mv[9] * t[4] + mv[10] * t[7];
        mvt[10] = mv[8] * t[2] + mv[9] * t[5] + mv[10] * t[8];
        mvt[11] = mv[11];
        mvt[12] = mv[12] * t[0] + mv[13] * t[3] + mv[14] * t[6];
        mvt[13] = mv[12] * t[1] + mv[13] * t[4] + mv[14] * t[7];
        mvt[14] = mv[12] * t[2] + mv[13] * t[5] + mv[14] * t[8];
        mvt[15] = mv[15];

        for (int i = 0; i < 16; i++)
            mv[i] = (float) (mvt[i]);
    }


    @Override
    public void display(GLAutoDrawable drawable) {}


    @Override
    public void reshape(GLAutoDrawable drawable, int x, int y, int width, int height) {}


    @Override
    public void displayChanged(GLAutoDrawable drawable, boolean modeChanged, boolean deviceChanged) {}


    public static void main(String[] args) {

        final FloatError main = new FloatError();
        final Frame frame = new Frame();
        final GLCanvas canvas = new GLCanvas();
        canvas.addGLEventListener(main);
        frame.add(canvas);
        frame.setSize(50, 50);
        frame.addWindowListener(new WindowAdapter() {
            @Override
            public void windowClosing(WindowEvent e) {
                new Thread(new Runnable() {
                    public void run() {
                        System.exit(0);
                    }
                }).start();
            }
        });
        frame.setVisible(true);
    }

}

Liefert die zu erwartenden Werte:

rounding error orthogonal (java)    : 0.0
rounding error non orthogonal (java): -0.6738281
rounding error orthogonal (gl)      : 0.0
rounding error non orthogonal (gl)  : -0.6738281

Übrigens selbst wenn Du die obige JAVA Implementierung vollständig auf double änderst, verschwindet der Fehler nicht! (Auch wenn er um Größenordnungen kleiner wird.)

Gruß,
Michael

 

[muckelzwerg]

Die Doubles waren mein zweiter Test, der Fehler ist bei Floats gleichgroß.
Allerdings lässt sich "1.0" doch exakt darstellen, oder nicht?
In meinem Testprogramm findet absolut nichts anderes statt.
Matrizen zurücksetzen und dann die beiden Translates.
Da ist nichts Ungerades etc. Das entspricht sozusagen Deinem "orthogonalen Fehler",
und der ist bei Dir null, in meinem Beispiel nicht.
Hätte ich vorher Operationen mit nichtdiskreten Werten gehabt, wärs ja klar.
Zudem ist der Fehler direkt abhängig von der Viewportauflösung,
ich tippe da eher auf ein Umrechungsproblem, dass sich dann vervielfacht.

Also nochmal, es reicht völlig aus in einer "frischen Szene" 10000mal mit 1.0 (entlang einer Achse) zu translieren,
und danach 1mal mit 10000 in die Gegenrichtung. Zeichnet man vor und nach der Translation das gleiche Objekt, ist es nicht kongruent.
Erhöht man die Entfernung, steigt auch der Fehler.
Verändert man den Viewport, "springt" das zweite Objekt um das erste herum.

Das sollte eigentlich weder an nichtdiskreten Floats noch an unaufgeräumten Matrizen liegen.

-- -- muckelzwerg

 

[muckelzwerg]

Folgende neue Erkenntnisse:

Ich habe nochmal Deinen Ansatz untersucht. In einer sauberen Szene müsste doch die Kameratransformation das
Einzige sein, was die Matrizen mit unsauberen Werten belegt.
Ich habe verschiedene Scrollfunktionen getestet, also die Kamera hin und her geschoben,
der Fehler bleibt dabei konstant.
Jetzt war mein Gedanke, dass der Fehler ja nur auftreten sollte, wenn durch Rotation der Szene/Kamera nichtdiskrete Werte auftreten.
Also habe ich die Kamera auf 0/0/0 ausgerichtet und ihre Position entlang aller drei Achsen verschoben.
Bei Verschiebung entlang der Y-Achse wird der Translationsfehler (X-Achse) nicht beeinflusst.
Spricht für Deine Aussagen. Bei Verschiebung entlang der anderen Achsen wird der Fehler beeinflusst
und der 2. Würfel fängt an zu springen. (Kamera bleibt immer auf 0/0/0 ausgerichtet, sorgt dann also für die Rotation )
Spricht auch für deine Aussagen.
Jetzt stellt sich aber die Frage, wo der Fehler herkommt, wenn die Kamera nicht rotiert sondern nur verschoben wird.
Ein einfaches Translate 0/0/-2, also "rauszoomen nach hinten" reicht aus um die Würfel auseinanderzubringen.
Das sollte aber keine indiskreten Floatwerte in der Matrix erzeugen.
Und nach wie vor ist auch da der Fehler direkt abhängig vom Viewport.
Ich habe auch bisher keinerlei Translation finden können, bei der der Fehler nicht irgendwann auftritt.
Und zumindest mal die Zweierpotenzen sind in IEEE745 diskret darstellbar.

-- -- muckelzwerg

 

[muckelzwerg]

So, gibt wieder ein kleines Update.
Es sind keine Floatingpointfehler oder andere Verzerrungen dieser Art. Hab grad enige interessante Dinge getestet, will aber keine halbgaren Infos verbreiten.
Nur damit sich in der Richtung niemand mehr den Kopf zerbricht:
Es liegt nicht daran, dass ich vorher "die Matrizen mit nichtdiskreten Werten versaut" habe.
Ich bin noch am recherchieren, und kann hoffentlich bald mehr dazu sagen.

mfG

-- -- muckelzwerg

 

[Evil-Devil]

Die Frage die sich mir gerade stellt, was genau willst du eigentlich darstellen?
1000 Würfel nebeneinander oder ineinander?

Bei letzteren würde ich einfach mit glPopMatrix/glPushMatrix arbeiten. Dann sparst du dir das ständige zurücksetzen via glTranslate.

 

[muckelzwerg]

Da wird eine dynamische Tabelle gezeichnet.
Die Würfel sind zwar letztlich irgendwelche Modelle in den VBOs aber prinzipiell "ja, 100 Würfel nebeneinander".
PushMatrix und PopMatrix ändern am Problem nichts, und erhöhen in dem Fall leider nur die Komplexität.
Denn dann muss ich nach jeden "Würfel" dessen Transformation rückgängig machen. Wenn ich aber nach jedem einzelnen Translationsschritt einen Würfel zeichen und dann an den Tabellenanfang mit einem großen Schritt zurückgehe, entfällt dieser Aufwand. (ist hier ironischerweise also genau andersrum)
Prinzipiell ist das aber auch ein völlig akzeptabler Weg. Es gibt keinen Grund warum 10000mal translate mit 1.0 nicht den gleichen Effekt hat wie einmal translate mit 10000.
Wie gesagt, es liegt weder an Floatfehlern noch an JOGL oder Java.
Hab den gleichen Effekt in C++ "erfolgreich" getestet, und inzwischen auch Konfigurationen gefunden mit denen dieser Codeschnippsel problemlos funktioniert.
(Ich blick nur noch nicht tief genug durch um da jetzt schon groß was zu erzählen.)

-- -- muckelzwerg

 

[Marco13]

Hm. Kann's grad nicht testen, aber wenn man sowas macht wie

float sum = 0;
for (int i=0; i<1000; i++) sum += 0.1f;
sum -= 100;

wird "sum" am Ende sicher nicht 0 sein.
Das "Rückgängig machen" der Transformation durch Verschieben in die Gegenrichtung ist einfach kein geeigneter Ansatz. Die finale Matrix, die verwendet wird, um das Objekt im 3D-Raum zu platzieren (bevor es geclippt und in 2D plattgedrückt wird) besteht ja aus der MODELVIEW und der PROJECTION Matrix. Die Matrizen beschreiben sozusagen den Weg vom Ursprung zum "Zielpunkt" (d.h. dem "betrachteten Punkt"), (MODELVIEW) und den Weg vom Auge zum Zielpunkt (PROJECTION). D.h. am Ende werden die beiden Matrizen miteinander multipliziert, und dabei kann (bei so großen bzw. unterschiedlich großen) Zahlen eben Mist rauskommen.

 

[muckelzwerg]

Ich habe es ja mehrfach getestet. Und sum ist definitiv 0, wenn ich das Beispiel so aufstricke, wie Du es beschrieben hast.
zwei glTransaltes mit exakt gegesätzlichen Vektoren heben sich fehlerfrei auf. Zerlegt man aber einen der Vektoren in Mehrere funktioniert es nicht mehr, müsste es aber.
Wie gesagt, der Fehler tritt sowohl in Java, als auch C++ auf,
ich kann ihn aber auch "umgehen", so dass die von mir geposteten Beispiele genau so funktionieren, wie sie sollen.
Tatsächlich hat es nämlich überhaupt nichts mit Java etc. zu tun.

-- -- muckelzwerg