F
@zeropage sagte in Random Walkers 3D:
Die Heatmap repräsentiert die Schrittdistanz, oder ist das nur der Abstand zum Zentrum (sieht man nicht so ganz genau)?
Bei Heatmap musste ich erst wieder googeln, es könnte auf drei Verfahren in meinem Code hindeuten, die Farbgebung, das 'Node Heading' was als Wert im Video angegeben ist, die Schrittweite zwischen zwei Nodes.
Mit dem Begriff mein ich einfach nur die Farbe. In der Visualisierung codiert man schonmal gerne irgendwelche Daten-Werte mit einer Farbe und verwendet dabei bestimmte Farbverläufe/Paletten. Unter anderem auch solche RGB-Verläufe. Das kann z.B. ne Landkarte sein, bei der die Bevölkerungsdichte über die Farbe codiert ist oder auch beliebige andere Werte in beliebigen Dimensionen. Das nennt man alles "Heatmap", wobei der Begriff wohl am verständlichsten z.B. bei ner Landkarte ist, wo die gemessene Durchschnittstemperatur über so ne "rot-heiß-blau-kalt"-Farbpalette codiert wurde. Sorry, wollte damit keine Verwirrung stiften
Die Farbgebung ist einfach die x,y,z Koordinate eines Node umgerechnet in sphärische Koordinaten wobei der max-Radius die halbe (ungefähre, aus optischen Gründen) Diagonale des sichtbaren Würfels ist. Dieser Wert, bzw der Radius wird dann auf die Größe der Farb Palette 'remapt'.
Ah, das war nicht ganz so ersichtlich ob es Radius war oder vielleicht doch die gesamte Distanz, den ein einzelner "Walker" an dem Punkt mit der entsprechenden Farbe zurückgelegt hat. Das dürfte beides sehr ähnlich aussehen, bei Lauf-Distanz wäre da allerdings auch in der Mitte des Würfels etwas mehr Rot und Blau.
Damit kommen wir zu der Schrittweite. Die wird als Startwert vorgegeben, abhängig davon, wo der Walker starten soll. Die Schrittweite soll vom vorgegebenen Radius eines Node abhängen.
Beim Center, wie in diesem Fall, soll das sein:
case CENTER:
pos.clear();
vel = getRandomVelocity(1.0, node.Radius * 2);
break;
wobei hier das Heading dann 1.0 ist.
Ah, je weiter weg vom Zentrum des Würfels, umso größer die Bandbreite der nächsten möglichen Geschwindigkeiten, also umso schneller laufen die Walker im Durchschnitt. Zusammen mit dem Winkel sind das Parameter zum rumspielen, mit denen man wahrscheinlich sehr unterschiedliche Strukturen erzeugen kann, wenn man daran dreht.
.
Ansonsten: Schön solche Fortschritte zu sehen. Ich erinnere mich noch vage wie wir hier noch über Vektoren, Kameras und Transformationen diskutiert haben. Weiter so!
Ja, danke schön. An dieses Thema kann ich mich auch noch erinnern, wo ich auch wieder einige Zeit zum Reagieren benötigte und ich glaub das ist dann sogar eingeschlafen. Es ging damals darum, das meine Berechung für verdeckte Flächen irgendwo falsch oder unvollständig war. Jedenfalls blitzten in einem bestimmten Winkel immer wieder eigentlich verdeckte Flächen durch. Das Problem habe ich übrigens immer noch Könnte ich ja mal ansprechen, irgendwo gibt es bestimmt eine Lösung. Zum Glück trifft das hier nicht zu. Hier wird strikt von hinten nach vorne gepinselt.
Ich hab das nicht mehr so ganz im Kopf. Prinzipiell verwendet man im Echtzeit-3D-Rendering einen Z-Buffer (oder auch "Depth Buffer"), damit verdeckte Flächen nicht gerendert werden (oder genauer: verdeckte Pixel, der Z-Buffer eliminiert nämlich einzelne Pixel im finalen Bild). Da kann es aber schonmal zu Rundungsfehlern kommen, wenn die Parameter für den Z-Buffer nicht optimal sind und/oder zu weit von der Kamera entfernte Flächen gerendert werden. Da kommt es dann zu so einem "durchblitzen". Da müsste ich mich auch erst wieder was einlesen, das lässt sich aber sicher mit den richtigen Parametern minimieren. Allerdings haben auch hin und wieder diverse Spiele solche Probleme, wenn man genau hinguckt. Je nachdem was für Szenen man rendert, muss man da nämlich schonmal etwas tricksen. Der Z-Buffer hat nämlich nur eine feste Bit-Breite je Pixel und funktioniert nur in bestimmten Wertebereichen optimal ("Tiefe" des Pixels von der Kamera gesehen). Wenn man beliebig "tief gucken" will, muss man eventuell mehrere Z-Buffer verwenden und verschiedene "Tiefen-Schichten" der Szene separat mit jeweils anders konfiguriertem Z-Buffer rendern und die Renderings dann nachher zusammenfügen (so eine "Trickserei" ist aber meistens nicht nötig und auch zu komplex für einfache Sachen).
Ansonsten gibt es auch noch (oft) auf der CPU berechnete Techniken, mit denen man verdeckte Flächen eliminieren kann. Das fällt dann unter den Oberbegriff "Culling", wie z.B. "Backface Culling" (Flächen werden nur gezeichnet, wenn man von "vorne" draufschaut - sieht man bei Spielen häufig, wenn man sich z.B. in irgendeine Wand ge-"glitcht" hat und dann von der Rückseite durch alle Flächen "durchgucken" kann).
Oder "Frustum Culling", dabei werden alle Objekte beim Rendering verworfen, die nicht innerhalb des "View Frustum" (Pyramidenstumpf) des Kamera-Sichtfelds sind.
Und dann noch "Occlusion Culling", das eliminiert durch andere Geometrie verdeckte Objekte, ähnlich dem Z-Buffer allerdings etwas gröber und bevor die Geometrie überhaupt an die GPU geschickt wird (Z-Buffer läuft auf der GPU).
Das sind aber alles Techniken, mit denen man vornehmlich die Performance bei komplexen Szenen verbessert. Wenns nur um sauberes Rendering ohne "durchblitzende" Flächen geht, dann musst du lediglich den Z-Buffer richtig konfigurieren.
PS: Ich denke, ich bin im Unterforum 'Jenseits der Programmierung' doch falsch aufgehoben, Bei mir geht es doch gerade um Programmierung. Aber so ist 'my Life'...
Ich hätte sowas vielleicht unter Projekte gepostet, wenn du nen besseres Forum suchst
