Korrekt hast Du im Prinzip richtig verstanden Rainer. Der LOD Level also der Punktabstand der Höhenpunkte wird durch das Mesh vorgegeben. Hat man ein Mesh mit sehr hoher Auflösung z.B LOD11 wird dieses erst durch Manipulation des TMVL sichtbar. Ohne dieses arbeitet es nur mit niedrieren LOD Level.
Ausschlaggebend für diesen CTD ist allerdings die Flankensteilheit von einem Höhenpunkt zum nächsten. Da ist es im Prinzip egal wie hoch der LOD Level des Mesh bzw. der Wert des TMVL ist. Beispiel TMVL auf 21. Rasterabstand des Mesh 38Meter. Der eine Punkt hat eine Höhe von 0 Meter der andere 38Meter. Ergibt eine Flanke mit 45°. Nehmen wir mal an diese löst mit entsprechender Landclasspositionierung und Mask Class Map Funktion einen Crash aus.
Jetzt sagt man. "Ja das passiert nur bei manipulierten TMVL Faktor".
Also den Wert auf Default19. Klar jetzt würde ev. einer der Höhenpunkte von 38Meter ausgelassen. Es würde erst der nächste genutzt. Die Flanke würde flacher und wir hätten keinen Crash an dieser Position.
Jetzt komme ich mit einem anderen Beispiel. TMVL auf 19. Ein Mesh mit Rasterabstand 76m Dieses wird bei TMVL 19 ohne Probleme dargestellt.
Der eine Meshpunkt auf 0 Meter der andere auf 76 Meter. Was passiert wir haben eine Flankensteilheit 45°. Was bedeutet dieses. Crash to Desktop bei TMVL19. Jetzt ist es sogar gefährlicher da die Fehlerfläche größer wird.
Auf der anderen Seite dürften diese Konstellationen vielleicht in realen Meshfiles seltener oder an anderen Stellen vorkommen. Auch glaube ich nicht das alle bisher gemeldeten Crashs nur bei Usern aufgetreten sind die am TMVL maipuliert haben, sei es wissend oder unwissend. Einige haben den Crash in SION gemeldet in Verbindung mit einem anderen Mesh. Anderes Mesh bedeutet auch andere Flanken möglich. (auch bei unverändertem TMVL)
Also von daher Horst denke ich werden die Problemstellen einfach wechseln.
Ich muß mal nachschauen von irgendjemand hatte ich eine Mail mit einer Crash Stelle die definitiv auch mit TMVL 19 auftritt.
Noch etwas man muß die verschiedenen Flattentechniken im Auge behalten. Schau Dir LWM Flatten an. Hier ist der Rasterabstand in den bakannten Vectorpoints hat also überhaupt nichts mit dem Raster von LOD zu tun. Bei dem alten Area16N Flattenbefehl verhält es sich wieder anders. Daher können hier Flanken entstehen die nahezu unabhängig von jedem LOD Level oder TMVL sind.
Es ist alles letzendlich nur eine Frage der Höhendifferenzen und der Konstellationen anderer Elemente.
Zu deinem Sticky. Man beachte hier wird nicht die MaskClassMap=2 wie bei meinem Patch geändert. Nur 1 und 3. Es gibt somit kein Airportrasenproblem wie jetzt beim aktuellen SG1 Patch es bedeutet aber auch es können weitere Crashs möglich sein.
Leider habe ich momentan zu wenig Zeit sonst hätte ich mich auch schon mehr damit beschäftigt. Ich habe hier einen Verdacht das es bevorzugt da crasht wo zwei MaskClassMap Funktionen aufeinander stoßen. Wir bedenken in Sion war noch eine kleines Linienflüsschen welches ziemlich nah am Airportflattenpoly kratzte. Was sagt uns das? Wir wissen ein Linienfluss hat eine MaskClassmap Funktion. Das Airportpoly im Prinzip auch. Nur es sind verschiedene MaskClassMap Nummern.
Ein theoretisches Beispiel die LC Nummern stimmen nicht. Es geht nur ums Prinzip. Das Mesh ist steil. Der FS wechselt aufgrunddessen von LC35 auf LC 120. Der erste Wechsel. Von der einen MaskClassmap Funktion der Flüsse möchte der FS z.B von LC120 auf 130 wechseln. An der selben Stelle möchte er durch MaskClassmap des Airportpolys von LC120 auf 140 wechseln.
Mag er diese zwei Wechsel. Crasht er zum Desktop. Wie verhält es sich hier mit den Prioritäten.
Zum größten Übel kommt jetzt noch eine Saisongrenze dazu wie in SION.
Da ist die Hölle los an Schaltfunktionen hinsichtlich Landclass im FS.
Im Prinzip ist das testen gar nicht so schlimm. Trotzdem habe ich momentan andere Prioritäten. Aber ich denke den Bug selbst kann man finden. Nur vermutlich nicht anders als momentan lösen das dürfte das Problem werden.
Zu dieser anderen Geschichte ob da nun wer auf mich verweist oder nicht das ist mir persönlich schon seit längerem egal.
Die meisten hier im Forum dürften eh wissen wer das zuerst entdeckt hat. Das reicht mir um mich in meiner Arbeit zu bestätigen. Ob die anderen das dann aus anderen Foren übernommen haben juckt mich nicht.
Im Prinzip hat es Richard Ludowise ein paar Stunden später entdeckt.
Es passiert halt immer wieder das Leute nahezu zeitgleich Fehler rausfinden.
Nur es reicht halt nicht aus die MaskClassMap einfach auszuschalten. Zumindest nicht bei den Airportpolys. Von daher gibt es momentan nur meinen Weg des Patches.
Dem Richard hat die Scene eh sehr viel zu verdanken. Meiner Meinung einer der wichtigsten Männer in der Designscene. (hatte ich aber schon mal erwähnt) Ohne ihn wäre die damals neue LWM/VTP Technik nicht so schnell programmierbar gewesen.
|