3D Entwicklung - Welches Framework

[funcoder]

Hallo Zusammen,

ich habe bis jetzt nur Erfahrung in der 2D Entwicklung und möchte jetzt eine 3D Applikation umsetzen.
Die 2D Projekte habe ich immer "roh" mit Canvas umgesetzt ohne jegliches Framework.
Deshalb die Frage an diejenigen die bereits eine 3D App umgesetzt haben.
Welches Framework könnt ihr empfehlen?
Ganz normal bzw. nur mit Standard OpenGL oder eben auch entsprechende Module/Frameworks?
Was hat euch am besten gefallen, was könnt ihr nicht empfehlen?
Hat jemand Erfahrung mit min3D? Min3D ist mir aufgefallen, da dadurch auch 3d Models im 3DS sowie OBJ Format geladen werden können.

Bzw. 3DS ist DAS Datenformat für 3dModelle, richtig?

Bin auf dem Gebiet noch ein absoluter Anfänger und wäre daher für jeden Rat/Hinweis dankbar.

Danke!

 

[reddox]

Hi,

zuerst einmal: ich habe noch nie 3D Anwendungen für Android geschrieben, deswegen kann ich nicht sagen welche Library da besonders geeignet ist. An der Stelle hilft dir bestimmt google wenn du nach '3D engine android' oder 3d library android' suchst.

Allerdings habe ich mich vor einiger Zeit mit 3D Programmierung am PC beschäftigt (was ja nicht so anders ist), weswegen ich einige Erfahrungen mit dir teilen möchte.
Zum einem: es macht durchaus eine Menge Spass - und man lernt auch sehr viel dabei, wenn man seine 3D Library selber schreibt, bzw direkt auf OpenGL programmiert (oder wie es in meinem Fall war auf DirectX). Nun kommt es allerdings auf das Projekt selbst an, ob es denn nicht sinnvoll ist eine fertige Library, denn wenn es in Richtung Optimierung geht kann es sehr langwierig sein, eine Performance zu erreichen, die an eine fertige Library herankommt.

Bei der Auswahl der Library würde ich auf 3 Punkte achten: Anwendungsbereich, Community und Interface

Zuerst zum Anwendungsbereich: Ich habe gemerkt, dass sich (für den PC) einige Engines, die ausschliesslich für 1st/3rd Person Spiele eignen, wenn man nun ein RTS oder ähnliches aus Vogelperspektive erreichen will geht das auch, aber es ist umständlich. Ich denke das kann bei Android auch passieren. Es gibt natürlich auch Libraries, die gut universell nutzbar sind - hier ist zu beobachten, dass man etwas mehr Arbeit hat um eine 1st Person Perspektive einzurichten, aber dieser Aufwand hält sich in Grenzen. Wenn man auf lange Sicht immer mit dem gleichen Framework arbeiten will empfehle ich eine universelle Library.
Der wichtigste Punkt ist meines Erachtens nach die Community zu dem Framework - zum einem: umso größer sie ist, desto besser ist wahrscheinlich das Framework. Zudem ist es natürlich dann viel leihcter Hilfe zu erhalten.
Und zu guter Letzt: Das Interface. Der Punkt ist für Android möglicherweise zu vernachlässigen, da durch Java immer eine saubere Objektorientierte API vorhanden ist. Bei C++ ist das leider nciht so selbstverständlich, und spätestens wenn im Interface mit Pointern hin und hergeworfen wird und möglicherweise ncihtmal OO genutzt wurde, stand der Fehlerteufel schon grinsend in der Ecke. Für Android würde ich dann einfach darauf achten, ob sich die API gut anfühlt, aber sobald man sich in eine eingearbeitet hat fühlt sie sich immer brauchbar an. Deswegen würde ich darauf keinen zu großen Wert legen.

Gut, zu guter Letzt noch eine Anmerkung zum Datenformat. DAS 3d-Format gibt es nicht. 3ds ist ein ziemlich gutes, da es iirc alle Informationen des Modelles inklusive Material und Animationen beinhaltet sind. Allerdings ist das nicht immer erwünscht, da dies nun auch ein Overhead sein kann, oder wenn sich mehrere Modelle ein Material teilen kann es auch Redundanz sein. Zudem glaube ich mich zu erinnern, dass 3ds keine Skeletal Animation unterstützt.
Unterm Strich kann man sagen, dass viele Libraries ein eigenes optimiertes Format mitbringen, aber da gibt es dann auch Konverter zu, die idR alle auch 3ds importieren können


Ich hoffe ich konnte dir ein wenig helfen auf deiner Suche

 

[funcoder]

Danke reddox für deine ausführliche Hilfe.
Ich habe jetzt doch einiges recherchiert und möchte euch die wohl besten OpenGL basierenden und Android unterstützenden Frameworks kurz nennen:

-jPCT (Mein Favorit)
-jMonkey Engine (Sehr komplex, große Community. Android Portierung noch in Testphase)
-libgdk (Schlank und schnell)

Nach einigen Tests habe ich mich nun für jPCT entschieden.
Und nach gut 2 Stunden Einarbeitungszeit kann ich wie ich denke doch bereits die Grundlagen. ->Objekte laden, bewegen, rotieren, Kamera.

Das Framework fühlt sich zumindest so an, als ob es einem enorm die Arbeit abnimmt. Bin also sehr zufrieden

Und stimmt ja, das 3DS Format ist wohl deutlich dem OBJ Format vorzuziehen. Da es binär aufgebaut ist, und somit kleinere Dateigrößen produziert als auch schneller beim importieren ist.

Alle oben genannten Frameworks basieren auf Java bzw. performance Kritische Operationen sind auch Nativ. Dennoch ermöglichen alle drei die Entwicklung mit Java.

Hoffe vielleicht jemanden ebenso geholfen zu haben bei der Wahl eines Frameworks

Ergänzung:
Wer Interesse hat, kann sich hier das spezielle Android Framework herunterladen.

 

[FelixL]

Danke, sicher für einige hilfreich die Rückmeldung!

 

[computer_freak]

Danke, hat mir geholfen, obwohl ich bisher nur ogl direkt angesprochen hab!

Uebrigens: Dass binaere dateien kleiner sein sollten? Wer erzaehlt dir denn so einen schmarn?
Jedes Zeichen wird in ein Binaeres Zeichen ersetzt. Wo ist da die einsparung?

im gegenteil:
Durch umwandeln in binaer ist es nicht mehr kompressierbar, im gegensatz zu den allseits beliebten textdateien.

Trotzem ist hier 3ds vorzuziehen, da ladezeiten hier wohl wichtiger als dateigroesse ist.

 

[funcoder]

Uebrigens: Dass binaere dateien kleiner sein sollten? Wer erzaehlt dir denn so einen schmarn?
Jedes Zeichen wird in ein Binaeres Zeichen ersetzt. Wo ist da die einsparung?

Also ich hab hier von dem ein und dem selben Objekt eine File im OBJ Format (73,4KB) und eine im 3DS Format(40,6KB). Demnach ist mein Gedanke wohl nicht ganz so abwegig.

Was ich meine ist, das die OBJ File textuell aufgebaut ist. Die Datei kann man mit einem beliebigen Texteditor problemlos öffnen. Da diese das Element exakt beschreibt und keine Komprimierung vorgesehen hat. Ansich hat das OBJ Format den wohl denkbar größten Overhead. Sicherlich könnte man auf Basis des OBJ Format seinen eigenen angepassten Standard basteln...

Die 3DS File ist nicht textuell aufgebaut, sondern schon auf das nötigste komprimiert.

So zumindest meine Erfahrung

 

[computer_freak]

Hihi, naja
versuche mal folgendes:
DeinObject.obj => rechtsklick => komprimieren => .7z oder .zip
Du wirst sehen, die dateigroesse schrumpft enorm.

Nun versuche dasselbe mit der 3ds datei. Kaum ein unterschied.

Das ist im wesentlichen das, was ich damit sagen wollte.

Bleibt nur die frage offen: Wieso/wie "komprimiert sich" die binaere datei?

Btw: tut mir leid, habe hier nur ne EN keyboard zur verfuegung, also nicht wundern wegen umlauten und dem allseits beliebten scharfem s

 

[funcoder]

Ohaa okay
Na man lernt nie aus, naja trotzdem möchte ich mein apk nicht unötig aufblähen. Danke für die Aufklärung

 

[reddox]

Bleibt nur die frage offen: Wieso/wie "komprimiert sich" die binaere datei?

Das ist schnell erklärt.

Zum einem: Warum ist Binär kleiner?
Das hängt vor allem mit der Datendarstellung zusammen - eine Zahl 1000 zB braucht binär 10 Bit - in Textdarstellung braucht man 4*8=32 Bit.
Zudem kommen noch Kleinigkeiten wie Schlüsselwörter zur Angabe von Position von Daten bei der Txtfile dazu, was bei der Binärfile auch nciht so gross ins Gewicht fällt.

Das andere Thema: Warum lässt sich eine Textfile besser komprimieren?
Das hängt natürlich von dem Komprimierungsalgorithmus ab. Wichtig zu wissen ist hier, dass Statistik eine grosse Rolle spielt. Es wird aus bestimmten Zeichenfolgen in der Datei eine Bibliothek/Lexikon erstellt, welches dann in der komprimierten Dateie referenziert wird. Nun ist es bei Textdateien viel wahrscheinlicher sich wiederholende Zeichenfolgen zu finden - weswegen die Lexikalische Analyse viel erfolgreicher ausfällt. Ausserdem ist die Entropie von Textfiles viel geringer: von den 256 Möglichkeiten die ein Byte nutzen kann werden vllt 40 regelmässig genutzt - die anderen selten bis nie. Das hat natürlich einen großen Einfluss auf die weiter oben genannte Lexikalische Analyse.