Maximale Anzahl an Objekten?
Übersicht
BlitzMax, BlitzMax NG Allgemein
InfectedBetreff: Maximale Anzahl an Objekten? |
 Fr, Sep 27, 2013 23:15Antworten mit Zitat 
|
|
|---|---|---|
|
Hallo! Gibt es eine Maximale anzahl an Objekten die ich in Blitzmax erstellen kann?
Ich erstell momentan in meinem "Minecraft"-Übungsprojekt für jeden Würfel ein Objekt.. komischerweise krieg ich Exeption Violation... Es sind schon einige Würfel die da erstellt werden.. rumzicken tut er genau bei 12x12 Chunks. Ein Chunk besteht aus 16x16x64 Blöcken, ist das zu viel? Bleibt mir keine andere Wahl als die Blöcke ausschließlich in arrays zu speichern? |
||
|
XeresModerator |
Fr, Sep 27, 2013 23:34 Antworten mit Zitat
|
|---|---|---|
|
Wenn du allen Speicher belegst, ist es egal in welcher Form du das tust. Wie viele Daten sind denn das tatsächlich? Wenn 1 Block = 4 Byte (Int) gilt, folgt schon mal 12x12x16x16x64x4 Byte = 9 MB als absolutes Minimum.
Oder du erstellt mehr Dreiecke in einem Surface als die Grafikkarte oder der Treiber verträgt... |
||
|
Win10 Prof.(x64)/Ubuntu 16.04|CPU 4x3Ghz (Intel i5-4590S)|RAM 8 GB|GeForce GTX 960
Wie man Fragen richtig stellt || "Es geht nicht" || Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld) |
||
Infected |
Fr, Sep 27, 2013 23:39 Antworten mit Zitat
|
|
|---|---|---|
|
In einem Surface werden immer die gleiche Anzahl an Dreiecken erstellt, das ist nicht das Problem..
Das Problem im ganzen ist folgendes: Damit es im Spiel nicht ruckelt, werden am Anfang direkt von allen Chunks die jeweiligen Koordinaten der Cubes berechnet, damit sie in Laufzeit dann nur noch aus den Types ausgelesen werden müssen. Die Cubetypes haben 3 Arrays, welche jeweils für die x,y,z vertices herhalten, die der Cube braucht. Es sind 24 vertices pro Cube. Mir fällt keine andere möglichkeit ein als diese Koordinaten eben in ein Type mit den Arrays zu speichern, oder in Laufzeit auszurechnen, das funktioniert allerdings nicht sonderlich gut, da es dann immer nen fetten Ruckler gibt.. Selbst wenn ich in Laufzeit vorher prüfe welche Seiten überhaupt angezeigt werden müssen, und nur die entsprechenden Seiten bzw. die Koordinaten ausrechne, gibt es immer noch einen Ruckler.. Irgendwas schein ich bei der ganzen Sache zu übersehen.. :/ |
||
|
|
XeresModerator |
Fr, Sep 27, 2013 23:51 Antworten mit Zitat
|
|---|---|---|
|
Ich kann mich ja irren, aber selbst wenn du 24 vertices hast, sind dass doch nur 8 Koordinaten - die wiederum von 8 Cubes genutzt werden könnten. Da wäre ein Array für Eckpunkte tatsächlich eine Optimierung.
Ohne Threads zu benutzen könnte es generell schwierig werden, ein Teil der Welt neu zu laden/generieren ohne Ruckler zu bekommen. |
||
|
Win10 Prof.(x64)/Ubuntu 16.04|CPU 4x3Ghz (Intel i5-4590S)|RAM 8 GB|GeForce GTX 960
Wie man Fragen richtig stellt || "Es geht nicht" || Video-Tutorial: Sinus & Cosinus THERE IS NO FAIR. THERE IS NO JUSTICE. THERE IS JUST ME. (Death, Discworld) |
||
Kruemelator |
Sa, Sep 28, 2013 15:21 Antworten mit Zitat
|
|
|---|---|---|
|
Die Eckpunkt der Würfel für eine Minecraft ähnlich Welt abzuspeichern ist extrem ineffektiv. Sie sind immer an den selben Stellen. Nur die Cubes abzuspeichern wäre effizienter. Mir würden jetzt zwei Möglichkeiten dazu einfallen, einmal ein 3D Array pro Chunk: array(16,16,64) oder eine Objekt Liste pro Chunk mit nur den Cubes die es wirklich gibt. Beid er Liste müsste man für jeden Würfel auch noch die Position mit ablegen. Bei dem Array nur die Art des Würfels. Außerdem kann man die Nachbarn eines Würfels in einem Array viel Schneller finden als in mit einer Objekt Liste.
Wenn es ruckelt wenn ein neuer Chunk erstellt wird dann erstelle ihn nicht am Stück. Anstatt alle 16*16*64 Cubes direkt zu erschaffen, mach erst 1000 und dann im nächsten Frame wieder 1000 und das solange bis der Mesh fertig ist. Du musst dir dann nur merken wo du zuletzt warst und ab da weiter machen. |
||
Infected |
Sa, Sep 28, 2013 17:56 Antworten mit Zitat
|
|
|---|---|---|
|
Hey!
Danke euch beiden für die Antworten! 
Komischerweise, wenn ich die Cubes nur aus nem Array lese und in Laufzeit die Coordinaten der Cubes ausrechne, hab ich jedes mal nen dicken ruckler. Man braucht ja die absoluten coordinaten für die Vertices, und nicht die position innerhalb des chunks. Das mit dem "nicht am stück" erstellen werd ich wohl mal probieren, danke 
|
||
PhillipK |
So, Sep 29, 2013 14:09 Antworten mit Zitat
|
|
|---|---|---|
|
Oh?
Nein, du brauchst die koordinaten innerhalb des chunks o.O Dein Chunk könntest du nämlich als eigenes Entity mit eigenem Mesh mit eigener Surface erstellen. Dieses Entity kommt auf die passende "anfangsposition" im raum, entweder an der linken / vorderen/oberen ecke ausgerichtet oder mit dem Zentrum des Chunks. Dabei ist es egal wieviele blöcke im Chunk tatsächlich gesetzt sind, dein chunk hat immer die gedachten kantenlängen von 32x32 und 64 höhe. Diesen Quader richtest du im Raum aus und die blöcke immer mit den selben koordinaten. Am besten kann man das ganze nachvollziehen, wenn mans sich aufzeichnet auf ein blatt papier. Allerdings: Sollte es so sein, das das in deinem jetzigen aufbau "klappt" , dh nur die Chunks werden gerendert, die im blickwinkel der kamera liegen, dann solltest du da meine aussage oben missachten. Wichtig ist, das das AABB des Chunks richtig die blocks umschließt. AABB ist ein prüfungsquader, der alle vertices des Meshes umfasst - ist nur eine kante im bild oder der AABB komplett um / in der kamera, werden alle faces und vertices gezeichnet. Ist nichts davon von der kamera zu sehen, wird der gesamte renderstep übersprugnen, was viel leistung einspart. ---------------------------- Das mit dem Ruckler musst du genauer erklären. Ist es so, das dein pc einfach lange braucht um ALLE chunks zu erstellen? Wenn ja, nicht am stück erstellen. Schon der richtige ansatz
Im idealfall hast du eine art radiusprüfung um den spieler herum. Alle chunks die innerhalb dieses radius liegen, müssen gezeichnet werden. Alle chunks, die ausserhalb liegen, müssen nicht zwangsweise existieren. Wenn du das mit 2 radien kombinierst, kannst du ein system aufbauen, dass: - Anfänglich alle Chunks im Sicht-radius erstellt (start lade-ruckler) - Alle chunks in der näheren umgebung, die nicht erstellt sind, in eine liste schmeißt - Pro frame zb. ein chunk aus soner liste erstellt - Chunks die viel zu weit weg sind aber vorhandern sind, löscht. (spart speicher und kann eine theoretisch unendlcihe map ermöglichen) Mal eine kleine skizze: 
Der punkt in der Mitte ist der Spieler, bzw der chunk in der sich befindet. Das grüne zeugs sind die chunks die sichtbar sein sollten - diese sind im idfealfall erstellt. Das dunkelorange sind chunks in der "Liste", zum erstellen. Da sieht man 2 der radien: MUSS sichtbar sein, SOLLTE erstellt werden. Aussen rum der dritte kreis ist die deadline für die existenz der spieler. Alles was erstellt ist, aber nicht innerhalb dieses radiusses, kann gelöscht werden. Ich meine wirklich gelöscht - zerstör den ganzen surface. Allerdings sind die radien auf dem screenshot nur grob gewählt. Wichtig wäre, das so 5x5 chunks um den spieler immer da sind, um schnelles umdrehen wie auch kleinere bewegungen möglichst flüssig laufen. Die chunks im 2ten radius sind dafür da, das der spieler beim durchqueren der map möglichst flüssige übergänge hat. Diese chunks müssen nicht sofort da sein, aber es wäre cool wenn sie es wären. Bewegt er sich nämlich in eine gewisse richtung, landet er irgendwann im nichts. Würden die chunks erst alle gebaut werden, wenn sie im innersten radius liegen, würde es (eventuell) arg ruckeln, da so ein surface zu bauen kein pappenstil ist. Wie dem auch sei, das ist auch nicht die beste lösung. Es gibt auch in dieser idee noch vielerlei verbesserungsmöglichkeiten. Zb könnten chunks auf die sich der spieler zubewegt eine höhere gewichtung bekommen und eher erstellt werden. Andere chunks aus dem orangen bereich, die vielleicht garnichtmehr im 2ten radius liegen, wenn sie erstellt werden sollen (sie sind an der reihe), könnten auch direkt übersprungen und aus der liste genommen werden. Chunks, die erstellt sind, könnten in einer anderen liste landen, die "Existenten Chunks" - diese liste ist schön klein, um sie alle X frames mit dem äussersten radius zu vergleichen. Nichtmehr da? Nichtmal annährnd in reichweite? WEg damit. Entschuldige meien wall of text 
Ist keineswegs kritisierung, ich hab nur leider zu oft selber so ne blöde map geschrieben (und nie ein spiel draus gemacht, ich depp.). Hat mich immer ein wenig arbeit gekostet, diverse dinge rauszufinden, weswegen ich sie nun mitteile ^^ Die tatsächliche lösung die für dich und dein vorhaben passt, musst du nach wie vor selber rausfinden :3 |
||
Infected |
So, Sep 29, 2013 14:44 Antworten mit Zitat
|
|
|---|---|---|
|
Hey, danke erstmal für deinen Text
Das soll im prinzip gar kein Spiel werden, es ist nur ein Lernprojekt, um die 3D Funktionen besser kennen zu lernen, und zu verinnerlichen
Also ich geh erstmal nur auf einen Punkt ein, später kommt mehr
Zitat: Allerdings: Sollte es so sein, das das in deinem jetzigen aufbau "klappt" , dh nur die Chunks werden gerendert, die im blickwinkel der kamera liegen, dann solltest du da meine aussage oben missachten.
Momentan werden alle Chunks gelöscht, welche nicht im bereich von 5x5 Blocks um den Spieler herum sind. Alle Blöcke die nicht sichtbar sind, werden nicht gezeichnet. Jetzt hab ich (dank dir) aber eventuell meinen Fehler gefunden. Jeder Chunk hat ein surface + zugehörige mesh, allerdings ändere ich von der mesh nie die position, sondern schreibe die vertices direkt in die absoluten koordinaten. Es wäre besser(wie von dir vorgeschlagen) die würfel einfach mit den chunk-coordinaten zu erstellen, und dann die chunk-entity an den passenden ort zu schieben. Danke für diesen Ansatz Mal schaun wie ich es umsetzen kann.
|
||
Übersicht
BlitzMax, BlitzMax NG Allgemein
Powered by phpBB © 2001 - 2006, phpBB Group