Modellklasse mit c++ und OpenGL - Blender Exporter Script und Model-Viewer

[Isodrink]

Ok, aber was ist, wenn das Modell irgendwas besonderes können muss, z.B. wenn sich einzelne Teile auf so zu sagen Kommando bewegen sollen?

[Kuldren]

Isodrink schrieb:

Ok, aber was ist, wenn das Modell irgendwas besonderes können muss, z.B. wenn sich einzelne Teile auf so zu sagen Kommando bewegen sollen?

Dann erstellst du eben dafür eine Klasse die alles von der Modelklasse erbt nur eben auf die besonderen Eigenschaften eingeht.

Allerdings klingt das ganze eher so als solltest du dich eher mal mit der grundlegenden Logik und dem Aufbau auseinandersetzen

[Isodrink]

Kuldren schrieb:

Dann erstellst du eben dafür eine Klasse die alles von der Modelklasse erbt nur eben auf die besonderen Eigenschaften eingeht.

Ist ja gut, ich gebe mich geschlagen
Ich fange dann mal an, was in der Richtung zu basteln und poste dann das Ergebnis hier.

Kuldren schrieb:

Allerdings klingt das ganze eher so als solltest du dich eher mal mit der grundlegenden Logik und dem Aufbau auseinandersetzen

Von was? Programmieren allgemein, Klassen, OpenGL, 3D Grafik, c++......

[Kuldren]

Isodrink schrieb:

Kuldren schrieb:

Allerdings klingt das ganze eher so als solltest du dich eher mal mit der grundlegenden Logik und dem Aufbau auseinandersetzen

Von was? Programmieren allgemein, Klassen, OpenGL, 3D Grafik, c++......

Wenn du mit einem Spiel (also z.b. ein Towerdefensegame) anfängst solltest du dich mit der Sprache (hier wohl c++), OOP und OGL bzw D3D (letzere zumindest zum Teil) auskennen!

Was ich aber gemeint habe war der prinzipielle Aufbau deines Spiels.
Einfach losprogrammieren endet meist in einem Wirrwarr an Code. Wenn du jetzt viel Arbeit in eine bestimmte Klasse steckst und dann im Nachhinein draufkommst, dass die Klasse total überflüssig ist weil die Daten in einer Anderen besser gekapselt wären, wirst du dich nur unnötig ärgern.
Du musst ja keine Spezifikation schreiben aber die Grundstruktur sollte klar ersichtlich sein.

Willst du denn nun ein TowerDefenseGame programmieren? oder etwas anders? je nach dem solltest du bei einem anderen Punkt anfangen. Direkt mit dem Darstellen der Gegner anzufangen finde ich eher schlecht.

[Kóyaánasqatsi]

Von was? Programmieren allgemein, Klassen, OpenGL, 3D Grafik, c++......

OpenGL, 3D-Grafik und C++.

[Isodrink]

Nun ja, vielleicht ist es gar nicht schlecht mal ein kleines Spiel zu schreiben, um richtig in die Materie rein zu finden,
ich finde Tower-defence nicht schlecht, aber ist das für den Anfang nicht ein wenig schwierig?
Du kannst mir das sicher beantworten, ich hab grad gesehen das du ja eine sehr schöne Variante programmiert hast

[Kuldren]

Isodrink schrieb:

Nun ja, vielleicht ist es gar nicht schlecht mal ein kleines Spiel zu schreiben, um richtig in die Materie rein zu finden,
ich finde Tower-defence nicht schlecht, aber ist das für den Anfang nicht ein wenig schwierig?
Du kannst mir das sicher beantworten, ich hab grad gesehen das du ja eine sehr schöne Variante programmiert hast

Ich würde lieber mit was kleinerem anfangen.
Tetris, 4 Gewinnt, ein paddle game (weiß nicht genau wie die dinger heißen).
Oder prinzipiell mal ausprobieren wie man einfache Dreiecke, Würfel und dgl. darstellt und texturieren kann

[Isodrink]

So, Ich habe mir jetzt mal etwas (hoffe ich) simples vorgenommen:
Ich möchte ein Programm schreiben, mit dem man mit der Maus ein Modell drehen kann (wie bei Blender auch) also quasi eine 360° Ansicht. Ich habe schon ein oder zwei Experimente gemacht, aber irgendwie bekomme ich nicht heraus, wie Die Mathematik da hinter aussieht denn:
1. Muss man die Kamera um das Objekt herumdrehen und
2. Hat man ja nur x und y Koordinaten, kann also nur um 2 Achsen drehen, aber das sieht irgendwie stokelich aus.

Mit dem Blender Exporter Skript bin ich schon weiter, der exportiert jetzt die Daten in ein XML ähnliches Format, ich weiß aber nicht ob das Format Sinn macht (siehe Beispiel, Modell war eine Plane)
Ein Weiterer Punkt mit dem ich mich noch einmal beschäftigen muss ist, dass das Blender Koordinatensystem nicht das selbe ist wie in OpenGL......
Andere Modelldaten werden noch mit einbezogen werden (Material.......)
Schauts euch mal an, ich bin schon auf Kritik gefasst

Beispiel:

<object>
	<name>
	Plane
	</name>
	<vertex>
		<location_x>
		1.000000
		</location_x>
		<location_y>
		1.000000
		</location_y>
		<location_z>
		0.000000
		<location_z>
	</vertex>
	<vertex>
		<location_x>
		-1.000000
		</location_x>
		<location_y>
		1.000000
		</location_y>
		<location_z>
		0.000000
		<location_z>
	</vertex>
	<vertex>
		<location_x>
		-1.000000
		</location_x>
		<location_y>
		-1.000000
		</location_y>
		<location_z>
		0.000000
		<location_z>
	</vertex>
	<vertex>
		<location_x>
		1.000000
		</location_x>
		<location_y>
		-1.000000
		</location_y>
		<location_z>
		0.000000
		<location_z>
	</vertex>
</object>

[hellihjb]

mit der Maus ein Modell drehen kann

google: acrball

<vertex>
        <location_x>
        1.000000
        </location_x>
        <location_y>
        1.000000
        </location_y>
        <location_z>
        0.000000
        </location_z>
    </vertex>

nichts gegen xml oder ascii, aber ich halte es nicht fuer sinnvoll, mindestens 25 byte informationsoverhead fuer jede zahl zu speichern dessen inhalt sich auch aus dem kontext ergibt.

[ip]

Isodrink: Vielleicht solltest du dir einfach eine Dokumentation eines gängigen Dateiformates für Meshes besorgen und eine Import Routine für deine Software schreiben.

Grüße,
Daniel

[Isodrink]

hellihjb schrieb:

google: acrball

Danke das ist genau das was ich haben wollte
Nur leider ist es ziemlich kompliziert Naja ich hab einen Codebrocken gefunden den ich verwenden kann/darf, so kann ich mir das also erstmal sparen.

hellihjb schrieb:

nichts gegen xml oder ascii, aber ich halte es nicht fuer sinnvoll, mindestens 25 byte informationsoverhead fuer jede zahl zu speichern dessen inhalt sich auch aus dem kontext ergibt.

Recht hast du, ich hab mal noch ein wenig an meinem Skript gearbeitet, sind "nur noch" 46 byte auf 3 Koordinaten(werde ich noch einmal überarbeiten....):

<object>
	<name>Plane</name>
	<vertex>
		<location>1.000000; 1.000000; 0.000000;<location>
	</vertex>
	<vertex>
		<location>-1.000000; 1.000000; 0.000000;<location>
	</vertex>
	<vertex>
		<location>-1.000000; -1.000000; 0.000000;<location>
	</vertex>
	<vertex>
		<location>1.000000; -1.000000; 0.000000;<location>
	</vertex>
</object>

Ich muss es noch hinbekommen, das Mesh in Dreiecke zu wandeln, bevor ich es exportiere......dann werde ich auch die Formatierung noch ändern.....

ip schrieb:

Isodrink: Vielleicht solltest du dir einfach eine Dokumentation eines gängigen Dateiformates für Meshes besorgen und eine Import Routine für deine Software schreiben.

Ja, das habe ich auch versucht, aber das scheiterte daran, das ich kein geeignetes Format gefunden habe, für das es bei Blender ein Exporterskript gibt.......

[hellihjb]

Ob das fuer 3D-Daten besonders sinnvoll ist sei mal dahingestellt aber XML bietet durchaus mehr Funktionalitaet als nur Tags um Text zu setzen:

<vertex xyz="1,5,7" uv="1.0,0.5" col="FF8080"/>

Eigentlich sehe ich aber nur zwei Gruende fuer ein Exportplugin:
- Die Daten sollen so aufbereitet werden, dass sie vom Renderer moeglichst effizient verarbeitet werden koennen (und das soll nicht zur Laufzeit passieren)
- Die Daten sollen moeglichst platzeffizient abgelegt werden

Beides scheint mir bei Deinem Ansatz nicht gegeben. Welchen Vorteil siehst Du denn zu bestehenden Formaten?

[Isodrink]

hellihjb schrieb:

Ob das fuer 3D-Daten besonders sinnvoll ist sei mal dahingestellt aber XML bietet durchaus mehr Funktionalitaet als nur Tags um Text zu setzen:

<vertex xyz="1,5,7" uv="1.0,0.5" col="FF8080"/>

Ja, ist natürlich richtig.........muss ich noch dran arbeiten.

hellihjb schrieb:

Eigentlich sehe ich aber nur zwei Gruende fuer ein Exportplugin:
- Die Daten sollen so aufbereitet werden, dass sie vom Renderer moeglichst effizient verarbeitet werden koennen (und das soll nicht zur Laufzeit passieren)
- Die Daten sollen moeglichst platzeffizient abgelegt werden

Beides scheint mir bei Deinem Ansatz nicht gegeben. Welchen Vorteil siehst Du denn zu bestehenden Formaten?

1. Ich versuche ja gerade das Format dahingehend zu ändern.
2. Blender benutzt nicht nur Faces mit 3 sondern auch mit 4 Verts, was man dann wieder umschreiben muss
3. Viele Faces "teilen" sich Verts mit anderen, das wird bei den meisten Exportern nicht beachtet.
4. Das Koordinatensystem ist anders, auch das wird bei den meisten Exportern nicht Beachtet.
5. Die meisten Exporter exportieren die Daten für ein anderes Programm, setzen also völlig andere Schwerpunkte als ich sie benötige
6. Wenn ich etwas brauche was nicht in dem Exporter vorhanden ist muss ich ihn editieren. und es ist ein großer Unterschied ob man seinen eigenen Quellcode editiert oder den von jemand anderem.
7. ich lerne dadurch nebenbei ein wenig Python und erweitere meine Kenntnisse mit blender
8. Ich kann mein eigenes gui schreiben und den User entscheiden lassen was und wie er bestimmte Eigenschaften exportiert.

[ip]

Isodrink schrieb:

2. Blender benutzt nicht nur Faces mit 3 sondern auch mit 4 Verts, was man dann wieder umschreiben muss

Wenn du deine Engine nicht dahingehend ändern möchtest, dass sie auch Polygone mit 4 oder mehr Vertices zeichnen kann, dann ist die einfachste Methode alle 4-Kanten Polygone entlang zweier gegenüberliegenden Vertices zu spalten. Das erhöht lediglich die Anzhal der Polygone, nicht der Vertices.

3. Viele Faces "teilen" sich Verts mit anderen, das wird bei den meisten Exportern nicht beachtet.

Ich habe erst vor kurzem für meine eigene Software einen 3ds Import-Algorithmus geschrieben und zumindest 3ds legt eine Vertextabelle an, welcher durch die Polygontabelle Referenziert wird - dh keine doppelten Vertices.

4. Das Koordinatensystem ist anders, auch das wird bei den meisten Exportern nicht Beachtet.

Das ist wohl richtig, aber idR mit einer einfachen Rotation gefolgt von einer Translation zu lösen.

5. Die meisten Exporter exportieren die Daten für ein anderes Programm, setzen also völlig andere Schwerpunkte als ich sie benötige

Die meisten Dateiformate sind so strukturiert, dass du Daten, welche dich nicht interessieren überspringen kannst. Ich möchte wieder das Beispiel 3ds heranziehen, wo ich zB Textur bzw Materialdaten einfach überspringe, da ich sie nicht benötige.

6. Wenn ich etwas brauche was nicht in dem Exporter vorhanden ist muss ich ihn editieren. und es ist ein großer Unterschied ob man seinen eigenen Quellcode editiert oder den von jemand anderem.

Wähle einfach das richtige Format in dem alles vorhanden ist, was du brauchst (Texture, Lightning, Skelettal Animation, etc)

Grüße,
Daniel

[Isodrink]

ip schrieb:

Isodrink schrieb:

2. Blender benutzt nicht nur Faces mit 3 sondern auch mit 4 Verts, was man dann wieder umschreiben muss

Wenn du deine Engine nicht dahingehend ändern möchtest, dass sie auch Polygone mit 4 oder mehr Vertices zeichnen kann, dann ist die einfachste Methode alle 4-Kanten Polygone entlang zweier gegenüberliegenden Vertices zu spalten. Das erhöht lediglich die Anzhal der Polygone, nicht der Vertices.

also wenn ich nicht gerade GL_TRIANGLE_STRIP verwenden will, was wohl schwer wird, sind das 2 Verts mehr

ip schrieb:

3. Viele Faces "teilen" sich Verts mit anderen, das wird bei den meisten Exportern nicht beachtet.

Ich habe erst vor kurzem für meine eigene Software einen 3ds Import-Algorithmus geschrieben und zumindest 3ds legt eine Vertextabelle an, welcher durch die Polygontabelle Referenziert wird - dh keine doppelten Vertices.

Is wohl richtig. Aber es ist nunmal so das Blender für einen Würfel 8 Verts benutzt und Opengl 24 dafür braucht......

ip schrieb:

4. Das Koordinatensystem ist anders, auch das wird bei den meisten Exportern nicht Beachtet.

Das ist wohl richtig, aber idR mit einer einfachen Rotation gefolgt von einer Translation zu lösen.

Jup, muss mir mal anschauen wie ich genau rotieren muss...

ip schrieb:

5. Die meisten Exporter exportieren die Daten für ein anderes Programm, setzen also völlig andere Schwerpunkte als ich sie benötige

Die meisten Dateiformate sind so strukturiert, dass du Daten, welche dich nicht interessieren überspringen kannst. Ich möchte wieder das Beispiel 3ds heranziehen, wo ich zB Textur bzw Materialdaten einfach überspringe, da ich sie nicht benötige.

6. Wenn ich etwas brauche was nicht in dem Exporter vorhanden ist muss ich ihn editieren. und es ist ein großer Unterschied ob man seinen eigenen Quellcode editiert oder den von jemand anderem.

Wähle einfach das richtige Format in dem alles vorhanden ist, was du brauchst (Texture, Lightning, Skelettal Animation, etc)

Also zunächst möchte ich erstmal nur das Mesh exportieren, keine ganze Szene. aber schon da fehlt es an einem geeigneten Exportskript. Wenn ich mich irre Schande über mein Haupt
Du musst auch beachten das Blender freie Software ist, wenn es dort keinen gibt der ein für OpenGL geeignetes Skript schreiben will, dann gibts halt keins, dafür ist die Python API sehr gut

Was haben eigentlich alle dagegen, das ich ein Exportskript selber schreibe?

Grüße,
Iso

[hellihjb]

[...] aber schon da fehlt es an einem geeigneten Exportskript.
Du musst auch beachten das Blender freie Software ist, wenn es dort keinen gibt der ein für OpenGL geeignetes Skript schreiben will, dann gibts halt keins

Du muesstest evtl mal auf File->Export klicken:
3ds, Obj, Vrml, Collada, ...
Alle nicht "fuer OpenGL geeignet" ?

Quads sind trivial in zwei Dreiecke zu zerlegen, andersrum machts schon etwas Muehe. Koennte vielleicht irgendwann mal nuetzlich sein...

[rapso]

hellihjb schrieb:

Welchen Vorteil siehst Du denn zu bestehenden Formaten?

exporter schreiben eigentlich nie in ein effizientes finales format, exporter generieren metadaten, diese sollten leicht verstaendlich, unmodifiziert (also ohne optimierungen und komplression) und langlebig sein.
erst ein resource compiler (oder auch die engine wenn's sein muss), konvertieren diese daten in ein gewuenschtest format.

es gibt viele vorteile, deshalb macht es jede halbwegs organisierte spielefirma so.
1. bei formatwechseln, muss man nicht alles neu exportieren. (und das ist selbst automatisiert aufwendiger als ein resourcecompiler, falls die automatisierung nach allen wuenschen klappt).
2. keine (bzw kaum) versions (kompatibilitaets) probleme, es muessen nicht alle auf einmal umstellen, jeder kann sich code und daten seperat besorgen, weil anhand der metadaten jede version die gewuenschten daten erzeugen koennen. das erlaubt auch sanfteres einfuehren und testen von neuen dingen, weil kaum jemand alles lokal testen kann sobald projekten/firmen etwas groesser werden.
3. flexibles arbeiten, weil optimierungen simpel gemacht werden koennen, da die metadaten noch alle informationen haben.
4. es gibt kein endianess wirrwarr, es ist klar lesbarer text, und pro attribute zu sagen dass es x y z ist, ebenfalls nuetzlich, fuer den fall das es eben nicht xyz, weil man die daten aus verschiedenen programmen exportiert die das 'offensichtliche' anders sehen.
5. ein resourcecompiler erlaubt es die daten pro plattform zu uebersetzen, es waere irgendwie seltsam das pro plattform einmal zu exportieren. es ist sicher gleich langsam, wenn man es von einem anderen plattformformat zu dem eigenen konvertieren muss (oder es reicht auch ne 'alte version'). metadaten haben das problem nicht unmengen an cross-convert-code zu halten.
6. man kann metadaten einfuegen die nichts mit den daten an sich zu tun haben, z.b. hints fuer qualitaet, streaming, autor, rechner, compression, etc.

und dann kann man auch sehen, dass es eigentlich kein argument gegen ein xml format fuer metadaten gibt.
1. groesse? es sind metadaten fuer die produktion, es jukt wohl kaum jemanden wie gross die sind. die werden nicht in versionskontrollen eingecheckt (man kann sie ja schliesslich mit den eingecheckten exportern und quelldaten immer wieder erzeugen).

2.geschwindigkeit? es dauert nicht wirklich laenger die zu laden (weil sich hoffentlich jeder coder mal std::map<filename,crc32> als cache basteln kann fuer sein system) und man fuer sein workingset sicher nur einen bruchteil konviertiert.
fuer den fall der faelle dass man alles braucht, hat der nightly build hoffentlich die ganzen convertierten daten bereithaellt.

3.eigentlich sollte das ziel in der entwicklung sein, dass man moeglichst jederzeit arbeiten kann (also nicht dass man sich GB an neuen daten ziehen muss, weil jemand etwas an formaten aendert) und man sollte sehr flexibel bleiben (also nicht bei jedem formatwechsel die erdkugel kurz anhalten weil es so einen riesen impact hat und man das entsprechend selten macht).

fuer finale daten sollte man das natuerlich nicht mehr nutzen. esseiden es macht einem wirklich nichts aus z.b. weil man ein sharewar spiel macht, das klein ist und trotz xml meshes gezippt 5MB hat oder so.

btw. (falls jemand bis hierher ueberhaupt gelesen hat:P) man muss das rad nicht neu erfinden, collada ist schon so ein xml format (auf das immer mehr firmen aufspringen). es sollte fuer so ziemlich jeden 3dmodeller einen exporter geben.