![]() |
Deshalb habe ich auch nur auf das klassische Autogen verwiesen denn das beinhaltet auch keinerlei direkte Positionsinformationen wie bei den XML Objekten.
Das was Horst beschreibt ist wieder ganz etwas anderes welches eigentlich nicht unbedingt sinnvoll ist zwecks Gebäudepositionierung. Das dürfte alles nicht das sein was CN wollte. Ich denke er wollte schon die klassische Autogentechnik nutzen denn ist am effizientesten wenn man nur einfache Objekte benötigt. Nicht umsonst kusierte der Tipp das man die default.xml des FS2004 deaktivieren sollte um mehr Performance zu haben. Auch Vectorautogen gab es ja schon Empfehlung dieses zu deaktivieren. Man muß halt nicht unbedingt Straßenlaternen usw. bzw irgendwelche Kirchen oder Umspannwerke in der Scenery haben. Alles Geschmackssache. |
Hier haben sich ein paar Missverständnisse ergeben:
Mit chaotischer Verteilung meine ich die Definition der Standard Landclass-Dateien, die fast garnichts mit dem realen Vorkommen von Gebäuden an den entsprechenden Orten zu tun hat. Das die Obejekte dort eingefügt werden wo sie definiert wurden, ist schon klar. Das Problem ist eben, dass die Objekte auf Texture-Ebene und nicht ortsbezogen definiert werden. Letztendlich möchte ich einige AutoGen-Gebäude löschen, dafür aber andere dort hinzufügen wo in der Realität entsprechnde markante Gebäude stehen. Weiterhin möchte ich nicht nur den Gebäudetyp sondern auch das Objekt selbst bestimmen. Soweit ich das verstanden habe, muss man für eine ortsbezogene Definition von Objekten eine entsprechende Definitionsdatei anlegen bzw. vom Attonator anlegen lassen, die dann entsprechend einer Texture zugeordnet wird? Das Problem das bwuno ansprach, d.h. schlechte Performance durch zu viele Objekte, kann bei der von mir geplanten Vorgehensweise eigentlich nicht auftreten, denn ich möchte die Anzahl der AutoGen-Objekte nicht wesentlich erhöhen, ich möchte die Objekte einfach nur realistischer platzieren bzw. Objekte benutzen, die den real vorhandenen Gebäuden näher kommen. Im Moment scheint mir fogende Vorgehensweise die beste zu sein: Die Standard FS-Texturen verwenden, hierfür dann ein entsprechendes ortsbezogenes AutoGen erstelle. Sollte man wirklich keine Möglichkeit haben, einzelne Objekte definieren zu können, müsste man dann hier entsprechend sowas wie SBuilder verwenden. Der einzige Nachteil wäre, dass sich die Gebäude auf den Texturen, dann an anderen Stellen als die AutoGen-Objekte befinden würden. MfG. C.N. |
Hallo
@ C.N. Sorry für die Verwirrung! Deine derzeit „beste Vorgehensweise“ wird dich leider nicht zum Ziel führen! @ Bwuno Probiert oder vermutet? Ich denke nicht das Chris Wright oder Luis Sa gelangweilte Softwareentwickler sind, die sich auf einen Holzweg befinden. Horst |
CN
Dein leztes Posting hört sich jetzt auch anders an als am Anfang des Threads. "Mit chaotischer Verteilung meine ich die Definition der Standard Landclass-Dateien, die fast garnichts mit dem realen Vorkommen von Gebäuden an den entsprechenden Orten zu tun hat." Autogen bei Landclasstechnik ist wie gesagt direkt Texturbezogen. Mittels Landclassystem werden diese Texturen in der FS Welt positioniert und damit natürlich dessen Autogen. Da so eine Textur bzw. dessen Autogen weltweit zum Einsatz kommt nützt Dir das Autogen von dem wir gesprochen haben überhaupt nichts. Denn wenn Du etwas änderst dann tritt dieser Effekt ev. weltweit ein. Deine Autogenänderung kannst Du dann auch in einem anderen Land sehen. Damit ist Dein Satz: "Im Moment scheint mir fogende Vorgehensweise die beste zu sein: Die Standard FS-Texturen verwenden, hierfür dann ein entsprechendes ortsbezogenes AutoGen erstelle". technisch nicht realisierbar zumal jetzt im Gegensatz zu Deinem ersten Thread die Objekte denen der Realität näher kommen sollen. Nach Deinem letzten Thread würde ich sagen kommst Du nicht drum hin einen Weg zu gehen wie ihn Holger vorgeschlagen hat. Ev. unpassendes Standard Autogen musst Du excludieren. |
Hallo, habe wohl versehentlich zwei Usernamen (bwun und bwuno), bin aber immer noch der selbe und keine gespaltene persönlichkeit! Zu meinem Beitrag:
Natürlich habe ich das getestet. bis zu einer gewissen zahl (mehr als Zehntausend Objekte)kann man den performance-abfall noch hinnehmen, dann fängt aber irgendwann die Dia-show an. Erstelle dir einfach eine XML-Datei, kopiere und füge in Ihr Objekte ein, so kommt man relativ flott auf ein paar hundert. (Wenn man erst mehrere Dateien erzeugt und dann durch suchen ersetzen jeweils verschobene Koordinaten erzeugt, die Inhalte in eine Datei kopiert, kriegt man dann noch mehr). Die XML-Dateien können schon ein paar hundert kilobyte bis über ein bis drei megabyte groß sein, ist aber schon ein paar monate her, dass ich das getestet habe, und weiß jetzt nicht genau wie groß die dann (z.B. 20000 Obj)sind. ... und man wird feststellen, dass fs2004 seine unumgänglichen grenzen hat. Habe alle Foren abgesucht nach infos wie man das problem lösen kann und selbst probiert... geht irgendwie nicht. Es legt die Flusi lahm. Für bereiche um Flughäfen könnte man das ja machen, aber es gibt noch weitere nachteile, die auf der hand liegen (falsche maße der häuser, etc.) Und dabei hatte ich so tolle ideen und war meinem wunschflusi so nah... :( gruß bwun/bwuno |
Hallo bwun/bwuno (ist dies dein Vorname?)
Danke für die Antwort. Da gibt es bei weitem mehr Grenzen in aircraft und scenery design (und vor allem das Zusammenspiel), die deinen FS in die Knie zwingen und eine Dia Show veranstalten! Gerade rund um große Flughäfen ist dies sehr problematisch. Abgesehen von den Programmen, die im Hintergrund laufen. (Dies wäre eine „Framerate“-Diskussion, die ich immer meide). Aber mit einem Versuch (oder einer Grenze) würde ich mich nicht von der Vorstellung meines Wunschflusis abhalten lassen! Nur zur Information (da die Programme bei weitem komplexer sind): AutoAsm generiert ein scenery file (bei object panel), welches du für Airport verwenden kannst, für die Erstellung der bgl Datei. Ansonsten ASM Datei für bglc. SBuilder generiert SCM Dateien für SCASM. Also, bglcomp wird nicht verwendet. Grenzen gibt es immer. Bei dem was du erstellst, und wie du es erstellen kannst. Und vor allem bei deinem System. Außerdem kann man auch Arnos Tool OBPlacer verwenden, für die Platzierung von Objekten: http://www.scenerydesign.org/forum/f...splay.php?f=43 Aber mit der Überschrift AutoGen-Editor und richtigerweise Attonator.exe hat es nichts mehr zu tun, sondern nur mit der einfachen Platzierung von Objekten. Horst |
Hallo Horst, ist natürlich nicht mein vorname, ich möchte nur einer verwechslung vorbeugen (gibt noch einen Börries hier im Forum, und der name ist ja schon sehr selten).Ist mir jetzt auch klarer geworden das es hier nur um autogen geht und nicht xml-zeugs. Nichts für ungut. Gibt sicherlich tausend wege dem ziel näher zu kommen, wollte nur vor einer zeitverschwendung warnen.
beste grüße bwun |
Hier mal ein Update:
Ich habe mir nun einige der genannten Utilities (Attonator, Ground2k etc.) angesehen. Wirklich geeignet für mein Vorhaben ist keines der Utilities. Im Prinzip würde man sowas wie Lagos Scenery Enhancer für AutoGen-Objekte benötigen. Als Kompromiss ergibt sich daraus folgendes: Um den Airports herum, bessere, den realen Bedingungen angepasste Landclasses erstellen. Hier nur die wirklich Markanten Gebäude durch individuell platzierte 3D-Objekte (entsprchende AutoGen oder Custom-Objekte) ersetzen. Problematisch bleibt allerdings, dass dann z.B. die Gebäude im Stadt bereich, weiterhin nach globalen Vorgaben platziert werden. Selbst mit Fototexturen könnte man meinen Plan auch nur halbwegs umsetzen. Denn AutoGen-Gebäude lassen sich im Attonator zwar problemlos auf Texturen setzen, allerdings, anders als bei der Vegetation, lassen sich keine einzelnen Objekte auswählen. All das Zeigt, dass es hier zwei prinzipielle Probleme gibt: 1. Es fehlt ein benutzerfreundlicher Editor, der die wichtigisten Technologien beherrscht. So löblich es sein mag, dass einige Hobbyprogrammierer teilweise durchaus beachtenswerte Utilities erstellt haben. Für den FS-Benutzer, der hauptsächlich fliegene will und nur gelegentlich mal ein paar Veränderungen an der Szenerie vornehmen will, sind die Editoren eher weniger geeignet. Davon abgesehen, erschwert das Springen zwischen verschiedenen Utilities die dann auch noch verschiedene Benutzeroberflächen haben, die Arbeit zusätzlich. 2. Es gibt zwei Möglichkeiten Objekte zu setzen: framerateschonend mit AutoGen (Nachteil: Objekte können nicht objekspezifisch platziert werden), individuell mit custom Obejekte bzw. AutoGen-Objekten (Nachteil, bereits ab einer geringeren Anzahl von Objekte wird die Framerate stark reduziert). Das 1. Problem zu lösen, wäre eigentlich Aufgabe von Microsoft. Wenn man sich Produkte wie FarCry ansieht, bei dem ein hervorragender Editor bereits mitgeliefert wird, erkennt man schnell, zu welcher Arroganz und Ignoranz eine fast absolute Marktführerschaft in einem Softwarebereich führen kann. Hier werden einige enthusiastische Anwender einfach mal als kostenlose Microsoft-Mitarbeiter missbraucht. Das wird ebenfalls bei der 3D-Engine des FS deutlich, warum hier etwas komplett neues entwickeln, wenn der Anwender sich auch neue Hardware kaufen kann? Oder bei den Addons, warum mühsam vernünftige Standards entwickeln, wenn der Anwender sich bei jeder neuen FS-Generation auch neue Addons kaufen kann? Letztendlich braucht man sich dann auch nicht zu wundern, warum die Zahl der Freeware Szenerien immer weiter zurückgeht. Hier reicht es einfach nicht, Monate nach dem Erscheinen des FS unwillig mal ein paar SDKs hinterherzuschieben. Auch das 2. Problem wäre sicher lösbar. Da es aber kaum noch echte Konkurrenz gibt, wird sich MS hier wohl in Zukunft noch weniger mit beschäftigen. Hier bleibe eigentlich nur noch die Hoffnung, dass mal ein kommerzieller Entwickler eine leistungfähige Entwicklungsumgebung für den FS erstellt. Da MS gerade was die Informationspolitik bzw. den Support für Entwickler angeht, eher sparsam ist. Sind hier wohl die Voraussetzungen auch eher schlecht. Demnach wird mein Projekt wohl so lange warten müssen, bis es mal einen entsprechenden Editor gibt oder ich die Zeit habe, mich mit den ganzen Utilities zu beschäftigen. MfG. C.N. |
| Alle Zeitangaben in WEZ +2. Es ist jetzt 20:03 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
© 2009 FSL Verlag