3D-Grafik JOGL Grafiken in 3DS Max importieren

[Kamil]

Hey Leute,

ich bin neu hier im Forum und hab gleich mal eine Frage an Euch. Ich studiere Visuelle Kommunikation
an der UdK in Berlin, bin also kein ausgebildeter Programmierer. Für ein aktuelles Projekt programmiere ich momentan unter Eclipse mit der processing Core (Processing.org) und JOGL, weil ich 3D Modelle erstelle. Soweit funktioniert auch alles wie gedacht. Jetzt wäre es allerdings nötig, dass ich die erstellen 3D Modele (Quads etc.) exportiere, um sie mit einem Grafikprogramm wie 3DS Max zu bearbeiten. Es gibt ein Haufen Libraries um *.obj oder *.3ds mit JOGL/OpenGL zu laden, aber nicht andersrum. Zumindest bin ich bislang nicht fündig geworden. Für processing gibt es eine Library, die auch soweit ganz gut funktioniert hat. ich möchte aber nicht die internen Processing Funktionen (beginShape()... vertex().... endShape()) benutzen, sondern direkt mit JOGL arbeiten, da hier die Performance schneller ist.

Irgendwelche Hinweise für mich? Wäre super nett!
Kamil

 

[Kamil]

P.S.: Wenn meine Anfrage verwirrt, gerne nachfragen. Ich bin wie gesagt nur Hobby-Programmierer und mit den Fachausdrücken nicht vertraut. (noch nicht)

 

[Marco13]

Ein paar beispiel-codezeilen wie du im Moment die "Modelle erstellst" wären hilfreich - da kann ich mir nichts drunter vorstellen. Oder meinst du wirklich die Aufrufe

beginShape();
vertex(1,2,3);
vertex(5,2,3);
vertex(1,9,3);

vertex(1,2,3);
....
// Viele, viele Dreiecke, die dann ein Modell ergeben...
...

endShape();

???:L

 

[AlexSpritze]

Also du hast mit Processing 3D-Modelle erzeugt und die werden mit JOGL angezeigt? Dieses Modelle möchtest du dann exportieren, so dass du sie in 3DS öffnen kannst?
Dann wäre es gut zu sehen, wie du die 3D-Modelle erzeugt hast. Also ein wenig Java-Code davon.

 

[Kamil]

Hey, danke für Eure Hilfe!

Ich habe bislang immer direkt mit der Software von Processing gearbeitet. Bin jetzt aber auf Eclipse umgestiegen. Das funktioniert ganz einfach, man bindet die Processing Core ein und ansonsten ändert sich für mich Laien nichts.

import processing.core.*;

Auch in Processing kann man die OpenGL Library einbinden, die aber von der Performance her ziemlich schwächelt, jedenfalls kann man dann mit folgendem Code Vertecies zeichnen:

size(100, 100, OPENGL);
beginShape(POINTS);
vertex(30, 20, -50);
vertex(85, 20, -50);
vertex(85, 75, -50);
vertex(30, 75, -50);
endShape();

Das funktioniert alles super. Sowohl unter Processing als auch direkt unter Eclipse. (Nur extrem langsam) Unter Processing kann ich desweiteren mit der folgenden Library alles was mit beginShape() und endShape() erzeugt wird in einer *.obj Datei speichern, die ich dann mit 3DS Max öffnen kann. superCAD

Unter Eclipse und nach Einbindung der JOGL Library baue ich meine Vertecies hingegen folgendermassen, also im Grunde "direkt" mit JOGL was Processing ja im wahrscheinlich hinter seinem framework auch tut:

PGraphicsOpenGL pgl = (PGraphicsOpenGL) g;  
GL gl = pgl.beginGL(); 

       gl.glBegin(GL.GL_QUADS);
          gl.glVertex3f(   0, 0,80);
          gl.glVertex3f( 450, 0,80); 
          gl.glVertex3f( 450, 450,80); 
          gl.glVertex3f(00, 450,80); 
       gl.glEnd();

pgl.endGL();

Auch das funktioniert alles unter Eclipse super und läuft extrem schnell (42 fps statt 5 fps unter Processing). Einziges Problem: Die supercad-Library funktioniert jetzt nicht mehr, da sie nur auf beginShape() etc. reagiert. (Schätze ich.) Ich suche nun also eine andere Möglichkeit/Library, um meine Vertecies später in 3Ds Max zu importieren. Ich kann mir nicht vorstellen, dass es sowas nicht gibt.

 

[Marco13]

Kann schon sein, dass es sowas nicht gibt - was dieses "superCAD" da macht ist... schon... "ungewöhnlich" - sowas habe ich zumindest noch nicht für andere Sprachen gesehen.

Mal nebenbei: Das mit

size(100, 100, OPENGL);
beginShape(POINTS);
vertex(30, 20, -50);
vertex(85, 20, -50);
vertex(85, 75, -50);
vertex(30, 75, -50);
endShape();

ist 20x langsamer als OpenGL, OBWOHL dort OpenGL als Backend verwendet wird? Das sollte eigentlich doch nicht sein, oder?

Man könnte sicher relativ(!) leicht einen Wrapper für die Klasse "GL" schreiben, die die Aufrufe an eine Datei weiterleitet, aber ... irgendwie ist mir nicht klar, warum man Processing verwendet, wenn man dann eigentlich DOCH OpenGL verwendet... also, OHNE GL-Backend würde der Code ja mit einer ClassCastException abkacheln...?

 

[Kamil]

Hey, also bei großen Anzahlen von Vertecies wird es schon deutlich langsamer als unter "Eclipse" mit den JOGL Funktionen. Ich zitiere auch mal kurz aus dem Processing Forum:

There are no additional methods or fields for this library. It uses the Processing language, but renders geometry differently. Processing is not an IDE for using the JOGL API. We're using OpenGL graphics for one implementation of the Processing Core API.

Dann schreiben sie über die Möglichkeit, dass man OpenGL direkt ansprechen kann, aber das nicht wirklich ausgereift ist:

f you want to write code for Java and JOGL, then find yourself a good Java IDE and get JOGL installed, Processing is probably not the way to do it because that's the kind of confusing mess we're trying to insulate you from.

Code Beispiel:

import javax.media.opengl.*;
import processing.opengl.*;
	
float a; 
	
void setup() {
  size(800, 600, OPENGL);
}
	
void draw() {
  background(255);
  
  PGraphicsOpenGL pgl = (PGraphicsOpenGL) g;  // g may change
  GL gl = pgl.beginGL();  // always use the GL object returned by beginGL
  
  // Do some things with gl.xxx functions here.
  // For example, the program above is translated into:
  gl.glColor4f(0.7, 0.7, 0.7, 0.8);
  gl.glTranslatef(width/2, height/2, 0);
  gl.glRotatef(a, 1, 0, 0);
  gl.glRotatef(a*2, 0, 1, 0);
  gl.glRectf(-200, -200, 200, 200);
  gl.glRotatef(90, 1, 0, 0);
  gl.glRectf(-200, -200, 200, 200);
  
  pgl.endGL();
	  
  a += 0.5;
}

Also es ist möglich und beschleunigt auch meine Processing Sketche, aber ist teilweise noch ziemlich buggy. Ja, im Grunde ist das irgendwie ein ziemliches Mischmasch. Ich benutze die Processing Core im Grunde, weil ich mich damit auskenne und es ja bislang auch alles super funktioniert. Ziel ist es natürlich irgendwann mit reinem Java und OpenGL zu programmieren.

Tja, was superCAD da macht weiß ich als Laie sowieso nicht. Wrapper schreiben bedeutet mir die Dateien selbst zusammenbaun? Sprich erstmal analysieren wie so eine 3ds / obj / stl Datei aufgebaut ist? STL-Schnittstelle ? Wikipedia

Und was genau ist mit

OHNE GL-Backend würde der Code ja mit einer ClassCastException abkacheln...?

gemeint?

Danke Dir!

 

[Kamil]

Ahh, das scheint zu klappen. Ich habe jetzt manuelle eine *.stl Datei erzeugt mit einem Dreieck. Aufbau einer STL Datei:

STL Format

Und als Hilfe vllt:

STL mit VPython/

Dir konnte ein Freund von mir problemlos in Rhino (CAD Software) importieren. Ich sollte jetzt also in der Lage sein eine stl-Datei selbst zu erzeugen. Mal schauen, wie weit ich komme!

Danke!

 

[Marco13]

Das "Abkacheln" bezog sich darauf, dass bei
PGraphicsOpenGL pgl = (PGraphicsOpenGL) g;
ein Fehler auftritt, wenn NICHT OpenGL im Hintergrund verwendet wird.

Mit "Wrapper" war in diesem Fall gemeint, dass man theoretisch die Aufrufe "mitschreiben" könnte. Wenn man sowas hat wie

GL gl = pgl.beginGL(); 
 
gl.glBegin(GL.GL_QUADS);
gl.glVertex3f(   0, 0,80);
gl.glVertex3f( 450, 0,80); 
gl.glVertex3f( 450, 450,80); 
gl.glVertex3f(00, 450,80); 
gl.glEnd();

Dann könnte man sich theoretisch eine Klasse machen

class WritingGL extends (oder implements) GL
{
    private GL theRealGL;

    public void glVertex3f(float x, float y, float z)
    {
        theRealGL.glVertex3f(x,y,z);
        schreibeInDatei(x,y,z);
    }
 

    // Hier ggf. ALLE Methoden aus "GL" ... können viele sein...
}

Dass man also um das "echte" GL-Objekt ein anderes drumrumwickelt, das die gleichen Methoden anbietet (und diese Methoden werden auch an das "echte" GL weitergeleitet), aber die Methoden schreiben zusätzlich noch die Daten in eine Datei.

Das ist ein bißchen tricky, man sollte schon wissen, was man da tut... Aber wenn man das "richtig" machen würde, könnte man den oben angedeuteten Code ggf. durch

GL gl = pgl.beginGL(); 
gl = new WritingGL(gl, "output.obj");  // <<<--- diese eine Zeile
gl.glBegin(GL.GL_QUADS);
...

erweitern könnte, und (ohne irgendeine weitere Änderung des eigentlichen Codes!) die Daten dann rausgeschrieben werden würden. Aber nochmal: Das kann ein bißchen tricky sein - schließlich wird die Methode ggf. 50 mal pro Sekunde aufgerufen, und man kann (und will) nicht 50 mal die OBJ-Datei schreiben

 

[Kamil]

Genau! Ich danke Dir vielmals. Ich nutze deine Tipps jetzt um mich da reinzufuchsen und melde mich sobald ich irgendwo hänge!

 

[Kamil]

Jetzt ist etwas seltsames passiert, noch bevor ich wirklich weiterkam. Da alles wie gehabt gut lief, wollte ich meine Verticies doch erstmal mit den Processing Funktionen ausgeben. Um diese erstmal mit der superCAD Library zu exportieren. (Wollte Sie schon mal einem Kollegen schicken.) Doch nachdem einfügen der wenigen Funktionen...

beginRaw("superCAD.exportFormat", "outputPath.ext"); [...] endRaw();

... werden auf einmal meine Arrays falsch angezeigt. (Komischerweise hatte ich diesen Fehler schonmal.) Zum Verständnis: Ich habe eine txt-Datei in der pro Zeile ein Wert gespeichert ist. Dieser liegt zwischen 0 und 250. Mit den folgenden beiden Funktionen wird der Array ausgelesen und angezeigt. Man sah die Form eines Oberkörpers. (Ganz normal senkrecht stehend.)

public void readTxtToFace2D() {
		System.out.println("readTxtToFace - Setup gestartet"); // Meldung
		String line;
		for (int x = 0; x < numberOfFaces; x++) {
			reader = createReader("txt/" + x + ".txt");
			int count = 0;
			try {
				while ((line = reader.readLine()) != null) {
					// do something with each line:
					face2D[x].faceDots[count] = Float.valueOf(line);
					count++;
				}
				System.out.println("       face2D[" + x + "].faceDots[" + count
						+ "]"); // Meldung
			} catch (IOException e) {
				e.printStackTrace();
			}
			count = 0;
		}
		System.out.println("readTxtToFace - Setup beendet"); // Meldung
	}

	public void showFace2D(int face, int res) {
		for (int x = 0; x < w; x += res) {
			for (int y = 0; y < h; y += res) {
				int offset = y*w + x;
				stroke(face2D[face].faceDots[offset]);
				point(x, y);
			}
		}
	}

Das funktionierte wie gesagt alles super. Mit offset = y*w + x; wurde jeder Pixel aus der richtigen Stelle im Array ausgelesen und angezeigt. Nun jedoch... obwohl meine txt-Dateien nicht verändert worden sind und sich meine Funktion auch nicht geändert hat (ich habe wie gesagt nur superCAD eingebunden (und gleich wieder entbunden)) scheint es als hätte sich aus irgendeinem Grund die Reihenfolge geändert im Array. (Was laut den txt-Dateien nicht der Fall ist.) Auf dem Bildschirm erscheint eine verzerrte Ansicht meines Arrays. Ich habe herausgefunden, dass das ganze mit

offset = y + x * h

wieder gerade gerückt werden kann. NUR das kann doch nicht sein? Meine TXT ist unverändert, meine Funktionen auch! Ich habe sämtliche benutzten Libraries nochmal neu importiert etc. Der Fehler bleibt. Wie ist das Möglich? Das Probleme hatte ich schonmal, als meine Werte in meiner TXT bereits von einem anderen Java-Programm in der falschen Reihenfolge gespeichert worden sind. Daraufhin hatte ich das korrigiert. :/ ???:L

Ergänzung: Ich konnte meine TXT-Dateien wiederherstellen (alte Backups.) Habe daraufhin nochmal versucht herauszufinden was schief gelaufen ist. Folgende Situation: Projekt in Eclipse ist offen. Im data/txt Ordner liegen meine txt-Dateien. Alles wird richtig angezeigt beim Programmstart. Ich füge die superCAD Library hinzu (add library). Sie erscheint im Package Explorer. Ohne sie irgendwie weiter einzubinden in mein Projekt starte ich mein programm erneut. -> Arrays werden wieder verzerrt angezeigt. Worauf wirkt sich denn der Import der superCad aus?