 Thema: Stand und Organisation des Projekts - Fragen und Anregungen |
|
|
Danke fuer die weiteren Antworten!
An dieser Stelle moechte ich eine Zusammenfassung wagen.
Bitte korrigiert mich, wenn ich etwas falsch aufgefasst habe.
- Engine-unabhaengiges Arbeiten wird aufgrund des zu hohen Aufwandes abgelehnt.
Das zur Verfuegung stellen der gta:berlin Assets fuer andere Projekte wird vehement abgelehnt;
alle Kontributionen sollen gta:berlin vorbehalten bleiben. Das Projekt ist ein GTA IV mod.
- Der Umfang des Projektes ist derzeit klar auf Berlin-Mitte beschraenkt.
Sind diese Arbeiten eines Tages abgeschlossen, koennte man das Projekt entsprechend ausweiten.
- Public Hosting waere tendenziell denkbar, es existiert aber derzeit keine Infrastuktur
bzw. kein passender Service. Es waere denkbar, hierfuer Dropbox- oder OneDrive-Speicher anzumieten.
Git wird als Option eher abgelehnt.
- Die Organisation der Daten erfolgt bereits in einer Datei pro Block.
So koennen Abgaben von Aktivisten auch eingereicht werden.
Das Zusammenfuegen der Welt und das Einbringen in die Engine ist ein separater Prozess.
- Ein Texturarchiv wird als hilfreich empfunden, aber Hosting und Organisation sind unklar.
- Copyright/Lizenz des Projekts ist (?) und soll zentral und fuer alle Assets gleich geregelt sein.
- Bessere Dokumentation wird als wuenschenswert eingeschaetzt,
scheitert derzeit aber an mangelnden Kapazitaeten.
- Eine Darstellung des aktuellen Standes sollte erstellt bzw. die bestehende aktualisiert werden.
Im Folgenden noch ein paar Kommentare und Nachfragen zum bisher Besprochenen.
Asset-Hosting
Bezahlter Cloudspeicher bringt Probleme mit sich. Er gehoert einer Person, bei Projektaustritt oder
Zahlungsverzug etc. kann ploetzlich der gesamte Projektinhalt wieder ueber Nacht verschwinden.
Deshalb frage ich erneut: Was spricht aus Eurer Sicht gegen git?
Verwendet man Collada als Abgabeformat, waeren die 3D-Modelle ja sogar im Textformat.
Der Speicher ist kostenlos und kann einfach gesichert werden.
Das Nutzen der Daten in anderen Projekten kann via README/Lizenz verboten werden.
Und wenn git trotzdem abgelehnt wird: Kennt jemand weitere Alternativen?
LOD
| Zitat: |
| Das Problem hierbei liegt, dass ich noch nicht ganz hinter das LOD System der Engine gekommen bin. |
Bedeutet das, gta:berlin hat bisher kein LOD genutzt? Wieviele LOD-Stufen haben die GTA IV-Assets?
Dokumentation
Wie gesagt: Ich waere bereit, mich darin zu versuchen. Zwei Voraussetzungen gibt's aber.
Erstens, ich selbst brauche alle noetigen Infos. Momentan gibt's noch viele Fragezeichen.
Zweitens, die Doku muss irgendwo hin. Wenn's git (und damit git wiki) nicht sein soll,
dann muesste eine Alternative her. Gibt's dazu vielleicht Vorschlaege?
Markdown-basierte Loesungen wuerde ich empfehlen und bevorzugen.
Unterbringen koennte man die Doku vermutlich auf der Homepage?
Copyright / Lizenz
Wo ist die zu finden? Ich bin noch immer nicht ganz sicher, welche Ihr hier nutzt bzw. was gilt?
Separierung des Workflows
Auch wenn das Projekt die Assets nicht fuer andere Projekte freigibt, spreche ich mich
fuer eine klare Aufteilung der Organisation bzw. des Workflows in zwei Teile aus (s.o.).
Sprich: Erstellung und Abgabe von Bloecken ist klar dokumentiert und vereinheitlicht.
Also z.B. im selben Dateiformat, mit immer gleichen Namensschemen, etc.
Diese Daten sind es, die dann in der Cloud oder wo auch immer gehostet werden.
Das Weiterverarbeiten der Daten, so dass sie in der Engine landen ist der zweite Teil.
Also zum Beispiel das Zusammenfuegen der einzelnen Bloecke in der "Map-Datei".
Macht das so Sinn bzw. entspricht das ungefaehr dem aktuellen Workflow?
Informationen zum Modellieren / modden
Angenommen, ich wuerde jetzt ein Gebaeude beisteuern wollen, ich koennte es nicht.
Denn ich verstehe noch immer nicht, wie fuer die GTA IV-Engine modelliert werden muss.
Es gibt zwar diesen Post, der einige Wichtige Infos gibt,
aber es ist unklar, ob er aktuell ist und zudem bleiben auch weiter Fragen offen.
Wichtige Infos waeren z.B.:
- Wie und wo gebe ich meine Modelle ab? Per E-Mail oder im Forum?
- Wie "reserviere" ich einen Block, damit sich Arbeiten nicht ueberschneiden?
- Woher bekomme ich die Vorlage, also "Blueprint", Grundriss, etc?
- Welchen Detailgrad sollen Modelle und Texturen haben?
- Wieviele LOD-Versionen gibt es? Zwei, drei, vier?
- Gibt's ein separates Physics-Shape, oder wird das kleinste LOD genutzt?
- Nutzt GTA IV nur diffuse, oder auch normal/spec maps? Bump? Ganz andere?
- Welche weiteren Besonderheiten sind zu beachten?
Was ist mit Ambient Occlusion, Vertex Colors, Transparenz, Licht, Leuchten, ...?
- uvm.
Zu den ersten Punkten hat Trabbi zum Teil in seiner ersten Antwort schon etwas gesagt,
aber ich fuehre sie der Vollstaendigkeit halber noch mal auf.
Randbehandlung
Ich hatte das eingangs schon gefragt, aber noch keine Antwort gefunden:
Wenn Berlin-Mitte mal fertig modelliert ist, wie wird das "Ende" der Map gestaltet?
Eine schwimmende Stadt-Insel? Gebirge? Eine hohe Mauer? Blick ins Nichts?
Soweit erstmal. :-)
|
|
| Thema: Stand und Organisation des Projekts - Fragen und Anregungen |
|
|
Hey MoeRon,
hallo auch an Dich und danke fuer dein Feedback!
| Zitat: |
| Es kam nämlich rüber als würdest du dich als Projektleiter etablieren wollen ohne etwas fürs Projekt geleistet zu haben. |
Das hatte ich befuerchtet, aber da kann ich Entwarnung geben: Erstens waere das super unangemessen und vermessen,
zweitens waere mir das viel zu viel Verantwortung. 
| Zitat: |
| Es gibt nicht wirklich Performance Probleme. |
Ah, okay. Ich hatte mich da auf die Aussage von Dreyli etwas weiter oben bezogen.
Wenn das aber schon ueberholt ist, dann sind das gute Neuigkeiten!
| Zitat: |
| Des weiteren funktioniert unsere Zuarbeit mit den von uns gewählten (und absichtlich nicht genannten) Mitteln sehr gut. |
Aber wie funktioniert die denn eigentlich? Das konnte ich bisher noch nicht so recht rausfinden.
Sollte es fuer potentielle Helfer nicht klar ersichtlich sein, wie sie helfen koennen? Huerden scheinen kontraproduktiv.
Und um mich etwas zu wiederholen: Was ist mit backups? Was, wenn ich die Dateien fertiger Gebaeude als Referenz hernehmen moechte?
Solange ich als Aktivist nicht sicher sein kann, was mit meinen Daten passiert, waere das fuer mich ein Grund, nicht mitzuwirken.
Diesbezueglich wuerde ich gerne einen Post von Trabbi aus diesem Thread von 2012 zitieren:
"[...] Ich habe leider das Problem, dass ich meine Festplatte erfolgreich, ohne Backup oder ähnliches, abgeschossen habe und daher ALLES weg ist*HEUL* [...]"
| Zitat: |
| Hier hatten wir in der Vergangenheit Probleme das dritte sich Zugang dazu erschlichen haben und unfertige Sachen dann in Foren kursierten. [...] Ich meine es ist ja nicht unmöglich Mittels der von uns bereitgestellten Daten dran zu kommen wenn man es umbedingt will. |
Hm, mein Ansatz waere hier ein grundlegend anderer: Den Zugang nicht erschweren, denn wer wirklich dran kommen will, der tut es vermutlich.
Hast Du ja selbst gesagt. Stattdessen ueber eine klare Lizenz regeln, wer welche Rechte hat.
| Zitat: |
| Ich z.B. möchte nicht das meine für GTAB gebauten Sachen für irgendwas anderes verwendet werden. |
Oh. Das steht natuerlich in einem gewissen Konflikt zu einem der beiden wichtigsten Teile meiner Vorschlaege. Darf ich die Hintergruende erfragen?
So oder so: Wenn das bei den meisten Mitwirkenden die vorherrschende Meinung ist, koennte man die Lizenz natuerlich entsprechend waehlen.
| Zitat: |
| Und wenn wir uns von GTA trennen und eine andere Engine verwenden bin ich sowieso weg. |
Vielleicht muss ich da noch mal etwas genauer auf meine Vorstellung eingehen. Um das klar zu machen: gta:berlin soll sein Ziel nicht aendern!
Nach meinem Vorschlag bleibt das Projekt ein GTA Mod. Meine Idee ist es, das Projekt sozusagen in zwei Ebenen bzw. Teilbereiche einzuteilen.
Die untere Ebene waere die Erstellung von einem Berlin in 3D, also die "generischen Assets".
Die obere Ebene waere dann das Zurechtschnitzen dieser Assets, so dass man sie der GTA-Engine fuettern kann.
So laeuft es ja im Prinzip bereits. Nur wuerde sich die Trennung dann in Kommunikation, Organisation und Arbeitsablaeufen klarer wiederspiegeln.
Der Vorteil ist, dass die obere Schicht jederzeit ausgetauscht werden kann! Auch dies ist in der Vergangenheit ja bereits passiert:
Man hat von der GTA3 auf die GTA4-Engine gewechselt. Da die Assets z.T. nicht darauf ausgelegt waren, war der Wechsel vermutlich
mit ziemlich viel Handarbeit verbunden. Wenn man nun aber von vornherein versucht, die Assets moeglich Engine-Neutral zu gestalten,
dann ist es nur noch die obere Eben, welche bei einem Engine-Wechsel ihre Prozesse anpassen muss.
Sind diese Prozesse moeglichst automatisiert (falls moeglich?), z.B. Scripts, welche von Collada-Format in das Engine-Format umwandeln,
dann lassen sich entsprechende Wechsel moeglicherweise auch halbwegs Schmerzfrei gestalten. Kommt halt immer drauf an.
Ich hoffe, die Idee ist jetzt etwas klarer und klingt weniger abschreckend?
| Zitat: |
| Und dann noch zu der Versionskontrolle die du angesprochen hast. Die ist für das verwalten von Binärdaten ziemlich ungeeignet. |
Ist sie. Leider. Wie gesagt, so richtig toll ist die Loesung nicht, aber ich habe bisher keine bessere finden koennen.
Aber: Wenn man z.B. Collada waehlt, waren die 3D-Modelle ja gar keine Binardateien mehr. Nur noch die Texturen.
Ich koennte mir schon vorstellen, dass das ganz gut klappt.
| Zitat: |
| Und wir bräuchten einen GIT Master der Pull Request verarbeitet. |
Klingt sinnvoll, ja. Aber wie laeuft es denn jetzt? Wenn ich es richtig verstanden habe, gibt es derzeit einen "E-Mail-Master",
der Zuarbeiten der E-Mail (oder so aehnlich?) entgegen nimmt und diese verarbeitet. Einfacher oder besser klingt das nicht.
Abgesehen davon: Das liesse sich mit git dann immernoch abbilden. Wenn ein Artist keine Ahnung von git (oder keinen Bock drauf) hat,
kann er ja den Projektleitern nach wie vor seinen Kram per E-Mail schicken und die packen das dann fuer denjenigen ins git.
Vorteil waere, dass jeder sehen kann, was der Status ist. Jeder kann die Arbeit anderer als Referenz nutzen.
Und Kollaboration ("Ich habe Gebaeude 92 fertig, aber ich braeuchte Hilfe beim Texturiern!") waere sehr einfach moeglich.
Sehr gerne lasse ich mich aber auch noch davon ueberzeugen, dass das aktuelle System (?) besser ist.
Oder vielleicht hast Du (oder jemand anderes) noch eine bessere Idee, als git?
Bin auf die weitere Diskussion gespannt! 
|
|
| Thema: Stand und Organisation des Projekts - Fragen und Anregungen |
|
|
Wie angekuendigt werde ich im Folgenden meine Ideen und Vorschlaege vortragen.
Diese sind teils recht umfangreich und weitreichend. Aus diesem Grunde moechte ich vorab anmerken, dass ich verstehen kann,
wenn der ein oder andere Projektvater bzw. langjaehriger Aktivist dies im ersten Moment mit gemischten Gefuehlen betrachtet.
Lest es Euch einfach in Ruhe durch und lasst uns dann darueber diskutieren. Letztlich bin ich einfach ein Fan des Projekts,
der dieses unbedingt voranschreiten sehen will. Dafuer versuche ich hiermit einen Beitrag zu leisten.
Bestandsaufnahme
Probleme allgemein
- Trotz sehr langer Laufzeit ist das Projekt weit von der Fertigstellung entfernt
- Derzeit scheint die Aktivitaet des Projekts gegen Null zu gehen
- Die Entwicklung der GTA-Serie schreitet schneller voran, als die Arbeiten am Projekt
- Das Projekt ist in seiner Natur gewaltig und braucht viele aktive Helfer
- Organisation und klare Arbeitsablaeufe sind notwendig, aber nicht erkennbar oder vorhanden
- Informationen zum Projekt sind zumeist irgendwo im Forum vergraben
- Die Homepage ist etwas unuebersichtlich (subjektiv), die Infos z.T. veraltet (Engine), die letzte News von vor 2 Jahren
- Es gibt schon jetzt Performance-Probleme, obgleich nicht mal ein Bezirk fertiggestellt ist
- Die Zuarbeiten werden auf privaten, nicht frei zugaenglichen (und ggf. nicht mit einem Backup versehenen) Rechnern gelagert
Probleme aus Sicht (potentieller) Aktivisten
- Es ist unklar, fuer welche Engine das Projekt entwickelt wird
- Es ist unklar, wie die Mitarbeit am Projekt funktioniert
- Es ist unklar, welche technischen Anforderungen Modelle erfuellen muessen
- Es ist unklar, welche Arbeiten bereits getan, welche ausstehend sind
- Es ist unklar, welche Rechte Aktivisten an beigesteuerten Arbeiten haben
- Es ist unklar, welche Rechte Dritte an den Projektarbeiten haben
- Es ist unklar, wo Arbeiten abgegeben werden
- Es ist unklar, wo abgebene Arbeiten zugaenglich sind
- Es ist unklar, welche Softwareanforderungen es gibt
Probleme aus Sicht (potentieller) Nutzer
- Es ist unklar, welchen Status das Projekt hat und ob es noch aktiv ist
- Es ist unklar, wie das Projekt getestet werden kann
- Es ist unklar, was die (naechsten) Zwischenziele des Projekts sind
Auf der Haben-Seite
- Das Projekt ist nach langer Zeit noch immer online
- Es gibt noch eine gewisse Aktivitaet (siehe z.B. diesen Thread)
- Es gibt eine Projekt-Webseite
- Es gibt einen etablierten Kommunikationskanal (dieses Forum)
- Die vielen User und Aktivisten ueber die Jahre haben gezeigt, dass generell grosses Interesse am Projekt besteht
- Es ist ueber die Jahre schon viel an Material zusammengekommen (wieviel genau, kann ich aber noch immer nicht einschaetzen)
Zusammengefasst
Man stellt schnell fest, dass man die Probleme zu einigen wenigen Punkten zusammenfassen kann:
- Informationen: Informationen zum Projekt (fuer Nutzer und Helfer) sind entweder nicht vorhanden, veraltet oder schwer zu finden.
Aktuelle, ausfuehrliche und einfach zu findende Informationen sind aber eine Notwendigkeit.
- Organisation: Copyright, Aufteilung, Arbeitsprozesse, Vorlagen, Vorgaben, notwendige Werkzeugen, Zwischenziele...
es mangelt an allen Ecken an einer vernuenftigen Organisation.
- Zugaenglichkeit: Wo sind die eingereichten Modelle? Gibt es ein Backup? Dies ist momentan eine Black Box - das darf einfach nicht sein.
- Technisches: Schon jetzt gibt es Performance-Probleme. Vor dem Hintergrund der geplanten Ausweitung des Projektes
ist dies ein ernstzunehmendes Problem, welches genauer untersucht werden muss.
Loesungsvorschlaege
Es ist klar: Um dieses Projekt am Leben zu halten und zu vollenden, muss um Mitstreiter geworben werden.
Dies ist nur moeglich, wenn der Rahmen fuer eine einfache Kollaboration und gute, aktuelle Informationen existieren.
Deshalb muss dieser Rahmen dringend geschaffen und die Informationen bereitgestellt werden.
Ausserdem muessen die Proezesse moeglichst optimiert werden, damit die Arbeiten so einfach und schnell wie moeglich erfolgen koennen.
Ich schlage im Groben vor:
- Das Projekt sollte sich, so weit moeglich, nicht an eine spezielle Engine binden
- Die Modelle und Texturen sollten, in einheitlichem Format, oeffentlich gehostet werden
- Die Rechte an den Modellen und Texturen sollten klar definiert und ersichtlich sein
- Die Arbeitsablaeufe sollten durchdacht, vereinheitlicht und dokumentiert werden
- Technische Huerden bei der Mitarbeit sollten, soweit moeglich, beseitigt werden
- Ein uebersichtliches, umfassendes Informationsportal muss geschaffen werden
- Veraltete Informationen auf der Homepage muessen aktualisert werden
- Regelmaessige Neuigkeiten, auch wenn diese "Nichts Neues" lauten
1: Engine agnostic approach
Anfangs begann gta:berlin als GTA:SA mod. Irgendwann einigte man sich, fuer GTA IV zu modellieren.
Inzwischen gilt die GTA IV Engine unter Gamern als veraltet und erste Gruechte zu GTA VI machen die Runde.
Mit jedem Wechsel zu einer neuen Engine entsteht ein grosser Arbeitsaufwand, z.B. weil die Modelle ploetzlich
mit mehr Details ausgestattet werden muessen und hochaufloesendere Texturen benoetigt werden.
Dies kann dem Projekt auf lange Sicht das Genick brechen. Moegliche Aktivisten beschraenken sich
immer nur auf solche, die auch an dem entsprechenden Spiel interessiert sind.
Warum nicht abstrakter arbeiten? Jede mir bekannte Engine nutzt LoD. Ich schlage deshalb vor,
dass wir drei bis vier (eher drei) LoD-Level festlegen, die jeweils mit Beispielen in ihrer Ziel-Komplexitaet dokumentiert werden.
Jedes zu erstellende Gebaeude sollte also drei oder vier visuelle Modelle (plus die physikalische Repraesentation) umfassen, wenn es abgegeben wird.
So koennte man, wollte man die Gebaeude in GTA:SA bringen, nur das einfachste und mittelkomplexe Modell nutzen,
fuer GTA IV oder V das mittlere und high-poly Modell. Die Texturen sollten entsprechend in ausreichend hoher Aufloesung vorliegen;
je nach Anforderungen der Engine koennen diese bei Bedarf sehr einfach herunterskaliert werden.
Normal Maps (und Aehnliche) koennen fuer Engines, welche diese nicht brauchen, einfach weggelassen werden,
sind fuer bessere Engines aber vorhanden, etc.
Der Vorteil dieses Ansatzes ist insbesondere dieser: Das Projekt rueckt in seiner Natur damit eher an ein generisches 3D-Modell von Berlin
(mit klarem Fokus der Daten auf Nutzung in einer Spiele-Engine), als ein GTA Mod. Das mag zuerst schlecht klingen, hat aber riesige Vorteile:
- Die Zielgruppe potentiell interessierter Mithelfer und Nutzer wird signifikant (!) groesser
- Die Arbeitsprozesse werden einfacher, denn wir brauchen die Daten nicht als DFF oder aehnliches ablegen,
sondern koennen weithin kompatible und offene Formate verwenden. Umwandlung in Engine-spezifische Formate
kann man dann vermutlich in den meisten Faellen weitestgehend automatisieren
- Organisation und Kommunikation werden einfacher
- Softwareanforderungen an Helfer wuerden sich auf ein Minimum beschraenken
- Wir koennen moeglicherweise von Synergien profitieren
Zum letzten Punkt: Damit meine ich, dass es Engine-Projekte gibt, die ueber eine Spiele-fertige Datensammlung wie gta:berlin sicherlich sehr froh waeren,
bzw. diese verwerten koennten. Wenn die Helfer eines solchen Projektes dann auf uns aufmerksam werden, koennten deren Resourcen auch uns zuteil werden.
Ich moechte drei Beispiele nennen:
- OpenRW ist eine Open Source Engine Reimplementation von GTA 3, die derzeit in der Entwicklung ist.
Eines der Langzeit-Ziele dieses Projektes ist es, die Spieledaten von GTA 3 durch eigene zu ersetzen. Da koennten wir ins Spiel kommen!
- OpenMW ist eine Open Source Engine Reimplementation von Morrowind, die bereits voll spielbar ist.
Eines der Ziele dieses Projektes ist es, die Engine mit eigenen Assets zu fuettern,
um die Leistungsfaehigkeit der Engine zu demonstrieren und es Nutzern zu ermoeglichen, die Engine auch ohne Morrowind zu testen.
Hier koennten wir ins Spiel kommen!
- Grit Engine ist eine Open Source 3D-Engine, die auf die Darstellung von Open World Spielen wie GTA optimiert ist.
Viele Interessierte Programmierer scheitern aber an fehlenden Assets, wenn sie planen, ein Projekt mit solchen Engines auf die Beine zu stellen.
Hier koennten wir ins Spiel kommen!
2: Public hosting
Wenn alle Kontributionen oeffentlich gehostet sind, ist dies fuer alle Mithelfenden transparent, Backups ergeben sich quasi von selbst,
Helfer koennen die Arbeiten anderer Helfer als Referenz heranziehen und andere Interessierte (Projekte) koennen einfach auf die Daten zugreifen.
Leider konnte ich kein bruachbares kollaboratives Hosting fuer 3D-Modelle finden. Mein Vorschlag hier ist deshalb etwas ungewoehnlich,
ergibt aber hoffentlich gleich Sinn: git Version Control (also z.B. github oder bitbucket).
Eigentlich ist git fuer source code (also Textdateien) gedacht, schluckt aber auch binaere Dateien. Sowohl github als auch bitbucket sind kostenfrei,
sofern man sein Projekt oeffentlich hostet. Das passt gut. Git Clients gibt es kostenlos fuer praktische jedes Betriebssystem.
Die ersten Schritte sind fuer nicht-Programmierer etwas befremdlich, mit einer kleinern Anleitung aber zu bewaeltigen.
Durch die Moeglichkeit, ein Projekt zu clonen, kann jeder sofort das gesamte Projekt herunterladen.
Das Beziehen einzelner Dateien ist ueber die Webinterfaces von github und bitbucket auch moeglich.
Das "forken" (also kopieren) kann das Projekt im Falle einer Verwaisung durch andere User jederzeit wieder aufgenommen werden.
Weitere Vorteile folgen weiter unten.
Sowohl bitbucket als auch github haben eine Obergrenze von 1 GB pro Repository (also Projekt-Speicherplatz).
Dies koennte zu einem Problem werden, sollten wir jemals ueber Berlin Mitte hinaus kommen, sollte bis dahin aber kein Thema sein.
Zudem laesst sich das Limit leicht aushebeln, indem wir einfach pro Bezirk ein Repository anlegen koennen, das ist sowieso sinnvoll.
Vermutlich sollten die Texturen zudem auch in ein separates Repository.
Die Probleme, die git mit Binaerdaten haben kann, liessen sich komplett umgehen, wenn wir ein Reintext-basiertes Format fuer die 3D-Modelle nutzen.
Da wuerde sich zum Beispiel Collada (.dae) anbieten, welches nebenher ein offenes Format ist,
welches von praktisch jedem Programm geoeffnet werden kann.
Zumindest github erlaubt es, einzelne Dateien von externen Seiten aus zu referenzieren. Dies wuerde es ermoeglichen,
einen Webbasierten "Gebaeude-Viewer" zu erstellen, welcher via WebGL einzelne Modelle unseres Projektes darstellen kann.
Das waere unwahrscheinlich praktisch.
3: Copyright etc
Simpel. Wir muessen einmalig festlegen, welche Rechte die Aktivisten und Nutzer haben und dieses dokumentieren.
Mit git waere dieses besonders einfach, da wir es in der zentralen Beschreibung des Projektes (README.md) unterbringen koennen.
Eine moegliche Lizenz koennte z.B. die CC-BY-NC sein, welche die freie Nutzung (unter Namensnennung) fuer nicht-kommerzielle Projekte erlaubt.
4: Arbeitsablaeufe
Schwieriger. Wie kommen alle Gebaeude zusammen, wenn diese fertig sind? Niemand will in einer riesen Datei arbeiten, besser waere eine Datei pro Gebaeude oder Block.
Nehmen wir die 3D-Daten der Stadt Berlin irgendwie als Vorlage? Welches Dateiformat sollen die Abgaben haben? Namenskonvention? Wohin mit den Texturen?
Hier gibt es noch viel zu klaeren. Aber ist dies ein mal getan, muss es nur dokumentiert werden, dann kann sich jeder daran halten und es laeuft rund.
Hier lasse ich viele Fragen offen, schlage aber dies vor: Wir muessen einen Weg finden, jedes Berliner Gebaeude eindeutig zu bezeichnen.
Vielleicht gibt es im LIKA dazu etwas, wie eine eindeutige Nummer. Sobald wir dies wissen, sollten wir im git (oder wo auch immer) pro Bezirk fuer jedes Gebaeude
einen Ordner mit dieser Bezeichnung erstellen. Darin koennen dann alle zum Gebaeude gehoerigen Dateien nach einem festen Schema abgelegt werden.
Also zum Beispiel <Gebaeudename>-LoD1.dae, <Gabaeudename>-LoD2.dae, usw.
Eine zusaetzlich README.md (oder auch TODO.md oder aehnliches) kann den Autor des Werkes listen (bzw. die Autoren)
und auf den Status verweisen ("muss noch texturiert werden", "der Innenhof fehlt noch", ...).
Leere Ordner zeigen klar: Hier gibt's noch nichts. Wer will, der darf!
Dies koennte man durch ein Script auch automatisch auswerten lassen.
Damit liesse sich z.B. eine dynamische %-Anzeige des Projekt-Fortschrittes realisieren!
Weiterhin ist es auf Performance-Gruenden wichtig, dass wir Texturen mehrfach verwenden, wo immer dies moeglich ist.
Gerade generische Obflaechen wie "Beton" oder "Pflasterstein" bieten sich fuer soetwas an.
Es scheint also sinnvoll, ein zentrales Texturarchiv (weiteres git Repository?) zu erstellen.
Hierin koennten Modell-Autoren nach passenden Texturen suchen und diese nach Moeglichkeit auch fuer ihr Modell nutzen.
Nur wenn keine passende Textur gefunden werden kann, sollte eine neue Textur erstellt und dem Archiv hinzugefuegt werden.
Das Referenzieren der Texturen von den Modellen sollte einheitlich erfolgen (immer relativ? Immer absolut? Wie genau?).
Auf diese Weise werden wir Performance-Problemen entgegenwirken und auch die Downloadgroesse des Projektes moeglichst klein halten.
Ausserdem ermoeglicht es 2D-Artists, sich auf das Erstellen von Texturen zu konzentrieren,
ggf. auch ganz unabhaengig vom Modellieren, z.B. auf Anfrage eines 3D-Artists.
5: Technische Huerden beseitigen
Ergibt sich eigentlich bereits. Insbesondere bedeutet dies: Es waere schoen, wenn auch solche Nutzer (weiterhin?) mitwirken koennten,
die ausschliesslich mit freier und offener Software (Linux, Blender, ...) arbeiten. Sofern wir die Abgabe der Daten in einem offenen Format
wie Collada beschliessen und das Konvertieren der Daten fuer eine spezielle Engine auslagern, sollte dies absolut kein Problem sein.
6: Informationsportal
Ein weiterer Vorteil, sollten wir git benutzen: Hier kann man ein an das Repository gekoppeltes Wiki einrichten,
welches sehr uebersichtlich und einfach zu pflegen ist. Hier koennen Anleitungen, Tutorials, wichtige Resourcen
und alle anderen kritischen Informationen fuer Helfer sauber hinterlegt werden.
In der zentralen Projektbeschreibung (README.md) kann fuer jeden Interessierten zusaetzlich eine Projektbeschreibung
mit den wichtigsten Eckpunkten hinterlegt werden. Wunderbar!
7 und 8: Homepage auf Vordermann bringen
Trivial. Einfach mal wieder was posten, auch wenn es nur "Wir leben noch" ist.
Und veraltete Infos, wie "GTA:Berlin ist eine Modifikation des Spiels Grand Theft Auto: San Andreas", sollten aktualisiert werden.
Okay, das soll vorerst reichen! Das Schreiben hat ein paar Stunden gedauert, das Lesen sollte zumindest etwas schneller gehen.
Sorry, wenn es trotzdem ziemlich lange dauert. Ich bin gespannt, was ihr denkt.
|
|
| Thema: Stand und Organisation des Projekts - Fragen und Anregungen |
|
|
Hey Dreyli,
schoen, dass auch Du dich einschaltest. Danke fuer deinen Input! Hier kurz meine Anmerkungen bzw. Antworten auf deine Infos bzw. Rueckfragen:
Performance-Probleme klingt nicht gut. Konntet Ihr herausfinden, was der Flaschenhals ist? Texturen, Polycount, LoD? Oder liegt's daran, dass ihr - soweit ich es auf den Screenshots erkennen konnte - die neuen Inhalte einfach zusaetzlich zur Welt von GTA 3/4 hinzugefuegt habt, statt diese zu ersetzen?
Wenn die Map erst mal nicht groesser werden soll, bedeutet das mit anderen Worten: Erst mal nur Berlin-Mitte, richtig? Finde ich perspektivisch schade, kurzfristig aber doppelt sinnvoll: Nicht nur fuer die Performance, sondern auch aus Sicht des Arbeitsaufwandes.
3D-Modelle: Den Link aus dem letzten Post wuerde ich glatt wieder vergessen. Diese DWG-Daten konnte ich mit keinem Tool brauchbar oeffnen oder konvertieren (was nicht heisst, dass es nicht wer anders schafft, aber eben auch, dass es nicht sonderlich einfach ist). Jedoch habe ich eine noch viel bessere Quelle gefunden! Das 3D-Stadtmodell Berlin, welches inzwischen unter dem sehr unintuitiven Namen Wirtschaftsatlas Berlin im Netz steht. Kurz zusammengefasst: Auch dies ist ein 3D-Modell von Berlin (vermutlich basierend auf den zuvor gefundenen Daten, nicht sicher), allerdings viel besser zugaenglich. Features:
- Groesstenteils sehr simpel modelliert, als Platzhalter/Vorlage aber brauchbar
- Gebaeudehohen sind recht praezise, da auf Basis von Lasermessungen
- Groesstenteils aus Satellitenbildern texturiert (eher nur als Orientierungshilfe nuetzlich)
- Als 3D-Map im Browser anschaubar (aehnlich Google Earth bzw. Maps)
- Bezirksweise als CityGML-Download verfuegbar (Archive mit extrem vielen Dateien)
- Zusaetzlich koennen Gebaeude nach Wahl als CityGML oder 3DS exportiert werden
Einige Fragen sind auch bei mir noch offen, was die Daten angeht. Zum Beispiel sind in der Browser-Map einige Gebaeude sehr detailliert modelliert und ziemlich gut texturiert, in den heruntergeladenen Daten dann jedoch wieder nur extrem simpel modelliert und aus verzerrten Satellitenbildern texturiert. Woher diese Diskrepanz der Daten kommt, wuerde ich gerne noch herausfinden. Ich hoffe, dass wir auch an die "bessere" Variante kommen koennen.
Das CityGML-Format ist mir neu, es ist aber ein offener Standard und eine Form von XML. Somit ist hier zumindest theoretisch alles moeglich. Bislang konnte ich ein Script finden, welches CityGML-Daten in Blender importieren kann. Allerdings als ein einziges, riesiges Objekt. Zum Test habe ich das Archiv von Charlottenburg-Wilmersdorf heruntergeladen und importiert. Das Entpacken habe ich ohne Texturen vorgenommen, denn mit Texturen war mein Rechner auch nach 8 Stunden (!) noch immer nicht mit dem Entpacken fertig. Hier mal drei Ansichten dessen, was ich nach dem Import in Blender hatte:
Charlottenburg-Wilmersdorf in der Top-View (Wireframe).
Links in der Mitte: ICC. Rechts mittig: Savignyplatz.
Sophie-Charlotte-Platz im Wireframe.
Ungefaehr von Sued-West drauf geguckt.
Breitscheidplatz im solid mode.
Man sieht den Bahnhof Zoo, den Zoopalast, die KWG-Kirche etc.
Letztlich sind die Daten nicht dramatisch viel nuetzlicher, als ein 2D-Plan: Der groesste Vorteil ist, dass die Lage und Relationen aller Gebaeude zueinander stimmt und damit eine schoene Vorlage liefert. Zwei weitere Vorteile gibt's aber: Die Gebaeude haben scheinbar eine halbwegs korrekte Hoehe und zum Teil bereits modellierte Dachaufbauten und andere "Details". Damit liefern sie dann wirklich eine perfekte Vorlage, die man in einem Workflow gewinnbringend nutzen koennte.
Inzwischen bin ich auf ein weiteres Script aufmerksam geworden, welches angeblich etwas intelligenter vorgeht, und getrennte Objekte (= Gebaeude) beim Import auch als separate Objekte beruecksichtigt. Getestet habe ich es noch nicht.
Die Lizensbedingungen der Daten sind sehr entspannt; vereinfacht zusammengefasst kann jeder diese zu jedem Zweck (auch kommerziell) benutzen, solange es nicht fuer rechtsextreme oder pornographische Zwecke ist. ;-)
Mein Fazit: Wenn wir den Umgang und die Verfuegbarkeit (detaillierte Versionen einiger Gebaeude?) mit diesen Daten noch etwas erkunden, dann koennten diese sich als grosse Hilfe erweisen. Wir haetten damit bereits ein komplettes Berlin in 3D (wenn auch untexturiert bzw. schlecht texturiert), abgesehen von der Infrastruktur. Dieses "einfache" Berlin in 3D liesse sich fuer Tests mit der Engine bzw. fuer Preview-Versionen benutzen. Bei Fertigstellung eines echten Gebaeude-Modells koennte der entsprechende Platzhalter dann gegen dieses getauscht werden. So wuerde die Stadt langsam Gestalt annehmen. Weiterhin sollte es moeglich sein, diese Daten gewinnbringend in den Workflow zu integrieren - und sei es nur als Positionsanzeiger oder als Vorlage beim Modellieren.
Soweit zu deinem Post und den 3D-Daten. Jetzt muss ich mich anderen Dingen widmen. Aber: Morgen oder uebermorgen, allerspaetestens am Wochenende, werde ich erneut Posten. Dann kommen endlich die angekuendigten Ideen und Vorschlaege. Ich hoffe, sie sind erwuenscht. :-)
|
|
| Thema: Stand und Organisation des Projekts - Fragen und Anregungen |
|
|
Vielen Dank fuer die umfassende Antwort!
Ich moechte gerne auf einige Punkte eingehen, deine Fragen beantworten und meinerseits weitere Fragen stellen.
| Zitat: |
| Wir arbeiten aktuell mit GTA IV, weil es bereits die neue Engine hat, sich aber ganz gut bearbeiten lässt. Ich hab in den letzten Jahren mal mit GTA V experimentiert, aber das ist halt alles echt käse, wenn man ernsthafte Map-Mods erstellen will. |
Schade, ich hatte gehofft, es waere noch GTA:SA. Da haette ich dann einen interessanten Vorschlag gehabt. Andererseits ist GTA IV natuerlich wirklich optisch ansprechender. Allerdings bedeutet das ja auch, dass jedes Asset mit mehr Details und die Texturen hochaufloesender erarbeitet werden muessen, das kostet also auch mehr Zeit und Koennen. Dazu folgende Fragen:
- Habt Ihr im Blick, welche der Assets noch zu GTA:SA-Zeiten entstanden sind und entsprechend qualitativ nicht mehr reinpassen (also ueberarbeitet werden muessen), und welche Assets bereits GTA IV-Qualitaet haben?
- Wie unterscheiden sich die GTA IV-Assets von den GTA:SA-Assets? Ich nehme an, GTA:SA wollte nur Diffuse Texturen, GTA IV vermutlich aber auch Normal und Spec Maps?
- Ich nehme an, es waere sehr einfach moeglich, ein fuer GTA IV erstelltes Asset auch in GTA:SA zum Laufen zu bringen? Also z.B. einfach die Normal Map weglassen, ein paar Vertices loeschen?
- Ist die Datenlieferung als DAE (Collada) fuer beide Engines in Ordnung?
| Zitat: |
| Wir nutzen das Offizielle Liegenschaftskataster der Stadt Berlin, um Modelle passend zu erstellen. |
Koenntest Du dies etwas genauer ausfuehren (ein Tutorial waere definitiv hilfreich)? Ich selbst war auf Seiten der Stadt Berlin unterwegs und bin ebenfalls ueber den Begriff "Liegenschaftskataster" gestolpert, doch erstens schienen die meisten Daten erst auf Antrag erhaeltich und zweitens habe ich schnell den Ueberblick verloren, welche Daten es eigentlich gibt, in welchen Formaten diese angeboten werden und wie man sie bekommt. Vielleicht kannst Du mal einen Link zu der Seite posten, auf der Du dir die Screenshots machst? Meinst Du vielleicht diese Karte?
| Zitat: |
| Fertig gestellte Objekte landen aktuell erst mal bei mir oder Dreyli. Einen Zugriff darauf gibt es aktuell nicht, was einfach der Ermangelung einer Plattform geschuldet ist. |
Oh, das ist sehr bedauerlich. Besser gesagt, das finde ich extrem ungluecklich. Was, wenn Ihr beiden ploetzlich nicht mehr erreichbar seid, sei es weil ihr das Interesse am Projekt verliert, in persoenliche Schwierigkeiten geratet (Gesundheitlich, familiaer etc), Euch miteinander oder dem restlichen Team verstreitet etc?
Ausserdem: Als Mitwirkender moechte ich in der Lage sein, mir die Arbeit der anderen Mitwirkenden anzusehen (zum Lernen, als Referenz, zur Inspiration), um anderen "Aktivisten" bei Ihrer Arbeit unter die Arme greifen zu koennen, um einen besseren Eindruck vom Stand des Projektes zu bekommen und letztlich auch, damit ich selbst auf meine Kontributionen zugreifen kann (z.B. im Falle des lokalen Datenverlustes).
| Zitat: |
| Soweit ich weis nutzen wir die Creative Commons Lizens. hab mich aber im Detail nie so wirklich damit auseinander gesetzt. |
Hm, auch das finde ich sehr unguenstig. Es sollten klare Verhaeltnise herrschen. Anders gesagt: Als "Aktivist" sollte es klar ersichtlich sein, welche Rechte ich selbst, das restliche Team und der Rest der Welt an meinen Werken haben wird.
| Zitat: |
| Eine Dokumentation gibt es (leider) nicht. |
Sehr, sehr schade. Vielleicht koennte ich hier ja sogar etwas aushelfen. Natuerlich muesste ich mir dafuer selbst erst noch einen besseren Ueberblick verschaffen, aber da bin ich ja irgendwie gerade dabei.
| Zitat: |
| Wie du siehst ist momentan alles sehr unkoordiniert und chaotisch. Das macht mich als jemand, der selber im IT-Produktmanagement arbeitet natürlich auch nicht glücklich, hab in der Vergangenheit jedoch den Fokus lieber auf Fortschritt gelegt. |
Das verstehe ich sehr gut. Allerdings denke ich: Das Projekt ist riesig. Geradezu monstroes. Man sieht ja, wie lange es schon andauert. Und die Beteiligung ist ueber die Jahre scheinbar nicht unbedingt gewachsen. Soll heissen: Ein bisschen Organisations- und Publicity-Aufwand erscheint mir sehr wichtig, damit man neue "Aktivisten" ins Boot bekommt und so ueberhaupt eine Chance hat, jemals einen spielbaren Stand zu erreichen. Immerhin waere es super traurig und aergerlich, wuerde all der Aufwand der Vergangenheit am Ende ins Nichts laufen. Wie gesagt, vielleicht kann ich dabei ja etwas helfen.
An dieser Stelle vielleicht kurz zu mir:
- Sitze in Berlin
- Informatik studiert, theoretisch sollte Scripten/Programmieren also moeglich sein
- Privat bisschen mit 3D-Modellierung beschaeftigt (alles, was eher einfach und eckig ist, kriege ich hin - also z.B. Gebaeude!)
- Mit Texturen bin ich leider ziemlich schlecht
- Andere unterstellen mir, ich koennte Dinge ganz gut strukturieren bzw. in Ordnung bringen
- Leider nie genug Zeit und durchaus etwas sprunghaft
Ausserdem moechte ich Dir hier deine Frage aus dem anderen Thread beantworten, also wie ich auf das Projekt gestossen bin. Da kamen ein paar Dinge zusammen: Zum einen liebe ich Open World Spiele und Urban Exploring, zusammen bedeutet das also, dass ich urbane Open World Spiele liebe. Am Wochenende habe ich bei einem Freund zum ersten Mal GTA V ausprobiert und war von der groesse und dem Detailreichtum der Welt voellig ueberwaeltigt. Kurz darauf hatte ich einen Traum in dem ich mit demselben Kumpel anfing, Berlin digital nachzubauen. Gestern habe ich das einzige GTA, welches ich selbst besitze (San Andreas!), aus dem Regal gekramt und installiert. Daraufhin dachte ich, dass das Spiel grafisch simpel genug ist, als dass ein Berlin-Nachbau (genug Helfer vorausgesetzt) moeglich scheint. Daraufhin habe ich mich daran gemacht, herauszufinden, ob man GTA:SA modden kann, denn erst eine eigene Engine aus dem Boden zu stampfen waere Selbstmord. Dabei habe ich eine Seite gefunden, die beliebte Mods listet. Dort sah ich "gta:berlin" und musste laut lachen, da ich schon in der Vergangenheit nie der erste war, der eine Idee hatte. Auf der Seite angekommen war ich zum einen erstaunt darueber, was schon alles getan wurde, zum anderen etwas in Angst, als ich die Daten der letzten Veroeffentlichungen und Forenposts sah. Ich beschloss, mehr herauszufinden.
So, nun wuerde ich gerne noch ein paar weiter Fragen stellen:
- Gibt es eine Art Roadmap, also Zwischenziele, die man sich gesetzt hat? Soll z.B. erst ein bestimmter Bezirk fertiggestellt werden, dann zu einem angrenzenden uebergegangen werden?
- Wurden schon irgendwelche Zwischenziele erreicht?
- Was ist der Plan bzgl. der "Randbehandlung"? Sprich, wenn Berlin irgendwann modelliert sein sollte, was soll mit den Strassen und der Landschaft an den Grenzen Berlins passieren?
- Seid Ihr bereits auf die von der Stadtentwicklung bereitgestellten 3D-Modelle von Berlin aufmerksdam geworden? Koennen wir damit etwas anfangen? Da die Daten im proprietaeren DWG Format sind, weiss ich damit leider nichts anzufangen, aber im Prinzip scheinen diese Daten eine extrem vielversprechende Ressource zu sein, oder nicht?
- Wie kommt eigentlich die Infrastruktur zwischen all den Gebaeuden zustande? Wer modelliert die Strassen, Buergersteige, Plaetze, Parks? Oder soll das am Ende passieren? Woher kommen die (halbwegs) korrekten geographischen Hoheninformationen, oder wird das alles ueber den Daumen gepeilt?
- Gibt es in Eurem Mod bzw. in Euren Assets Platzhalter-Gebaeude, welche nicht fertiggestellte Gebaeude repraesentieren?
- Kann es sein, dass jedes Gebaeude Berlins eine Nummer im Liegenschaftskataster hat? In einem anderen Thread sah ich, wie jemand sich um "Nummer 205" beworben hat, ihm dann aber zu einer anderen Nummer geraten wurde. Ich kann nur vermuten, dass es sich um Gebaeudenummern handelt?
- Lassen sich die Strassen so zum Funktionieren bringen, wie das im original Spiel der Fall ist? Sprich, werden NPC-Autos sie (korrekt) befahren koennen?
- Gibt eine der Engines es her, die Stadt halbwegs realistisch mit parkenden Autos vollzustellen, oder wird man hier abspecken muessen? Werden NPCs in der Lage sein, Parkplaetze (korrekt) zu nutzen?
Ich bin sicher, dass ich noch viel mehr Fragen haben werde, aber das soll vorerst reichen. Mit meinem naechsten Post wuerde ich dann gerne auch ein paar Vorschlaege zur Organisation machen. Aber ich will hier auch nicht zu sehr mit der Tuer ins Haus fallen.
|
|
| Thema: Stand und Organisation des Projekts - Fragen und Anregungen |
|
|
Hallo gta:berlin Menschen!
Dieses Projekt sieht vielversprechend aus und es wird schnell klar, dass schon sehr viel Arbeit investiert wurde. Allerdings ist fuer mich derzeit voellig unklar, wie der Status des Projektes ist und wie es organisiert ist.
In einem anderen Thread habe ich gestern bereits nach dem technischen Workflow gefragt, doch eigentlich habe ich noch viel, viel mehr Fragen:
- Wie/wo ist der Stand des Projektes ersichtlich?
- Ist das Projekt nach wie vor als GTA:SA mod, oder inzwischen als GTA IV oder GTA V mod geplant?
- Wie/wo ist zu sehen, welche Dinge fertig, in Arbeit und noch zu tun sind?
- Wie stelle ich sicher, dass ich die Gebaeude in der richtigen Groesse und Form baue? Gibt's Grundrissdaten o.Ae., an denen sich alle orientieren?
- Welche anderen Datenquellen bzw. Ressourcen gibt es und werden genutzt?
- Was passiert mit fertiggestellten Objekten, wo landen diese, wo kann man sie finden?
- Welche Lizenz hat das Projekt bzw. die Assets? Public Domain?
- Gibt es eine Dokumentation, z.B. mit einer Anleitung, wie man sich einbringen kann?
- Gibt es Richtlinien bzgl. Texel Density, Poly Count und aehnlichen technischen Details?
- Gibt es noch andere Kommunikationskanaele, ausser dieses Forum? IRC vielleicht?
- Gibt es eine Hirarchie? Welche Rollen haben die auf der Website gelisteten "Teammitglieder"?
- Gibt es eine Liste aktiver Helfer inkl. ihrer Spezialisierung? (3D, Texturen, Scripts, Animationen, ...)
- ... und viele mehr.
Ich haette durchaus Ideen, wie man viele dieser Aspekte organisieren koennte, aber ich gehe davon aus, dass es bereits eine bestehende Organisation, also bereits bestehende Antworten auf die oben gelisteten Fragen gibt.
Leider habe ich keine Ahnung, wo ich diese finden kann. Zwar gibt es hier einige vielversprechende Threads, die verlaufen sich aber zumeist in off-topic Diskussionen.
Ich waere sehr froh, wenn jemand mich etwas an die Hand nehmen koennte und Antworten bzw. Hinweise zu einem Teil dieser Fragen geben koennte.
Danke!
PS: Ich wollte diesen Beitrag passenderweise im Bereich "Organisation" posten, doch dazu habe ich keine Berechtigung.
|
|
| Thema: Ein Anfaenger sucht nach dem Anfang |
|
|
Hallo Forum,
bin gerade mit Begeisterung auf dieses Projekt gestossen. Gerne wuerde ich, wenn die Zeit es mir erlaubt, etwas beisteuern. Allerdings ist das Thema GTA:SA Modding fuer mich komplett neu. Ich habe keine Ahnung von den involvierten Dateiformaten, dem Workflow, den benoetigten Tools, der Engine.
Nach laengerer Suche, sowohl auf der Projekt-Website als auch hier im Forum, konnte ich keine Anleitung finden, die einem Anfaenger wie mir den Einstieg in das Projekt ermoeglicht. Haette ich nur besser suchen muessen? Wenn ja, dann verweist mich doch bitte auf die entsprechenden Quellen. Oder sind hier alle erfahrene Modder, die solche Ressourcen gar nicht brauchen?
Falls relevant: Ich selbst arbeite mit freier Software, also bzgl. Modellierung mit Blender.
Danke im Voraus fuer alle Tipps und Tricks!
|
|
|
