 Stand und Organisation des Projekts - Fragen und Anregungen |
domsson
Grünschnabel
Dabei seit: 18.09.2017
Beiträge: 8
 |
|
| 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.
Dieser Beitrag wurde 4 mal editiert, zum letzten Mal von domsson: 19.09.2017 22:02.
|
|
19.09.2017 21:49 |
|
|
Trabbi 601s 
GTA: Berlin-Aktivist
  
Dabei seit: 07.01.2008
Beiträge: 1.054
Herkunft: Wohnhaft bei Stuttgart
|
|
| RE: Stand und Organisation des Projekts - Fragen und Anregungen |
|
Oha ich seh schon, du bist profi
also um es kurz und so richtig abschreckend zu gestalten: Es gibt praktisch keine Organisation 
aber zunächst eins nach dem anderen, ich werde einfach mal versuchen die Punkte in der Reihenfolge abzuarbeiten, in der du sie gestellt hast:
- Um den Stand zu visualisieren haben wir mal eine Zeit lang mit einer Openstreetmap gearbeitet. Hier zu finden , die dürfte sogar halbwegs aktuell sein.
- 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.
- Ob Dinge in arbeit oder fertig sind, sieht man am besten auf der OpenStreet Map, da haben wir versucht nen entsprechenden Colorcode zu etablieren
- Wir nutzen das Offizielle Liegenschaftskataster der Stadt Berlin, um Modelle passend zu erstellen. Wir haben eine Version, die in 3ds Max als importiert werden kann, die ist aber sehr alt und gerade an interessanten stellen, wie Potsdamer Platz oder Hauptbahnhof unbrauchbar. Deshalb behelfe ich mir persönlich meist, wie bereits erwähnt, mit dem offiziellen liegenschaftskataster, da mache ich mir dann einen Screenshot, messe die Maße aus, geht alles auf der Seite der Senatsverwaltung für Stadtentwicklung und Umwelt, und lege mir dass dann als Textur auf eine Fläche, sodass ich in Max dann damit arbeiten kann (Guter Punkt, vielleicht könnte man hierzu auch mal ein Tutorial schreiben)
- Was meinst du mit welche Ressourcen werden genutzt? Also was den Grundriss der Gebäude betrifft, wie gesagt: Liegenschaftskataster. Außerdem sind Bilder von Gebäuden essentiell, dazu kann man hier im Forum fragen und meist findet sich jemand, der dir Bilder macht, wenn du nicht aus Berlin kommst
(Das sind dann meist Dreyli oder ich) ansonsten alles, was man so finden kann, was für mich beim Hauptbahnhof beispielsweise relativ einfach war, bei anderen Gebäuden ist sowas schwieriger, aber auch sowas wie google earth kann ungemein helfen. Du kannst bei der Nachbidldung von Gebäuden natürlich auch kreativ werden und musst dich nicht 1:1 ans original halten. Mir fehlt dazu meist die Kreativität, aber solange ein Gebäude von Form und Stil an die entsprechende Stelle passen, spricht da nichts gegen
- 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. Sobald man nämlich Daten bereitstellt, müssen diese gepflegt werden und man müsste sich Gedanken um die Sicherheit machen. dazu fehlen aktuell die Ressourcen. Gerne kann man mich aber per Mail oder PN kontaktieren, dann schau ich was sich machen lässt
- Soweit ich weis nutzen wir die Creative Commons Lizens. hab mich aber im Detail nie so wirklich damit auseinander gesetzt, dazu sind beispielsweise JPM und JKM die Profis.
- Eine Dokumentation gibt es (leider) nicht, was auch mangelnden Ressourcen geschuldet ist.
- technische Restriktionen haben wir abgesehen von unseren Modellrichtlinien keine. Prinzipiell gilt beim Polycount: "So viel wie nötig, so wenig wie möglich" also an sich sind reine polygone kaum ein problem, wobei wir mit Dreylie 2 Millionenkollos schon einige schwierigkeiten hatten. ich werde hierzu aber mal noch eine art stresstest durchführen, um den Flaschenhals in der Engine zu entdecken.
- Das Forum ist unser Hauptkommunikationskanal, ansonsten sind wir teilweise noch privat vernetzt. (was ist IRC?)
- Aufgrund dessen, dass wir mittlerweile auf ein absolutes Minimum geschrumpft sind, ist eine Hierarchie nicht notwendig. Fragen zur Map hab ich beispielsweise in der vergangenheit entschieden, weil ich es halt gemacht habe, das wurde dann im Forum bestenfalls besprochen, aber an sich würde ich uns sehr unhierarchisch beschreiben. Die Rollen im allgemein sind eher noch so ein relikt. JPM und JKM sind Administratoren, weil sie früher die Hauptorganisation übernommen haben, brik hat sich meist um die technischen seiten des Forums usw. gekümmert, der Rest gilt soweit ich weiß als "Aktivist" was so viel heißt , dass wir aktiv am Projekt mitarbeiten. (Man verbessere mich gerne, wenn jemand das anders sieht)
- Eine Liste mit aktiven gibt es nicht, sie wäre aktuell auch sehr kurz: Grundlegend kann man sagen: Dreyli - einer unserer fleißigsten Modelierer aktuell, hat viel rund um den Zeitenplatz/U-Bhf Mohrenstraße, sowie die sog egnannten Edelplatten gemacht (probs an dich
) er ist auch der Profi, was sketchup und von Sketchup ins spiel betrift, dann ist da noch MoeRon - GTA:Berlin Urgestein und verantwortlich für fast alles rund um das Brandenburger Tor und den Tiergarten (probs gehen auch an dich
), JPM und JKM - ebenfalls Urgesteine und haben einiges rund um den Spreebogenpark verbrochen (ich warte immernoch auf das Nordufer
) früher für die Map verantwortlich und dann ist da noch meine Wenigkeit - Mein Gebiet sind HBF und seine Umgebung, außerdem Kümmere ich mich darum, die Engine zu verstehen und die Objekte ins Spiel zu bringen, zumindest in der Theorie, außerdem hab ich unsere Facebookseite verbrochen. War jetzt die letzten Monate sehr inaktiv weil ich aus dem Unistress nicht mehr raus kam, aber kann hoffentlich nach meiner Masterarbeit wieder aktiver werden 
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, als Themen, mit denen ich mich eh schon andauernd beschäftigen muss. Prinzipiell bin ich aber für jeden Vorschlag und Hilfe offen, die die nachhaltige Organisation des Projekts verbessern. Jedoch sollte man auch immer bedenken, dass wir aktuell nur ne handvoll Leute sind, die das ganze zum Spaß nebenbei machen. Es gilt also immer darauf zu achten kein unnötigen Verwaltungsoverhead zu schaffen.
So ich hoffe ich hab deine Fragen beantwortet. Freue mich natürlich auf weitere diskussion
|
|
|
20.09.2017 11:07 |
|
|
domsson
Grünschnabel
Dabei seit: 18.09.2017
Beiträge: 8
Themenstarter 
|
|
| RE: 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.
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von domsson: 03.10.2017 15:38.
|
|
|
21.09.2017 00:11 |
|
|
Dreyli
GTA: Berlin-Aktivist
Dabei seit: 11.04.2014
Beiträge: 303
Herkunft: Berlin
|
|
Hi, freut mich dass du Interesse am Projekt hast; bzw. es dir in einer Prophezeiung erschienen ist
Mal abgesehen, dass man mit Modellen immer Unterstützung leisten kann findet man tatsächlich wenig Anhaltspunkte darüber wo es aktuell brennt.
Na dann mal zu deinen Fragen:
Roadmap: da wir im Moment eher unregelmäßig Zeit haben ist das Thema schwierig; als Ziel hatten wir eigentlich zum Ende letzten Jahres eine neue interne Version; Aber das ist dann wegen krassen Performance Problemen gescheitert und generell wegen der wenigen Zeit
Man kann aber sagen dass die map erstmal nicht noch größer werden soll; von Randbezirken und Umland mal ganz zu schweigen; es gibt ja jetzt schon genug Probleme oder Sachen die man nacharbeiten muss
3d Modelle Stadtentwicklung: die sind mir auch schon mal über den Weg gelaufen, wusste aber nicht dass man die downloaden kann; Sind die denn texturiert und wie verhält es sich mit dem Detailgrad? Als Lückenfüller spricht nichts dagegen denke ich; Rolf und ich hatten auch schon in solche Richtung gedacht; als Rohmaterial zum modellieren brauche ich sowas nicht; wenn die echt gut vom Detailgrad passen würden und nur noch texturiert werden muss warum nicht; wie sieht es mit der Lizenz aus?
Infrastruktur: grundsätzlich sollen die Blöcke mittlerweile inklusive Gehweg, Innenhof etc. Erstellt werden; so dass man sich die Blöcke zurecht schiebt und dann nur noch die Straße anpassen oder bauen muss; so ist dann auch sichergestellt, dass Einfahren etc. Vorhanden sind;
Soll aber nicht heißen dass man alle Gebäude eines Blocks schaffen muss; wir freuen uns aber über jedes Gebäude, das nutzbar ist!
Kataster: Glaube nein, Find ich aber klasse Idee
Engine: von den Funktionen müsste alles möglich sein hinsichtlich Verkehr; Kfz Pfade definitiv;
die Engine gerät an ihre Grenzen; wir müssen abspecken!
Gilt mittlerweile auch für den polycount; werde fast alle meiner alten Modelle nochmal verkleinern müssen
Ich hoffe ich konnte dir weiterhelfen
; ich habe im Moment sehr wenig Zeit und nur Handy Internet, werde also nicht schnell antworten können :-/
|
|
|
02.10.2017 22:30 |
|
|
domsson
Grünschnabel
Dabei seit: 18.09.2017
Beiträge: 8
Themenstarter
|
|
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. :-)
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von domsson: 17.10.2017 22:10.
|
|
|
17.10.2017 22:03 |
|
|
domsson
Grünschnabel
Dabei seit: 18.09.2017
Beiträge: 8
Themenstarter
|
|
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.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von domsson: 19.10.2017 10:30.
|
|
|
19.10.2017 00:47 |
|
|
MoeRon
Die BM Waffe =D
Dabei seit: 03.10.2006
Beiträge: 609
Herkunft: NRW
|
|
|
|
21.10.2017 18:13 |
|
|
Dreyli
GTA: Berlin-Aktivist
Dabei seit: 11.04.2014
Beiträge: 303
Herkunft: Berlin
|
|
Inzwischen hab ich wieder Internet und auch zeitlich so langsam wieder minimal Luft zum Atmen. Dann prescht aber noch knallhart mein aktueller Elex-Hype dazwischen
Aber bevor ich hier gänzlich abschweife nun zu deinen Vorschlägen, bzw. mal schauen wie weit ich jetzt kommen werde:
Man sieht schon mal dass du viel investiert hast und dir einiges an Gedanken gemacht hast! Coole Sache, freut mich sehr wenn neue Leute Herzblut in die Sache investieren 
kommst du aus Berlin oder Umland?
zu 1.
Beim Enginewechsel hat man natürlich das Problem, dass viele Arbeitsschritte um sonst waren. Modelle, die eine veralteten Detailgrad haben werden aber belassen. Das liegt neben emotionalen Gründen des Respekts vor allem daran, dass es eine schiere Unmenge an Gebäuden ist, die allein in Mitte stehen, daneben Untergrundbauwerke u.v.m.. Würde man jetzt anfangen alles alte neu aufzulegen würde man sich im Kreis drehen. Über den Ersatz alter Gebäude wird daher als aller letztes nachgedacht. Es gibt einfach noch so viel Freiraum mit tollen Lagen/Objekten die erstellt werden können. Auch von der optischen Seite ist das nicht unbedingt so ein großes Problem. Ich find die Abwechslung bringt viel Charme und Atmosphäre rein; irgendwie wie im echten Berlin früher, wo Prunkbauten neben (in dem Kontext überspitzt) Ruinen standen.
Das Thema mehrere LOD's ist einfach ein Aufwandsproblem. Ich zB. hab zu jedem meiner Modelle ein sehr detailarmes LOD erstellt, was ja so noch recht einfach machbar ist. Blos das mittlere LOD sprengt einfach in krasser Weise den Rahmen; da es so erstellt werden muss, dass es gleichzeitig als Kollision dienen kann (das wäre jedenfalls ein sinnvoller Ansatz). Multipliziert man das mit der größe und komplexität einiger Blöcke (und Designstrukturen) und der Anzahl der Blöcke die man auf der Agenda hat ist das mal eben als Hobby kaum noch zu verwirklichen. Man muss sich ja immer eines klar machen, es handelt sich nicht um Arbeitsstrukturen; wir haben alle noch anderes zu tun. Unter diesem Kontext muss man also dafür sorgen dass die Motivationsstufe immer erhalten bleibt. Man kann anderen oder sich selbst nicht immer mehr "Drecksarbeit" aufladen, davon gibt es ja eh schon genug. Ganz klar, könnte man die verschiedenen Arbeiten auf mehreren Schultern verteilen, würden das viel bringen. Das von einem (neuen) Modeler zu erwarten ist überambitioniert.
Hinsichtlich eines generischen 3D Modells von Berlins gibt es gar keinen großen Ansatzpunkt, bzw Veränderungsbedarf. Die 3D Map ist ja jetzt in die einzelnen Ortsteile/Bereiche von Mitte als Max-Datei untergliedert und damit maximal unterschiedlich einsetzbar.
Geht man den Weg anderer (WIP) Engines befürchte ich, dass der Fokus dessen, was wir mit diesem Projekt bezwecken wollen, bzw. wofür es steht, verloren geht und entsprechendes Enginprojekt im Vordergrund steht. Zumal man sich komplett abhängig macht. Eine Morrowind Engine kann nicht funktionieren, da die Anforderungen an diese ganz andere sind. ZB. werden Innenräume nicht mitgeladen. ES müsste schon eine moderne GTA-Engine oder sowas wie Unity sein. Allein wie die GTA IV Engine mit dem Mod (gerade im Hinblick auf die vielen unterschiedlichen Texturen) parallel zur Orginalmap umgeht und wie sich die Performance dabei verhält ist beeindruckend.
2. und 3.
Das ganze klingt mir eher nach open source. Naja ich sehe das genauso wie Moe. Ich hab an meinen Modellen so viele von 100 erten Stunden gearbeiten. Ich will nicht, dass die Modelle für etwas anderes als für ein GTA-Berlin genutzt werden und irgenwo anders auftauen. Keiner hätte mehr einen Überblick. Oder wenn sich Leute mit fremden Federn schmücken (ist mir direkt schon passiert!). Ein weiterer Punktsind die Modelle der inaktiven Nutzer. Über Ihre Köpfe hinweg die Sachen freizugeben, die Sie persönlich übergeben haben, wäre zumindest ein Vertrauensbruch. Ich find die Struktur von Mitgliedern und Aktivisten schon sehr gut.
Copyright ist anhand dessen schon stark beschränkt. Dazu kommt schon mal die Copyrightbestimmungen der einzelnen Programme die wir nutzen dürfen. ZB kostenloses Sketchup.
4.
Die Gebäude/Blöcke sind einzelne Dateien. Sie werden dann zusammengeführt in eine Mapping-Datei pro Bereich. Das funktioniert soweit gut. Probleme liegen da eher in den Details (meine Mapingdatei läuft grad nicht
) und dem danach fortlaufenden Arbeitsprozess. Leute können etwa im .dae Format Objekte abgeben und wir können damit umgehen. Eine aktuelle Darstellung des Standes der Karte muss geliefert werden.
Ein zugängliches Texturarchiv finde ich sinnvoll aus den von dir genannten Gründen. Namen müssen bestimmten Vorgaben folgen. Aber gepflegt werden sollte dieses nur von Aktivisten u.ä..
6. Als Informationsquelle mag ich die Seite hier sehr. Man kann sich lange und intensiv informieren und findet immer wieder spannendes. Nur schnell geht das natürlich nicht. Da müsste man klar nachbessern und bestimmte wichtige Informationen separat bereit stellen. Da kommen wir aber wieder an den Punkt der fehlenden Kapazitäten für solche Aufgaben.
Deswegen muss man das Projekt insgesamt attraktiver machen...wie auch immer...Ich bin zB. im World of Players Forum auf eine 3D ecke getroffen, wo auch Wettbewerbe u.ä. statt finden. Vielleicht könnte man diese Leute für ein bisschen Unterstützung begeistert.
An der Stelle eine kleine Ankündigung: Ich habe einen aktuellen Trailer gemacht (jetzt schon zum zweiten mal). Nur leider halt mit Freware; Export bisher fehlerhaft. Das wird aber schon
...
Man muss wirklich lernen einen Cut zu machen. Mitte ist groß genug und der Mod würde damit schon echt geil sein. Eine Stadt wie ganz Berlin nachzubauen ist utopisch.
Man kann ohne viel Manpower auch nicht alles über den Haufen werfen. Daran kann das Projekt nämlich sogar scheitern. Als Fazit muss an vielen Ecken was verbessert werden. Die Grundprozesse sind aber nicht verkehrt. Vielmehr hapert es an dem "wie" der Umsetzung, der Kapazität der Leute und der Nachvollziehbarkeit der Prozesse im kleinen und großen.
...
Das 3D-Stadtmodell Berlin find ich ja mal der Hammer 
; 3ds ist auch gut! Ich bin mir sicher, dass wir das gebrauchen können. Ich werd mir die Daten demnächst mal einkrallen 
| Zitat: |
| Es gibt nicht wirklich Performance Probleme. Jeder im Team hat strenge Vorgaben wie viele Polygone er verbraten darf und die von denen du warscheinlich gehört hast kamen dadurch das Gebäude unoptimiert mal in der Engine getestet wurden um ihr Wirken zu testen. |
Jetzt wo du es sagst... optimiert ist es in der Tat noch nicht; Gescheitert ist diese Version trotzdem daran
es hat sich halt gezeigt dass nachgearbeitet werden muss und einige Einstellungen nicht richtig vorgenommen worden sind; insgesamt kann mans aber mal wieder unter "Kapazität" verbuchen;
Dennoch steht die Frage im Raum, wie weit geht die GTAIV Engine mit und reicht dafür die Optimierung, bzw. wie weit muss man downgraden; GTA IV ist nun mal nicht zeitgemäß; ich denke nicht dass die Engine eine komplett gefüllte Map mitmachen würde.
Dieses Problem stellt sich jedoch nicht; und wenn es sich stellt haben wir auch andere Technik!
Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von Dreyli: 21.10.2017 23:20.
|
|
|
21.10.2017 21:32 |
|
|
domsson
Grünschnabel
Dabei seit: 18.09.2017
Beiträge: 8
Themenstarter
|
|
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!
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von domsson: 21.10.2017 22:07.
|
|
|
21.10.2017 21:58 |
|
|
Trabbi 601s
GTA: Berlin-Aktivist
Dabei seit: 07.01.2008
Beiträge: 1.054
Herkunft: Wohnhaft bei Stuttgart
|
|
Sooo jetzt melde ich mich auch mal zu Wort, da ich denke, dass ich für einige Sachen mitverantwortlich bin, dass sie aktuell sind, wie sie eben sind. Vorweg sei gesagt, dass ich die letzten 3-4 Posts teilweise nur überflogen hab, aber mir jetzt schon genug einfällt, daher bitte ich bei Bedarf um Korrektur
Zunächst einmal die Sache mit dem Zugriff:
Ich hatte mal alles in ne Cloud gepackt, zuerst Dropbox dann OneDrive. Dadurch konnte jeder, der den Link hatte, in den daten stöbern einfach alles herunterladen und die Daten waren dadurch praktisch zugänglich. Mir ist Anfang des Jahren dann aber auf beiden Anbietern jeglicher Speicher verloren gegangen, den ich durch diverse Sonderaktionen zeitlich begrenzt bekommen hatte. Darauf hin musste ich leider wieder alles aus dem OneDrive raus holen, da ich es auch sonst nicht mehr für meine privaten Zwecke hätte nutzen können. Ich hatte Überlegungen eine eigene Cloud aufzusetzen, das scheiterte aber bisher sowohl an zeitlichen, wie auch an technischen Ressourcen. Aktuell hab ich Überlegungen, ob ich einfach etwas Geld in die Hand nehme und etwas OneDrive speicher kaufe, da ich das an sich auch privat ganz gerne nutze, dann wäre das mit GTA:Berlin auch kein Problem, das wäre allerdings etwas, was man zunächst im kollektiv entscheiden müsste, da ich auch verstehen kann, wenn von einigen da Sicherheitsbedenken kommen.
Dann hatte ich ja dieses Jahr unter anderem so wenig Zeit, weil ich meine Masterarbeit geschrieben habe. Warum erzähle ich euch das? nun weil ich mir ein Thema ausgedacht habe, was möglicherweise auch GTA:Berlin zu gute kommen könnte. Und zwar ist hierbei ein System entstanden, welches die nahtlose und plattformunabhängige Zusammenarbeit mehrerer Beteiligter in 3D-Umgebungen ermöglicht. Ich könnte das System anpassen und weiterentwickeln, dann ließe sich das bestimmt auch hier nutzen. Hier ist einfach mal ein Video vom Prototypen bei der Arbeit mit Unity3D und 3dsMax (sorry für die Kartoffelqualität 
) Hier gehts zum Video
Bei bedarf, kann ich das ganze auch noch mal genauer ausführen.
Eine Versionskontrolle halte ich an der stelle auch nicht für sinnvoll, da wie Moe schon andeutete das ganze für Modelle nicht gut funktioniert, was ich aus der Erfahrung mit einigen kollaborativen Unity-Projekten bestätigen kann. Daher kam auch der in meiner Masterarbeit umgesetzte Ansatz, welcher auch das Laden eines früheren Zustands eines Modells ermöglicht
Zu der Sache mit der Engine:
Wir wurden schön öfter gefragt warum GTA IV und nicht V. Und auch hier klingt die Antwort erst mal sehr doof: Weil mit GTA IV mehr möglich ist. Ich habe mich zuletzt im Frühjahr/Frühsommer mit dem Modding von GTA V befasst und ja: es mag sein, dass es leichter ist Skripte und so zu erstellen. Aber Mapmods, wie wir es hier machen, sind einfach aus der Mode gekommen und das Merkt man. We gesagt ich bin noch auf dem Stand von vor einem halben Jahr, aber bis dahin war es nicht möglich mit GTA V KArten antiv in die Engine einzubauen. Alle "Mapmods" waren eigentlich nur Kulissen, welche mit Hilfe von FiveM geladen werden mussten. Das hilft uns nicht weiter diese Mods sind in meinen Augen die reinsten Blender. Du kannst nämlich nicht wirklich mit der Engine Arbeiten und das ist schade. ich hatte bis dahin noch keinen Verkehr irgendwo gesehen, geschweige denn so Spielereien wie die Fontäne vor der Bauakademie, die ich testweise mal eingebaut habe. Es existierten bin Dato einfach nicht die entsprechenden Tools um eine solch Komplexe Map in GTA V umzusetzen. Und von der Ganzen Dateistruktur von GTA V will ich gar nicht erst anfangen... das ist echt ein graus... Ähnlich wie die Anderen sehe ich auch einen Weggang von GTA. Aktuell haben wir eine gemeinsame Basis und ein gemeinsames Ziel: Wir mögen GTA und wollen in Berlin spielen. Außerdem müsste man sich dann überlegen was macht man mit der Spielwelt. Wir hätten dann eine leere karte keine Spiellogik und Ähnliches. In GTA bringt einfach nur eine Karte schon den Vorteil, dass es schon spannend sein kann einfach eine Verfolgungsjagd durchs Regierungsviertel oder so zu veranstalten, außerdem lässt sich so vorhandene Elemente, wie Skriptschnittstellen und Spiellogiken, wie Rennen, einfach verwenden und so Content schaffen, ohne dass wir selber uns noch Gedanken um Logik machen müssen. Und dann ist da ja noch die Sache, die Moe angesprochen hat, bezüglich vorhandener Modelle und derer Lizenzen. Diese Creator haben uns ihre Werke gegeben um ein GTA in Berlin zu schaffen und nicht am ende was eigenes groß zu ziehen. Außerdem um die ganze Lizensdebatte abzuschließen: ich habe ehrlich gesagt wenig Lust von jedem einzelnen die Rechte abzufragen und ggf. individuell zu behandeln. Entweder wir arbeiten auf einer gemeinsamen Lizensrechtlichen Basis (Nutzung für GTA okay, alles andere erfolgt in absprache mit dem entsprechenden Creator) oder wir können es gleich lassen.
An sich finde ich auch die Idee gut, ein gemeinsames Asset-Set zu schaffen, weölches dann in jeder Beliebigen Engine genutzt werden kann, das hatte ich auch schon einmal versucht, jedoch ist das so nicht möglich. Das liegt vor allem daran, dass die Modelle einfach zu sehr spezialisiert werden müssen, hinsichtlich Texturen, Materialien und manchmal auch aufbau. Der Aufwand würde mit sowas also nur noch weiter steigen, ohne das ein Merklicher Mehrwert da ist; und das Mapping is so schon aufwendig und unspannend genug.. 
Die Sache mit der Kommunikation:
Das Problem ist, dass allgemein nicht viel passiert, ansonsten währe es wahrscheinlich ersichtlicher, wie wir uns abstimmen und kommunizieren: Nämlich ganz öffentlich in den Threads dieses Forums, wozu es auch da ist. Hier stellt jeder sein Werk vor, hier werden absprachen getroffen und anfragen beantwortet. Ich halte das an sich für einen guten Ansatz, da es somit eigentlich für jeden ersichtlich sein sollte.
Das führt mich auch gleich zur Öffentlichkeitsarbeit:
Ursprünglich war mal folgende Detailabstufung in den einzelnen Kanälen geplant:
Forum - Hier findet man alles ganz genau, diskussion immer das neuste, man muss sich halt reinfuchsen
Facebook - Für leute die am Mod und dessen Entwicklung Interessiert sind, hier werden auch Projekte gezeigt, welche WIP sind, dabei aber lange nicht so detailreich, wie eben hier im Forum
Homepagenews - Hier werden eigentlich nur fertige Sachen gezeigt, bzw. Konkrete Fortschritte, sehr grob, dafür sollten das dann auch definitive Informationen sein.
Hier muss ich leider Zugeben, dass ich mich da ein bisschen übernommen habe. Ich hatte in der Zeit meines Bachelors relativ viel Zeit und auch Motivation für den Mod, entsprechend viel habe ich angefangen: Ich hab die Map damals neu aufgerollt, hab mich ein bisschen um die Organisation gekümmert, dann kam Öffentlichkeitsarbeit in Form der Facebookseite, sowie die News auf der Homepage dazu usw. Und dann hatte ich ja noch meinen Hauptbahnhof mit Umgebung. Dann kam leider in den Letzen zwei Jahren der Dampfhammer und ich hatte Studiumsbedingt kaum noch zeit und im letzten bisschen Zeit hab ich mich meist mit der Zwerpflückung der Engine beschäftigt.. Das zerrt an den Nerven und der Motivation, an dieser Stelle ist es vielleicht angebracht mich nochmal beim Team zu entschuldigen, dass ich euch da vielleicht im Stich gelassen habe
Das ganze gipfelte jetzt darin, dass ich dieses Jahr so gut wie gar keine Zeit mehr hatte...
Abschließend noch Perrformanceprobleme:
Ich glaube Moe hatte nie die aktuelle Testversion von Dreyli und mir gespielt. Wir hatten hier bei den aufwändigen, wie schönen Blöcken von Dreyli leider einige Einbrüche in der Framerate. Das Problem hierbei liegt, dass ich noch nicht ganz hinter das LOD System der Engine gekommen bin. Ich hab mir jetzt mal überlegt, und das werde ich als nächstes auch mal angehen, dass ich mal einen eigenen Bereich basteln werde, um eben mal das Lod System anständig erforschen zu können. Ich hatte das sonst immer an bestehenden bereichen versucht, was aber Käse ist, weil wegen der Komplexität die Fehleranfälligkeit zwischen einzelnen Tests zu groß ist. Außerdem wollte ich mal noch einige stresstests mit der Engine machen, um herauszufinden was die Engine in die Knie zwingt, ob Polygone, Materialien, Shader oder doch was ganz anderes, das wird spannend aber auch ein langes Wochenende
So ich glaube das waren zunächst alle meine Gedanken, ich hoffe das Hilft so erst mal weiter. Es freut mich auf jeden Fall riesig eine solche Diskussion zu sehen
Danke allen Beteiligten und vor allem dir domsson, dass du sie so strukturiert angestoßen hast!
|
|
|
21.10.2017 23:47 |
|
|
brik
.
Dabei seit: 01.10.2006
Beiträge: 249
Herkunft: Berlin
|
|
Ich deraile jetzt einfach mal schamlos, Trabi, witziges Synchronisierungstool! Hast du dir fuer die Datenuebertragungsschicht was einfallen lassen, oder wird immer die ganze Szene synchronisiert? Letzteres waere dann wahrscheinlich eine ganze Stange Traffic, und bedeutet wahrscheinlich relativ lange Latenzen, wenn man nicht lokal synchronisiert, oder?
|
|
|
22.10.2017 13:23 |
|
|
Trabbi 601s
GTA: Berlin-Aktivist
Dabei seit: 07.01.2008
Beiträge: 1.054
Herkunft: Wohnhaft bei Stuttgart
|
|
also die Daten werden in einem XML Format übermittelt. Die Daten werden von den einzelnen Clients an den Server übermittelt, der Verarbeitet diese und verteilt sie dann wieder an die übrigen Clients. Die Szenendaten, also Lage der Objekte, Hierarchie usw. werden in einer Datenbank gespeichert, die Modelle werden in einem OBJ Format abgelegt. bei jedem neu übermittelten Stand eines Modells wird eine neue Datei angelegt und in der Datenbank wird hinterlegt wie die Datei heißt und wann sie erstellt wurde, dadurch lassen sich frühere Stände einfach wieder laden. Tatsächlich war Performanz nicht zwangsläufig das Nummer eins Kriterium aber es läuft recht flüssig, gerade was die Ausrichtung der Modelle betrifft, aber es besteht an vielen Stellen natürlich noch Optimierungspotential, klar handelt sich hier ja auch zunächst nur um einen Prototyp mit der absoluten Kernfunktionalität. Man kann übrigens auch eine Art Ticketsystem noch in das ganze einbauen, das wurde schon alles entworfen und auch teilweise vorbereitet, ist aber noch nicht implementiert, hab mal ein bild angehängt, wie sowas aussehen könnte.
Trabbi 601s hat dieses Bild (verkleinerte Version) angehängt:
|
|
|
22.10.2017 16:04 |
|
|
domsson
Grünschnabel
Dabei seit: 18.09.2017
Beiträge: 8
Themenstarter
|
|
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. :-)
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von domsson: 30.10.2017 20:37.
|
|
|
30.10.2017 20:32 |
|
|
Dreyli
GTA: Berlin-Aktivist
Dabei seit: 11.04.2014
Beiträge: 303
Herkunft: Berlin
|
|
| Zitat: |
| Bedeutet das, gta:berlin hat bisher kein LOD genutzt? Wieviele LOD-Stufen haben die GTA IV-Assets? |
Es werden schon LOD's genutzt, diese funktionieren nur leider nicht richtig. LOD's werden auch nur für einige modernere Modelle genutzt soweit ich weiß.
was genau meinst du Arbeitsabläufe oder bereits geschaffene Arbeit/Stand? Ansonsten von meiner Seite: Frag, soweit es mir möglich ist, will ich dir Antwort geben.
| Zitat: |
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.
|
Tja das ist in der Tat nicht so ohne weiteres zu beantworten. Wahrscheinlich kann das vollumpfänglich nur Rockstar beäntworten. Ich selber habe noch einige offene Fragen. Ich könnte dich/andere nur an meinen Erfahrungen teil haben lassen.
| Zitat: |
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.
|
• Mail/ grds flexibel
• Anfrage, bzw. entsprechenden Thread aufmachen; Vorher muss aber geguckt werden, ob entsprechendes Gebäude schon im Showroom oder WIP Gebäude enthalten ist
• naja man kann Kartasterkarten nehmen oder man lässt es halt sein. Dadurch, dass die Blöcke sammt Gehweg auf den Straßen landen kann man dann noch gut anpassen. Soll heißen, ich habe mit google auch gute Ergebnisse
• relativ hoch; aber die Map steht im Vordergrund, nicht das Modell; also nicht zu Detailverliebt... bzw. wie soll man diese Frage beantworten? ein paar 10.000 pro Gebäude... kleines Gebäude...großes mehr... würde ich sagen
LG
|
|
|
03.11.2017 22:32 |
|
|
zeppelin
Mitglied
Dabei seit: 17.09.2009
Beiträge: 28
Herkunft: Österreich
|
|
Ein paar Screenshots, auf denen man den optimalen Detailgrad erkennen kann, wären sehr hilfreich. Eventuell auch Beispiele von schlechten Modellen (zu wenig/zu viele Polys, schlechte Texturen etc.). Das gleiche gilt für LOD's.
Oder gleich ein fertiges Gebäude im Soll-Zustand (auch in Bezug auf Namensgebung, Ordnerstruktur), das von jedermann heruntergeladen und als Referenz verwendet werden kann.
|
|
|
04.11.2017 14:26 |
|
|
|
