Ihr habt Probleme mit eurem Spiel, eine Frage zu technischen Dingen, oder wollt einen Bug melden? In diesem Forum finden all diese Dinge ihren Platz. Bitte beachtet die Postingregeln für Bug-Reports.
falsch, es werden drei Punkte festgelegt für ein Parallelogramm und keine:
Unter Triangulation oder Triangulierung einer Fläche versteht man
a) ein Netz von Dreiecken im Raum, das auf einer vorgegebenen Fläche liegt und diese teilweise oder vollständig überdeckt, oder
b) die Prozedur der Erzeugung der Punkte und Dreiecke eines solchen Dreiecks-Netzes.
Als Anwender im GE erstelle ich ein Netz von trigonometrischen Punkten (Triangulation) , die Engine errechnet die Parallelogramme.
Ist jetzt auch langsam egal, hat ja eh nichts mit dem eigentlichen Thema zu tun.
Ein Trigonometrischer Punkt (TP) oder Triangulationspunkt, manchmal auch Trigonometer genannt, ist ein Beobachtungspunkt der Landesvermessung bzw. eines größeren Dreiecksnetzes
und soweit ich weiß ist es ein spezieller und nachträglich eingefügter Script, der im LS diese Flächen erstellt.
Auf der Ebelsbach wurde ein externes Script verwendet, um die Feld-Definitionen zu erstellen. Grund dafür war wohl, dass man die teilweise komplexen (runden) Feldränder schön abbilden wollte. Das hat aber eben zu diesen hunderten kleinen Streifen geführt, aus denen die Felder jetzt bestehen. Dies wiederum hat anscheinend massive Auswirkungen auf die Performance.
Was HeinzS versucht zu erklären:
Normalerweise wählt man einige/wenige Punkte entlang der Feldgrenze aus. Dadurch entsteht erstmal ein Vieleck. Der Editor (das Basisscript) macht daraus dann entsprechend (möglichst wenige) Vierecke um das Feld aufzuteilen.
Nachteilig ist hier einfach nur, dass die Feldränder (besonders kurvige) meist nicht sehr gut abgebildet werden. Das sieht man bei manchen Karten ja auch, wenn die Felder noch in NPC Hand sind.
Extrem gesagt: Feld ist eigentlich ein Kreis, die Felddefinition ist aber nur ein Sechseck. Im Spiel wird dann vom NPC (nicht der Helfer) auch nur das Sechseck bearbeitet.
Falls ich hier was falsch verstanden habe, bitte korrigieren.
Kann mir mal einer erklären, weshalb das überhaupt derart kompliziert gehandhabt wird, ein Feld zu erstellen? Wieso kann man nicht einfach ein Kreis um das Feld ziehen und fertig? Ist der programmiertechnische Aufwand dafür zu groß?
Finjas wrote: ↑Thu Apr 04, 2019 12:06 pm
Kann mir mal einer erklären, weshalb das überhaupt derart kompliziert gehandhabt wird, ein Feld zu erstellen? Wieso kann man nicht einfach ein Kreis um das Feld ziehen und fertig? Ist der programmiertechnische Aufwand dafür zu groß?
könnte man wenn der GE so etwas beinhalten würde, da aber Giants Felder schnell mit ein paar Parallelogrammen erstellt werden kann hat man dieses nicht eingefügt.
Eische wrote: ↑Thu Apr 04, 2019 11:57 am
Normalerweise wählt man einige/wenige Punkte entlang der Feldgrenze aus. Dadurch entsteht erstmal ein Vieleck. Der Editor (das Basisscript) macht daraus dann entsprechend (möglichst wenige) Vierecke um das Feld aufzuteilen.
falsch, es ist ein extra Script, deren Funktion in dem o.a. Link beschrieben wird und da es nicht von einem Profi erstellt wurde ist es zwar schnell aber auch ungenau und zusätzlich sehr performancelastig.
Eische wrote: ↑Thu Apr 04, 2019 11:57 am
Normalerweise wählt man einige/wenige Punkte entlang der Feldgrenze aus. Dadurch entsteht erstmal ein Vieleck. Der Editor (das Basisscript) macht daraus dann entsprechend (möglichst wenige) Vierecke um das Feld aufzuteilen.
falsch, es ist ein extra Script, deren Funktion in dem o.a. Link beschrieben wird und da es nicht von einem Profi erstellt wurde ist es zwar schnell aber auch ungenau und zusätzlich sehr performancelastig.
Kann das sein, dass das keine Triangulierung sondern eine Art Integration ist? In der Oberstufe wurde das Thema damit eingeleitet, dass man den Flächeninhalt unter eine Kurve berechnen kann, indem man rechtecke einzeichnet (exakt so, wie es im Screenshot von HeinzS aussieht). Dabei bleiben die Dreiecke übrig, die nicht berechnet werden, je mehr (kleine) rechtecke man zeichnet, desto weniger Dreicke bleiben und desto genauer lässt sich der Flächeninhalt bestimmen, bei "unendlich vielen" rechtecken ist der Flächeninhalt korrekt abgebildet und man hat die Integration. Sorry für eventuelles OT, aber ich fühlte mich extremst daran erinnert
es wird aber nicht der Flächeninhalt einmalig berechnet sondern im Spiel 60 mal pro Sekunde und je mehr Flächen verwaltet werden müssen desto geringer die Performance. Einfach mal im GE alle fields bis auf eine löschen und dort nur ein Parallelogramm verwenden. Dann sollten die FPS deutlich besser sein.
Hast du eine Quelle für diese Behauptung? Die von dir montierten Fielddimensions sind lediglich für die Missionen und die virtuellen Bauern von nöten, meines Wissens nach werden diese TGs lediglich beim Spielststart (bzw. beim Laden der Map) berücksichtigt und nicht während des Spiels. Sprich, das Löschen dieser TGs wird dir nur einen schnelleren Spielstart bescheren und dass die Missionen nicht mehr oder nicht mehr korrekt funktionieren.
hatte ich geschrieben und auf einer anderen Map schon erfolgreich getestet
HeinzS wrote: ↑Thu Apr 04, 2019 10:05 pmEinfach mal im GE alle fields bis auf eine löschen und dort nur ein Parallelogramm verwenden. Dann sollten die FPS deutlich besser sein.
HeinzS wrote: ↑Thu Apr 04, 2019 10:05 pm
es wird aber nicht der Flächeninhalt einmalig berechnet sondern im Spiel 60 mal pro Sekunde und je mehr Flächen verwaltet werden müssen desto geringer die Performance.
das ist meine Schlussfolgerung, weil ohne die vielen Streifen die FPS besser waren. Auf der Ebelsbach habe ich das noch nicht probiert da sie auch sonst zu viele Tg für meinen i5-2500K enthält um mit 60 FPS zu laufen.
