Quote:

---

und du brauchst ja nur 4 terrain, also ist das nciht diiiie mühe

---

Naja so einfach ist es dann doch nicht...

Angenommen ich will eine Fläche von 1km². Ich rechne mit 2 Quant pro cm also ergeben 5000 auf 5000 einen Hektar Fläche. Damit es einigermaßen was aussieht, sollte der Vertexabstand pro Terrain nicht über 30 liegen (meine Erfahrung),
nehmen wir also mal 20. Die maximale Vertexmenge beim Import liegt bei 500 ergibt eine Größe von 10000*10000 (4Hektar). Bei einer Heightmapgröße von 4096*4096 sieht das ganz gut aus. Aber jetzt bräuchte ich immer noch 25 Terrains aneinandergelegt um die erforderliche Größe zu erreichen. Da ist mir eine gute Methode zum Zusammensetzen schon wichtig, vor allem weil das hier jetzt die maximalwerte waren, wahrscheinlich werden meine Terrains aber noch kleiner sein (1Hektar), da ich ja mit multitextureshader arbeite und so nur 4 verschiedene Texturen pro Terrain habe.

^^° omg..ich wurde von zahlen erschlagen.
Die einzige möglichkeit seh ich dann in MED darin, dass du den scalieren wert aufs maximum schiebst und alles per hand machst *mit dir leid*.
Oder du versuchst dir einen kleinen script in c++ zu schreigen der dir terrain aus highmaps generiert (md7.lib für mdls und hmps)

wegen dem terrainshader: du kannst mehr als nur 4 haben: da man insgesamt 8 texturen importiren kann bracuht man 2 color maps also kannst du insgesamt 6 haben(color maps mit schwarz,rot,grün,blau,alpha also sogar noch zusätliche informationen möglcih wie z.b. shadowmap)

Dummerweise wollte ich die restlichen Texturen für meine Blendingeffekte nutzen... Ich arbeite momentan ja an einem Shader für noch mehr Texturen, aber das ist nicht ganz einfach, da die Shaderreferenzen von Microsoft so unübersichtlich sind. Man kann das wohl auch per dll lösen, aber ich kann kein C++, daher versuch ichs erst mal mit HLSL.

25 mal 25: Das sind 625 Terrainstücke. Das klingt, als ob man das ohne Tools nicht lösen kann.

Ich würde vermutlich in so einem Fall lieber Modelle nutzen. Hier könnte man LOD nutzen, aber 625 LOD-Stücke erstellen, ist ebenfalls ein Ding der Unmöglichkeit. Vor allen Dingen dann, wenn die Ränder wirklich passen sollen, auch bei den LOD-Stücken.

Was ist mit dem unendlich großen Terrain das Gamestudio liefern soll mit diesem Chunked-LOD? Funktioniert das nicht?

Ich gehe davon aus, du willst eine riesige Fläche von z.B. 100.000 quants mit Chunked Terrain befüllen.
Also, ich hab das alles mal angetestet, wobei ich meistens mit folgendem Format operiert habe:

257 * 257 vertices, 32 quant Triangle size. Ergibt z.B. eine Fläche von 8192 quant. Dann bräuchte man ca 12 * 12 Terrain-entities (die dann wiederum intern von der Engine in kleinere Chunks zerlegt werden)
Bei meinen Versuchen entsprachen 32 quant etwa einem Meter.

Du kannst beliebig viele solcher Flächen erzeugen und als Chunked Terrains verwenden.

Damit sie an den Rändern exakt aneinanderpassen, sind drei Dinge zu beachten:

1) Die Pixel an den Rändern der heightmap müssen identisch sein (kopieren und in benachbarte heightmap einfügen). Dadurch ist sichergestellt, daß die Vertices exakt aneinanderpassen.
Spiegeln hat natürlich dieselbe Wirkung, ist aber nicht notwendig.
Es spielt keine Rolle, wie die Heightmaps zustande kommen. Ich habe meine meistens von Hand gepinselt.

2) Alle Heightmaps müssen im Scale-Mode identisch skaliert werden, wobei sowieso nur die Höhe skaliert werden kann In MED geht das meines Wissens nur mit dem blauen Pfeil mit Click & Drag. Im Toolbar ganz unten wird angezeigt um wieviel man skaliert hat. Darauf muß man achten! Ich habe meine Terrains meistens um den Faktor 8 skaliert.

3) Ein Problem ist, daß der Nullpunkt bzw. Origin der Terrains, zumindest ist das meine Vermutung, immer dem Schwerpunkt des jeweiligen Terrains entspricht, also, was die Höhe angeht, irgendwo in der Mitte.
Ich habe auch probiert, mit Bezugspunkten zu arbeiten (ganz weißes, bzw. ganz schwarzes Pixel in der Heightmap), hat das Problem aber auch nicht gelöst.
Man kann aber - bei maximalem Ranzoomen an die Ränder - die Terrains in WED manuell passend anordnen. Wenn man pingelig genug dabei vorgeht und die Werte auch über das Properties - Panel einstellt, funktioniert das ganz gut. Ein kleiner Rand ist aber kaum zu vermeiden.

Du wirst wahrscheinlich die Terrains im Spiel dynamisch laden wollen (abhängig z.B. von der Player Position). Das kann geschehen, indem Du dabei die manuell ermittelten Terrain Positionen verwendest.

Ich wüßte leider keine einfachere Methode . Habs aber ausprobiert und es funktioniert.

@ friendly frank
Sorry hab mich falsch ausgedrückt, meine Rechnung basierte auf 4Hektar pro Terrain 100 Hektar = 1km² also 25 Terrains (5*5). Aber war ja nur ein Beispiel, bei 1 Hektar pro Terrain wären das ja schon 100 und was wenn ich dann plötzlich Lust habe noch einen km² dran zu hengen? Da brauch ich einfach eine schnelle, gute Methode.

@ Robotronic Danke für deine Ideen, ich habe das schonmal probiert, mit dem Kopieren der Ränder, aber wenn die Heightmaps an diesen Rändern deutlich unterschiedlich sind, sieht das später sehr seltsam im Level aus. Das Problem ist, das z.B. die Graustufe 65 einer Heightmap nicht representativ für eine Höhe ist, es hängt von der Gesamthöhendifferenz im Terrain ab.

Bei Earth Sculptor kann man die aber glaub ich im Editor festlegen (max. Height), ich werd das mal testen, ob alle Heightmaps richtig daran angepasst werden. Der dritte Punkt den du angesprochen hast, ist ebenfalls ein Problem.
Du hast recht, wenn man SEHR pingelig ist, es sogar ohne erkennbaren Rand hinkriegen, aber wenn man 20 Terrains + Vegetationsobjekte in WED geladen hat, dann ruckt der Editor ziemlich (bei mir) und dann ist das mit der Ausrichtung auch eine längere Sache.

Quote:

---

Das Problem ist, das z.B. die Graustufe 65 einer Heightmap nicht representativ für eine Höhe ist, es hängt von der Gesamthöhendifferenz im Terrain ab.

---

Es ist tatsächlich so, daß identische Grauwerte zu unterschiedlichen Höhenwerten führen können. Das hängt an zwei Faktoren:

1) Die Gesammtgröße des Terrains. => Man muß immer dieselbe Größe verwenden.

2) Bei der MED-Umrechnung von Grauwerten (bzw Farbwerten) in Höhenwerte haben auch die benachbarten Pixel einen Einfluß! Ich habe daher bei meiner Kopiermethode für Heightmaps im Format 1024*1024 im Prinzip "Rechtecke" mit Maßen von z.B. 2*1024 kopiert, am Rand der Nachbarheightmap eingefügt und zudem natürlich gespiegelt. Damit ist dann auch der Einfluß der Nachbarpixel identisch und du solltest gute Übergänge bekommen ...

=> Die Gesammthöhendifferenz hatte bei mir komischerweise keinen Einfluß ...

Wegen dem Ruckeln: Ich hab das auch und ich denke mal, das hängt mit dem Arbeitsspeicher der Editoren zusammen. Um die Höhenpositionen in WED festzulegen, genügt es aber jeweils zwei Terrainentities zu laden, die Höhe anzugleichen und zu notieren.
Du kannst die Terrains dann später dynamisch an der ermittelten Position ent-createn. Ich denke mal, bei einer sehr großen Welt mußt du sowieso über ein Lade und Remove-system nachdenken, sowohl für Terrain als auch für Vegetation etc. Ich würde das generell so machen, daß ich nur die Teile der Map lade, die ich bearbeiten will.

Das pingelige Angleichen ist nervig. Man bräuchte eine Option in MED, wo man den Nullpunkt des Terrains absolut (in Bezug auf einen bestimmten Grauwert)festlegen kann, dann hätte man dieses Problem nicht. Kanst ja mal vorsichtig bei Conitec anklopfen, ich würde so einen Antrag sicherlich unterstützen ...

Ja eine solche Option wäre tatsächlich hilfreich...

Mit EarthSculptor scheint der Import durch die Voreinstellung der Höhe tatsächlich besser zu laufen, aber leider kann man die Kapazität des Editors auch nicht wirklich ausnutzen. Die masximale Terraingröße von 3DGS beträgt nur 500*500 Vertizes (EarthSculptor kann 4096*4096). Im Handbuch steht zwar was von "unbegrenzter Terraingröße" für chunked Terrain, nur frag ich mich, wie man die erreichen will...

Leider zeigt EarthSculptor den Abstand der Vertizes nicht an, das wäre für eine Übertagung schon schön zu wissen.

Mal ne Frage zum chunked Terrain wegen einem Ausblendsystem: Führt jede Parzelle eine dem Terrain gegebene Funktion selbst aus, oder nur das Terrain als ganzes?

EDIT: @robotronic Das die benachbarten Pixel in der Heightmap eine Rolle spielen
liegt wahrscheinlich daran, dass ja immer ein pixel der Heightmap einen Vertex repräsentiert, aber die maximale Anzahl bei MED ja bei 500*500 liegt. Das heißt eigentlich sind Heightmaps größer als 500*500 für den Import sinnlos, dann werden halt Mittelwerte zwischen den Pixeln gebildet.

Quote:

---

Im Handbuch steht zwar was von "unbegrenzter Terraingröße" für chunked Terrain, nur frag ich mich, wie man die erreichen will...

---

Das Handbuch ist da ziemlich irreführend, bzw. kurzatmig ...
Du kannst meines Wissens ein unbegrenztes Terrain nur mit einer Vielzahl von schachbrettförmig angeordneten, kleineren TerrainEntities (z.B. 257*257 Vertices) erzeugen. Diese werden aber alle brav von der Engine in noch kleinere Chunks zerlegt und dadurch schnell gerendert. Und als Bonus kannst du auch für die einzelnen Terrainzellen unterschiedliche Texturen verwenden.
Ich habe mal versucht ein Terrain mit 999 * 999 Vertices zu laden. Hat ewig lange gedauert und führte nach kurzer Zeit zum Absturz. Gab auch Editormeldungen wie "Low System Memory".

Das ganze Thema "Übertragung von Pixeln in Vertex-Höhenwerte" ist mir leider selbst nicht 100-prozentig klar.
Gibt es ein optimales Verhältnis zwischen Heightmap-Format (in Pixeln) und Terrainformat in Vertices? Hab ziemlich viel rumexperimentiert, aber irgendwie kam dabei nur heraus, daß vermutlich mehrere Pixel zur Berechnung der Vertexhöhe verwendet werden.
Für mich funktioniert das ganze nicht besonders gut.
Ein weicher Grauverlauf führt i.d.R. nicht zu einem weichen Ansteigen oder Abfallen der Höhenpositionen, sondern man bekommt bekommt plötzlich Stufen bzw. Treppchen, die man dann in MED mühsam Vertex für Vertex korrigieren muß.

Ich wrede mich vermutlich mal nach einem Terrain-Editor umsehen, wo man das Terrain als Modell exportieren kann und dann das Modell in MED in Terrain umwandeln. Ich glaube, das ist am Ende besser, als die häßlichen Resultate, die man mit "Import from Pic" erzielt.

Earthsculptor hat einen .obj Export, aber der lässt sich nicht so ohne weiteres in Med laden, mein MED stürzt dabei ab.