Ich habe dasselbe getan wie Caesar und die Baumtexturen mit welchen
aus meiner "Bibliothek" ersetzt - die schwarzen Rechtecke sind weg.

Ich führe das deswegen an, weil an, weil das updaten auf die
Version 1.1 an diesem Problem garnichts ändert, man muß da selber
"aktiv" werden.

Oder Dirk liest das....;)

Irgenwas in der Gegend HH ist der "Übeltäter". Ich habe eine Helgoland-Szenerie, die, mit dem Flieger in EDDH stehend, den Speicher lt. Taskmanager auf 1,3 GB füllt.
Nach Deaktivierung der Szenerie geht die Auslastung auf ca, 580 MB zurück. Ich habe dann die neue HH ebenfalls deaktiviert und keinen großen Unterschied festgestellt.
Ein Rundflug über HH brachte eine Steigerung auf ca. 800 MB. Ein Weiterflug in Richtung Osten ließ die Speichergröße auf etwa 1GB anwachsen. Querab von Rügen habe ich den Flusi "in der Luft" beendet und an der gleichen Stelle sofort wieder gestartet. Das Eregebnis seht ihr im Anhang. Unter 450 MB!

Ich hatte diesen Swap-Datei Überlauf in Hamburg auch. Allerdings lag es bei mir daran, dass ich frecherweise die Readme nicht beachtet (aber gelesen) hatte und einfach die Hamburg-Scenery und den HHGround200x-Ordner in einen Ordner zusammenkopiert hatte, da ich es nicht mag, wenn ich ohne Ende Ordner in X:\FS2004\Addon Scenery habe...
Nach erneuter Installation wie in der Readme beschrieben läuft nun alles bestens, auch mit Helgoland, Boberg und Finkenwerder Szenerie.

Hm, ich bin zwar nicht der große readme-Leser vor dem Herrn, aber ich habe 2 Ordner für die Szenerie, einmal Ground und einmal eben HH.
Nun habe ich mir die Liesmich noch einmal durchgelesen und finde alles so vor wie angegeben.
Dennoch habe ich den vorher beschriebenen Sachverhalt.
Nach dem oben beschriebenen Neustart bin ich jetzt über Moskau und die Datei ist immer nich 420 MB groß. Und dies auch trotz einer UUEE-Scenerie. Ich erwähne dies, weil auch anderen Addons der schwarze Peter zugeschoben wurde.

Hallo Wolf

Zu Deinem Satz eine Frage:


""Irgenwas in der Gegend HH ist der "Übeltäter". Ich habe eine Helgoland-Szenerie, die, mit dem Flieger in EDDH stehend, den Speicher lt. Taskmanager auf 1,3 GB füllt.
Nach Deaktivierung der Szenerie geht die Auslastung auf ca, 580 MB zurück. Ich habe dann die neue HH ebenfalls deaktiviert und keinen großen Unterschied festgestellt.""


Wenn ich Dich richtig verstehe füllt sich Deine Auslagerungsdatei nur wenn diese Helgoland Scenery aktiv ist. Korrekt.

Also bei mir sieht es so aus. Ich habe nach Vorschrift installiert. Egal ob ich die beiden Sceneryteile allein oder zusammen betreibe im wesentlichen kann ich keinen Speicherüberlauf feststellen. Wenn ich beide Teile zusammen betreibe ist es nicht so garvierend anders. Klar jede für sich allein benötigt etwas weniger Speicher. Fakt ist das dem Dirk Landclass allein nicht genau genug war. Es kommen extrem viele VTP2 Polys mit Landclasszuweisung vor. Das kann man sehr schön daran sehen das die Wälder sehr exakte genaue Formen haben im Gegensatz zu reinem Landclass aber immer harte Ränder haben. Es wirkt etwas aufgesetzt nicht ganz so natürlich.

Da die Scenery extrem viele dieser Polys hat frisst das nicht nur mehr Performance sondern auch Speicher. Dadurch eben mehr als manche andere Scenery. denn der Dirk hat wirklich bei seiner Scenery sehr viel umgesetzt.

Aufgrund dessen das ich mir aber wegen der VTP Poly Probleme von Holger seiner Scenery diese genauer angeschaut habe kann man sagen das Ground2k bis vor kurzen extrem komplexe Polys erzeug hat.

Die aktuelle Version macht das nicht mehr. Dadurch werden sogar andere Problem gelindert. Ich werde dem Dirk das mal schreiben falls er das nicht eh schon festgestellt hat. Ich könnte mir vorstellen das sich die Situation bessert wenn man das Projekt noch mal neu über
die Routine laufen lässt.

Ja aber -
@Jobia: Oh Wissender, was könnte dann auf meinem System passieren ???
Welches Zusammenspiel könnte diese Speicherfüllung dann auslösen ???

Wie gesagt bei mir ist die Hamburg Scenery speicherbelastend, aber ein Problem habe ich mit Ihr nicht. Ich habe kein Speicherüberlauf sprich bei mir passiert nichts negatives wie bei einigen anderen offensichtlich.

Wenn es zum Speicherüberlauf kommt bleibt der FS hängen oder stürzt schlimmsten falls ab. Wie gesagt beides kann ich mit der Hamburg Scenery nicht feststellen daher ist sie für mich in Ordnung. Eine sehr schöne Scenery.

Was mir halt aufgefallen ist das der Ground2k VTP2 Bodenpolycode der älteren Version extrem aufwendige Polys erzeugt. Bei der neuen Ground2K Version ist das nicht der Fall.

Es kommt natürlich drauf an was die Bodenpolygone für Formen haben. Haben sie sehr viele nach innen gewölbte Bereiche dann wurden sie zu vor in sehr viele kleine Teilpolygone zerlegt um nach innen gewölbte Flächen zu vermeiden. Der FS stürzt aber nicht ab bei nach innen gewölbten Flächen, sondern stellt sie schlimmsten falls nicht dar.
Ev. treten optische Probleme auf.

Offiziel laut FS2002 SDK (ist im FS2004 nicht besser bei VTP2) mag der FS aber keine nach innen gewölbten VTP2 Boden Polygone. Aus Erfahrung weis ich aber das er hier recht großzügig ist.


Bei der neuen Ground2K Version ist diese Großzügigkeit mit eingebracht worden. Die neuen Routinen erzeugen weniger Einzelpolygone. So konnte ich bei ein und der selben Scenery erkennen das hier die Filegröße fast um die Hälfte reduziert werden konnte.

Wenn Dirk seine Projektfiles noch hat, braucht er die nur noch mal durch die neue Ground2K Version jagen und kann damit vermutlich den Speicherverbrauch verringern. Garantieren kann man das nicht, aber ein Versuch ist es Wert. Außerdem hat sich bei Holger Sandmann schon rausgestellt das es auf diese Weise auch anders weniger Probleme gibt. Einige seiner Probleme sind auf diese Weise fast komplett verschwunden.

Deshalb habe ich den Dirk auch angeschrieben.

Hallo Leute,

ich hatte in den letzten Wochen sehr viel um die Ohren, weshalb ich zwar kurz im Forum gelesen habe, aber nicht geantwortet habe. Sorry dafür.....
Also, zunächst das Baum-Problem: Das Ahrensburger Schloss habe ich von der älteren Hamburg-Version übernommen und dabei für den FS2004 die Umwandlung der Baum-Texturen vergessen. Deshalb werden die schwarz umrandet dargestellt. Der Fehler ist schon auf meinem Zettel und wird so schnell wie möglich behoben. Dazu gehört auch, dass noch weitere Texturen bzw. BGL-Dateien geändert werden müssen, da einige Schiffe im Hafen grau umrandet werden, sobald man den Bodenscenerieschatten einschaltet. Die Dinger waren mir beim letzten Update durch die Lappen gegangen.
Das nächste Problem ist das der langsam werdenden Rechner bei eingeschalteter Scenery. Leider muss ich Euch da im Moment enttäuschen, da ich nicht die leiseste Ahnung habe, woran das liegen könnte. Sehr schwierig dabei ist auch, dass bei mir das Problem nicht auftritt und ich deshalb nicht nachvollziehen kann, woran es liegt, geschweige denn einen Versuch starten kann, einen möglichen Fehler zu beheben.
Jobias Idee die Ground-Dateien nochmal mit einer neuen Version von Ground2K zu kompilieren sind gut, aber ich habe die Scenery mit der aktuellen Version (V5.32) erstellt. Insoweit scheidet auch dieser Ansatzpunkt aus. Interessant ist, dass das Problem nicht bei allen auftritt, sondern nur bei einigen. Versucht doch mal bitte die einzelnen BGL-Dateien im HHGround-Verzeichnis "auszuschalten" (also z.B. umbenennen oder woanders hin bewegen) und zu sehen, ob sich etwas ändert.... (und wenn ja, wann...)
Habe ich es auch richtig verstanden, dass das Problem bei allen nur beim FS2004 auftritt?? (Was mich vermuten lässt, dass ich als Scenery Designer dann vielleicht gar nichts machen kann, sondern Herr Gates oder Christian Fumey als Entwickler des Programms Ground2K....)
Ich werde weitere versuchen, hinter das Geheimnis zu kommen und auch mit Jobia nochmal mailen.....
Sorry, dass ich leider im Moment keine andere Antwort für Euch habe...

Gruß Dirk
:confused:

Hallo Leute

mit FS2002 läuft diese geniale Szenerie bis auf eine Ausnahme stabil und flüssig.
Im Frühling, Sommer und Herbst kommt es bei Benutzung der GA DF Boeing 737, sowie der POSKY Boeing 757 zum Stillstand des FS2002, mit einer g2dll Fehlermeldung.

Kann ich aber mit leben, da ich mich in die PMDG Boeing verliebt habe :rolleyes:

Gruß
Peter

Hallo Dirk

Das mit der Ground2K Version ist seltsam. Wenn ich hier im Forum von Bodenpolys spreche denke ich könnte ich für einige dieses auch mit Bahnhof ersetzten. Das selbe vermutlich wenn ich sage, es muß aufgebrochen werden um nach innen gewölbte Flächen zu vermeiden. Daher im Anhang ein Bildchen für alle anderen und auch für uns welches mehr als Worte sagt.

Oben sieht man eines Deiner Hamburger VTP2 Bodenpolys. Hier diese Waldfläche. Im Prinzip wenn der FS nach innen gewölbte Flächen könnte dann würde man im Designtool nur um diesen Wald an markanten Punkten rumklicken. Diese angeklickten markanten Punkte würde man dann im Code als X/Y Punkte angegeben (wie bei einer Bitmap mit 256x256 Pixeln links oben ist X=0, Y=0 unten rechts ist X=255, Y=255. Der FS würde diese Fläche die innerhalb dieser Punkte ist dann mit Wald füllen.

Im Prinzip machen die Designtools nichts anderes wenn man es mal einfach ausdrücken möchte.

Da er aber nach innen gewölbte Flächen offiziell nicht mag muß jetzt Ground2K diese Fläche die wir über die markanten Punkte theoretisch erzeugen könnten in mehrere Einzelpolygone zerlegen. Das sieht man oben im Bild sehr schön. Die weissen Linien zeigen uns diese typischen idealen Dreiecksflächen/Polygone. Wie man sieht besteht das große Polygon jetzt aus vielen kleinen, nach innen gewölbte Flächen kommen nicht mehr vor. Jeder Eckpunkt eines Polygones muß als X/Y Wert im BGL Code übernommen werden.


Also eine Information die wir haben müssen und die Speicher und Rechenarbeit kostet.

Unter dem Bild von Hamburg sehen wir ein Bild aus Holger seiner Scenery. Hier auch ein Bodenpoly nur diesmal eben Wiese die in einem Wald liegt. Wenn man es mit Dirk seinem oben vergleicht ist diese Fläche auch wieder in viele Einzelpolygone zerlegt.

Übrigends das Problem bei dem Tool Autoasm das wir in dem anderen Thread angesprochen haben ist das es nicht nur markante Außenpunkte der Bodenpolys als X/y Werte angibt es bricht auch nicht über eine Routine in mehrere auf sondern setzt im Prinzip alle Außenpunkte des Bodenpolys die in der auszulesenden Bitmap um. (siehe oben das mit den X und Y Werten) enthalten sind als X/Y Werte (von Microsoft Vectorpoints genannt)

Sprich würde sich die Außenlinie in der auszulesenden Bitmap aus 1500 Pixeln aufbauen finde ich im Code auch 1500 X/Y Werte mindestens vor. Also das zigfache an Information wie man es oben in Hamburg bzw. in der Mitte bei Holgers Poly vorfindet. Der Autoasm Code ist also extrem belastend hinsichtlich Vectorpoints. Zumindest bei mir. Mal sehen was Horst bei sich findet. Vielleicht arbeitet Autoasm bie mir nicht richtig oder ich habe einen Fehler gemacht. Passte gerade gut da man es an den Bildchen gut erklären kann.


Was fällt oben auf. Das Hamburger Poly und das von Holger in der Mitte sehen ziemlich ähnlich aus hinsichtlich Aufbau des Polys aus Einzelpolys. Es gibt sehr viele nahezu ideale Polys.


Unten sieht man aber noch mal das selbe Poly von Holger. Diesmal der Code der bei Ihm bei Rekompilierung über die aktuellste Ground2K Version entstanden ist. Sprich das was er gezeichnet hatte wird mit der neuen Routine wieder in Polys zerlegt und in die BGL kompilert. Diese eine Fläche wird da sie nach innen gewölbte Anteile hat immer noch in mehrere Polys von Ground2K zerlegt. Aber es sind nur noch sehr wenige Einzelflächen. Sie enthalten jetzt auch gewölbte Anteile aber offensichtlich nur in dem Rahmen wie es der FS zulässt. Da es weniger Flächen sind müssen auch nicht so viele X/Y Werte angegeben sein. Der BGL Code wird kleiner die Hardware muß weniger rechnen.

Wie gesagt bei Holger hatte das bei einem File fast eine Halbierung der Bytes gebracht. Auch die Probleme das anstatt dunkler Wiese in der Nacht hier ein kurioser Wechsel zu einer leuchtenden Stadttextur erfolgt hat sich wesentlich gebessert. (Leider nicht bei allen Files) Zumindest hatte ich neulich mir meiner Vermutung das die Polys von Ground2K zu komplex sind richtig gelegen.



Wie gesagt meine Erfahrung mit einem anderen vergleichbaren Designtool (welches das zerlegen der Polys in Einzelpolygone nicht macht) hat mir gezeigt das der FS da sehr tolerant gegenüber nach innen gewölbten Flächen ist.



Nur man sollte das auf jeden Fall bei Ground2k in der Anfangsphase der neuen Version kontrollieren ob durch die neuen Routinen ev. Teile des Polys auf einmal fehlen.

Das ist nämlich der Effekt wenn man es mit nach innen gewölbten Flächen überreist.

Der FS lässt diesen problematischen Vectorpoint einfach aus und springt zum nächsten Punkt. Dadurch entsteht eine gerade Linie zwischen diesen Punkten die nach innen gewölbte Fläche verschwindet.

Ground2K hat jetzt ja die Funktion concave Polys. Da ich aber noch eine Zerlegung erkenne denke ich nicht das Holger dieses aktiviert hatte.

Ich werde mir das aber mal genauer ansehen.

Auf jeden Fall schliesse ich nicht aus das es mit Deiner Scenery besser läuft wenn die Polys einfacher sind.

Wie gesagt einen Überlauf hatte ich persönlich nicht. Wenn ich Wolf sein Posting richtig interpretiere wird es bei Ihm eher durch diese Helgoland Scenery verursacht.

Hier das Bild. Oben Hamburg. Mitte Holgers Poly aus alter Ground2k Version unten das selbe aus aktueller Ground2k Version.