Brauche kleine Überlegungshilfe für Terrain Editor
-
Hallo zusammen,
ich zerbreche mir gerade den Kopf, wie man am geschicktesten die View für einen Terrain Editor implementiert. Ich bin erstmal ganz naiv an das Thema rangegangen und hab mir gedacht: "gut, du brauchst vertices die Flächen aufspannen, die zerteilst du dann in Dreiecke und steckst sie in nen VertexBuffer, nachdem du die Indizes berechnet hast". Also habe ich in meinen Fachklassen Vertices und Faces (Flächen) die in einem Mesh zusammengefasst werden. Jede Face weiss für sich bescheid, welche Vertices zu ihr gehören und wie sie die per IndexBuffer in Dreiecke aufteilt. Klingt ja theoretisch erstmal gut...
Nun mein innerer Konflikt: diese Vertices und Faces sind meine Model Typen (vom MVC). Ich möchte unbedingt in meinem Programm die View vom Model entkoppeln, damit man einfach auf verschiedene 3D Technologien portieren kann (OpenGL, D3D...). Also habe ich nun diese ganzen Vertex- und Face-Daten etc. in eigene, simple Klassen gewrappt. Diese Daten stellen im Endeffekt auch das Ergebnis des Editors dar, dass dann editiert, exportiert und gespeichert werden kann.
Zum sichtbarmachen dieser Daten werde ich, so denke ich mir, einen VertexBuffer und einen IndexBuffer brauchen um die Primitiven zu zeichnen, die aus Dreiecken Bestehen (Jede Fläche hat 4 Vertices die eine viereckige Fläche aufspannen, die dann wieder in zwei Dreiecke zerteilt wird).
Das heist dann aber, dass all meine Vertexdaten redundant vorliegen - also einmal in meinem eigenen (MVC->Model) Format und nocheinmal im entsprechenden Vertexformat der jeweiligen View. Ich müsste dann jede Änderung, die der Benutzer macht in meinem Model updaten und dann noch einmal in der View, damit die Änderung gezeichnet wird. Dafür bräuchte man allerdings auch nur zu zeichnen, WENN sich etwas ändert.
Irgendwie fühlt sich das grad nicht gut an und ich habe Angst, dass es zu Performanceproblemen führen kann - ein Terrain-Mesh kann wirklich verdammt viele Vertices haben und die alle 2x vorhanden? Ist das wirklich der richtige Ansatz? Und es ist einfach zu viel Arbeit um es auf gut Glück zu probieren, nur um nach vier Wochen zu sehen, dass man komplett von vorn ansetzen muss.
Da ich ganz alleine an dem Prog sitze und ich es immer hilfreich finde, mit anderen Leuten über solche gedanklichen Engpässe zu reden dieser Beitrag hier. Vielleicht hat ja jemand lust sich mit mir Gedanken zu machen, oder weiss sogar schon bescheid, wie man so etwas angeht. Ich hab leider grad irgendwie ein brett vorm Kopf. Auf jeden Fall ist es mir wichtig MVC-gemäß die Daten von deren Anzeige unabhängig zu behandeln.
Oha, ist ja doch etwas länger geworden. Vielen Dank an alle, die die Nerven haben das zu lesen und mir einen Tip zu geben.
-
ja, zweimal das komplette terrain als mesh im speicher zu haben waere ein wenig overkill. normalerweise speichert man sich nur eine heightmap, diese editiert man dann auch (so als ob man in paint ne bitmap bemalt) und zur laufzeit generiert man denn die meshes zum zeichnen, wobei hier nicht alles gezeichnet wird, sondern mit LODs das sichtbare, bzw noetige.
-
Ich halte Deinen Ansatz fuer falsch.
Bei der Verwendung eines Map-Editors sollte man sich gerade nicht Gedanken um einzelne Polygone und Eckpunkte machen muessen, sondern auf einer gestalterischen Ebene arbeiten.
Ueberlege Dir doch zunaechst mal was Du mit Deinem Editor erreichen willst bevor Du Dir Gedanken um die untersten Datenstrukturen machst.
-
danke für eure antworten
@raposo: stimmt, das klingt effizienter. Allerdings stelle ich mir dann die Umsetzung der 2D Koordinaten vom Mauszeiger zum Mesh etwas schwierig vor; zumindest fällt mir nicht sofort ein, wie man es machen könnte. Ich würde ja gern eine frei schwenk- und positionierbare Kamera einbauen. Und irgendwie muss ich dann von einem Klick ins 3D-Terrain, das halt momentan auch aus einem schiefen Blickwinkel angeschaut werden könnte, auf die 2D Map-koords kommen.
Ok, es hätte auch den Vorteil, dass man auf diese Weise gleich noch Texturmaps, SpecMaps etc einfach "painten" kann. Ich werd mir mal ernsthaft Gedanken über deinen Vorschlag machen. Danke dir@hellihjb: ich hab ja meine Anforderungsanalyse schon fertig gestellt. Ich weiss schon was ich erreichen möchte, nämlich ein Terrain mit möglichst wenig Klicks zeichnen zu können. Und jetzt muss ich mir halt überlegen, wie ich das bewerkstellige, deshalb meine Frage.
-
mach es dir einfach, statt den mauscursor jedesmal aufs terrain zu mappen, projeziere einfach anhand der mauscoordinaten z.b. einen kreis (eine kreis textur) aufs terrain, nicht nur dass dann der graphiker sehen kann wo genau auf dem terrain das zeichnen waere und mit welcher groesser, du wuerdest es auch perfekt uebernehmen koennen.
ich hatte sowas schon paar mal geschrieben und so scheinen es die grahpiker echt zu moegen, auch wenn sie statt dem kreis selbst ne bitmap angeeben koennen mit der form des 'stempels' und wenn sie anhand der intensitaet dieser map sehen wie stark es sich dann auswirkt etc.
-
danke dir für deine tips, raposo. ich hab schon meine fachklassen umgebaut, da fällt schonmal einiges an ballast weg. ist viel übersichtlicher, obwohl es mir einige mühe macht mich in das neue konzept reinzudenken. aber ich sehe den vorteil deutlich.
das mit dem kreis werde ich wohl einfach mal ausprobieren müssen. es klingt zwar erstmal gut, aber ich hab spontan keine ahnung, wie ich das mache. aber ich denke, ich werds schon hinkriegen.
danke für die hilfe