WCM Forum - Einzelnen Beitrag anzeigen - Mesh-Konflikte, Flatten-Probleme

JOBIA · 01.05.2005, 06:25

Zu

"Gibt es irgendeine Möglichkeit, ohne langes Probieren herauszufinden, welche Szenerien überhaupt in einer bestimmten Gegend geladen werden bzw. wirksam sind?"

Nein das gibt es eigentlich nicht.

Holger hat zwar recht mit seiner Aussage, dass man mit dem SDK Tool TMF Viewer bzw. LWM Viewer die Fläche solcher TMF Files beurteilen kann, auch deren Dateninhalt, aber das ist eigentlich nicht die direkte Antwort auf die Frage oben. Denn ob so ein Mesh, Landclassfile oder sonstiges überhaupt zur Anwendung kommt oder geladen wird, darüber sagen diese beiden Tools leider überhaupt nichts aus.

Was an einer Koordinate X/Y zur Anwendung kommt entscheidet der FS an einer eigenständigen Prioritätsregelung. So kommt es dann darauf an wie die Summe """aller""" im FS2004 aktiven Landclassfiles für diese Koordinate hinsichtlich Priorität in der Scenerybibliothek verwaltet sind.

Bei Meshfiles mit gleichen LOD Level gilt das selbe. Beim FS2004 wegen des Prioritätsbugs von der Logik umgekehrt. Umso niedriger das Mesh angemeldet ist umso höher die Priorität.

Bei Meshfiles unterschiedlicher LOD Level im gleichen Bereich kommt im Nahbereich immer das mit dem höchsten LOD Level zur Anzeige.

Gibt es dazu gleichwertige LOD Level Mesh Files muss auch hier beim FS2004 wieder der Prioritätsbug beachtet werden.

Diese Betrachtung bzw. überhaupt das Finden solcher Addondateien, dass können beide Tools nicht. Auch können sie nichts über die Priorität aussagen.

Über den Aufenthaltsort solcher Dateien auch nicht. Ausnahme LWM Viewer bei Defaultdaten einiger TMF Files.

Nun hat man aber ein Problem. Bevor ich ein LC oder Mesh File im TMF Viewer beurteilen kann, woher weis ich denn welches File ist überhaupt ein Mesh oder Landclassfile. In welchem Scenerypfad steckt es überhaupt.
Oftmals hat man solche Scenerien als eigenständige Addons angemeldet dann hat man Glück, dass ist des öfteren aber nicht der Fall.

Denn hin und wieder werden LC, WC oder Mesfiles von Addons irgendwo im FS2004 versteckt in Default FS Pfade untergebracht. Hin und wieder tragen sie auch keine verräterischen Namen wie z.B Mesh oder DEM. (Digital Elevated Mesh).

Wobei DEM in die Irre führen könnte. DEM wird z.B bei Flattenfiles in Area16N Technik bei Designtool SCC im Namen eingebaut.

Man könnte denken es handelt sich um ein Meshfile. Ist aber keines.

Ich habe auch schon Files mit LC im Namen gesehen, dass waren auch keine Landclassfiles.

Das bedeutet, dass man z.B bei mir im FS weit über 20000 Scenery.bgl Files als potente Störer hat. Selbst wenn man diese 20000 Files aufgrund eigenen Wissens auf nur noch 200 Files von Namen als Störer eingrenzen kann, dann bedeutet dieses 200 Files im FS and den unterschiedlichsten Orten aufzustöbern und anschliessend im z.B TMF Viewer öffnen. Das Verhalten der Priorität also was später überhaupt geladen wird, ist dann aber aufgrund eigenen Wissens zu treffen.

Wer das Wissen nicht hat, der kann dann aber auch nichts über deren Prioritäten aussagen.

So kann man z.B bei einer Custom Foto Scenery wie Real Germany störende eckigen Texturen erkennen. Das kann beim FS 2004 z.B eine höher gelagerte Landclasscenery sein. Das war beim FS2002 nicht so. Jetzt könnte man natürlich sagen OK ich weis, dass eine höher gelagerte Landclasscenery immer eine Fotoscenery überlagert.

Dem ist aber nicht so. Der FS2004 ist gemein. Es kommt darauf an wieviele LC Definitionen sind miteinander verbunden. Sind es nur sehr wenig und der Rest ist Transparenz LC Nummer 254 tritt der Effekt nicht ein.

Von daher sind diese Tools ideale Hilfsmittel wenn man weis welche Files überhaupt in Frage kommen.

Deshalb erwähne ich auch beide Tools in meiner Dok.

Nur das suchen und aufstöbern von potentiell störenden Scenerycode, dass nehmen sie einem nicht ab.

Deshalb habe ich diese Thematik mit aufgenommen. Sie wird enthalten sein.

Auch nehmen die Tools einem nicht ab zu entscheiden wie es sich dann später mit der Priorität verhält.

Der Sachverhalt mit dem Prioritätsbug bei Mesh hat sich ja durch Holger im FXP Forum ganz gut verbreitet. Holger hatte ja damals als erster hier im Forum über das Problem berichtet wenn ich mich recht erinnere.

01.05.2005, 06:25	#5
JOBIA Inventar Registriert seit: 02.01.2002 Alter: 61 Beiträge: 4.238	Zu "Gibt es irgendeine Möglichkeit, ohne langes Probieren herauszufinden, welche Szenerien überhaupt in einer bestimmten Gegend geladen werden bzw. wirksam sind?" Nein das gibt es eigentlich nicht. Holger hat zwar recht mit seiner Aussage, dass man mit dem SDK Tool TMF Viewer bzw. LWM Viewer die Fläche solcher TMF Files beurteilen kann, auch deren Dateninhalt, aber das ist eigentlich nicht die direkte Antwort auf die Frage oben. Denn ob so ein Mesh, Landclassfile oder sonstiges überhaupt zur Anwendung kommt oder geladen wird, darüber sagen diese beiden Tools leider überhaupt nichts aus. Was an einer Koordinate X/Y zur Anwendung kommt entscheidet der FS an einer eigenständigen Prioritätsregelung. So kommt es dann darauf an wie die Summe """aller""" im FS2004 aktiven Landclassfiles für diese Koordinate hinsichtlich Priorität in der Scenerybibliothek verwaltet sind. Bei Meshfiles mit gleichen LOD Level gilt das selbe. Beim FS2004 wegen des Prioritätsbugs von der Logik umgekehrt. Umso niedriger das Mesh angemeldet ist umso höher die Priorität. Bei Meshfiles unterschiedlicher LOD Level im gleichen Bereich kommt im Nahbereich immer das mit dem höchsten LOD Level zur Anzeige. Gibt es dazu gleichwertige LOD Level Mesh Files muss auch hier beim FS2004 wieder der Prioritätsbug beachtet werden. Diese Betrachtung bzw. überhaupt das Finden solcher Addondateien, dass können beide Tools nicht. Auch können sie nichts über die Priorität aussagen. Über den Aufenthaltsort solcher Dateien auch nicht. Ausnahme LWM Viewer bei Defaultdaten einiger TMF Files. Nun hat man aber ein Problem. Bevor ich ein LC oder Mesh File im TMF Viewer beurteilen kann, woher weis ich denn welches File ist überhaupt ein Mesh oder Landclassfile. In welchem Scenerypfad steckt es überhaupt. Oftmals hat man solche Scenerien als eigenständige Addons angemeldet dann hat man Glück, dass ist des öfteren aber nicht der Fall. Denn hin und wieder werden LC, WC oder Mesfiles von Addons irgendwo im FS2004 versteckt in Default FS Pfade untergebracht. Hin und wieder tragen sie auch keine verräterischen Namen wie z.B Mesh oder DEM. (Digital Elevated Mesh). Wobei DEM in die Irre führen könnte. DEM wird z.B bei Flattenfiles in Area16N Technik bei Designtool SCC im Namen eingebaut. Man könnte denken es handelt sich um ein Meshfile. Ist aber keines. Ich habe auch schon Files mit LC im Namen gesehen, dass waren auch keine Landclassfiles. Das bedeutet, dass man z.B bei mir im FS weit über 20000 Scenery.bgl Files als potente Störer hat. Selbst wenn man diese 20000 Files aufgrund eigenen Wissens auf nur noch 200 Files von Namen als Störer eingrenzen kann, dann bedeutet dieses 200 Files im FS and den unterschiedlichsten Orten aufzustöbern und anschliessend im z.B TMF Viewer öffnen. Das Verhalten der Priorität also was später überhaupt geladen wird, ist dann aber aufgrund eigenen Wissens zu treffen. Wer das Wissen nicht hat, der kann dann aber auch nichts über deren Prioritäten aussagen. So kann man z.B bei einer Custom Foto Scenery wie Real Germany störende eckigen Texturen erkennen. Das kann beim FS 2004 z.B eine höher gelagerte Landclasscenery sein. Das war beim FS2002 nicht so. Jetzt könnte man natürlich sagen OK ich weis, dass eine höher gelagerte Landclasscenery immer eine Fotoscenery überlagert. Dem ist aber nicht so. Der FS2004 ist gemein. Es kommt darauf an wieviele LC Definitionen sind miteinander verbunden. Sind es nur sehr wenig und der Rest ist Transparenz LC Nummer 254 tritt der Effekt nicht ein. Von daher sind diese Tools ideale Hilfsmittel wenn man weis welche Files überhaupt in Frage kommen. Deshalb erwähne ich auch beide Tools in meiner Dok. Nur das suchen und aufstöbern von potentiell störenden Scenerycode, dass nehmen sie einem nicht ab. Deshalb habe ich diese Thematik mit aufgenommen. Sie wird enthalten sein. Auch nehmen die Tools einem nicht ab zu entscheiden wie es sich dann später mit der Priorität verhält. Der Sachverhalt mit dem Prioritätsbug bei Mesh hat sich ja durch Holger im FXP Forum ganz gut verbreitet. Holger hatte ja damals als erster hier im Forum über das Problem berichtet wenn ich mich recht erinnere.