Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.
Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.
This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Ich habe nun von mehreren gehört, dass sie das alte in Bezug auf die Abrundungen der Geometrie schöner fanden und ob ich es denn so wieder einbauen würde.
Also erstmal muss ich sagen, dass der alte Algo wirklich die Geometrie gesmoothed hat. Dadurch musste ich aber die Umgebung mit betrachten und es war dadurch viel langsamer. Dann ist es gar nicht wirklich möglich, richtige Rundungen zu bauen, wenn man pro Würfelseite nur einen 3x3 Patch verwendet. Außerdem ist, wenn man sich das Wireframe betrachtet, die Geometrie eigentlich gar nicht wirklich runder...
Es handelt sich dabei eher um eine optische Täuschung. Denn damals habe ich das Gras nicht nur auf der Oberseite der Würfel wachsen lassen, sondern rings um.
Da die Graskante so gerade abgeschnitten ist ( was sich später aber noch ändern wird ).
Habs zum Vergleich zwei Screens gemacht:
Und nochmal zwei, wo ich mal versucht habe, es aus dem neuen und alten Stonequest zu vergleichen:
( Das Alte war also nicht wirklich abgerundeter )
Zuletzt geändert von Zudomon am 10.11.2011, 08:12, insgesamt 2-mal geändert.
Im Wireframe [F4] sieht man sehr schön, wie die einzelnen Cluster weggeculled werden...
Außerdem wird nun beim erstellen auch das Occlusion herangezogen, so haben Cluster, die näher an der Camera sind die höchste Priorität... sind sie Occluded, dann verlieren sie an Prio, sind sie hinter der Camera, dauert es noch länger, bis sie erstellt werden...
(vielleicht ändere ich die Reihenfolge noch ab, muss ich mal schauen, wie sich das auswirkt )
Zudomon hat geschrieben:Außerdem wird nun beim erstellen auch das Occlusion herangezogen, so haben Cluster, die näher an der Camera sind die höchste Priorität... sind sie Occluded, dann verlieren sie an Prio, sind sie hinter der Camera, dauert es noch länger, bis sie erstellt werden...
(vielleicht ändere ich die Reihenfolge noch ab, muss ich mal schauen, wie sich das auswirkt )
FAIL... nachdem ich jetzt mal eine kleine Debugausgabe reingebracht habe, muss ich feststellen, dass das gar nicht funktioniert.
Die Cluster sollen zwar entfernt werden, wenn sie außerhalb der Reichweite sind... aber tatsächlich entfernt werden sie dann erst, nachdem sie generiert wurden. Da die Anzahl der gesamt Cluster und der zu benötigten Cluster gleich ist, können auch nur neue generiert werden, sobald die anderen tatsächlich entfernt sind.
Das bedeutet dann letztendlich, dass man munter ins leere fliegen kann, die Generierung aber stoppt, und zwar solange, bis die generierten außerhalb des Einflusses sind... ich hoffe, wenn das behoben ist, dass es dann nicht mehr möglich sein wird, ins leere zu fliegen.
( So nebenbei ist das eigentlich gar nicht so wichtig, da man hinterher sowieso nicht so schnell durch die Gegend fliegen kann, außer man craftet sich dann einen Drachenflieger oder ähnliches :D )
Dass das Occlusion zur generierung mit rangezogen wird, hatte ich gerade schon fertig. Da war einfach in der State-Logik noch ein Fehler.
Der andere Fehler mit dem Cluster-Kill war auch sehr einfach... ich hatte die Bedigung ein IF zu tief, und zwar erst killen, wenn erzeugt.
Nachdem ich das drin hatte, ist ein weiterer Fehler aufgetreten, den Artifical Mind mir die Tage beschrieben hat:
Es entstehen seltsame Löcher in der Landschaft. Die auch nicht weg gehen und auf verschiedenen Detailstufen existieren. Ich muss dazu sagen, er hat 8 Kerne und wir haben vermutet, dass es wohl irgendwie am Multithreading liegt, dass sich da noch was in Gehege kommt. Nachdem ich den Fehler aber nun bei mir hatte, konnte ich den doch recht schnell finden. Und zwar habe ich beim zerstören des Clusters den Index für die einzelnen Geometrielod's nicht wieder zurückgesetzt.
Ich hoffe, bei Artifical Mind war es das gleiche Problem.
Allerdings habe ich noch Ruckler, beim Clustergenerieren...
Ansonsten ist das erstellen der Cluster nochmal beschleunigt.
Während ich vorher jede Schicht des 3D-Clusters einzeln in eine Textur gerendert habe und die Daten anschließend kopiert wurden, habe ich nun begonnen, alles in eine größere Textur zu rendern und dann nur einmal die Daten zu holen bzw. immer, wenn die Textur voll ist. Das hat das erstellen, auch wenn es hier etwas schwierig ist, Zeiten an zu geben da der Wert sehr streut, von etwa 6 ms auf 1,5 ms runtergedrückt ( wohl gemerkt nur das GPU-Prebuilding, nicht das generieren des ganzen Clusters ). Allerdings ist mir nun noch der Gedanke gekommen, eine Textur an den Shader zu übergeben, der mir sagt, welche Voxel genau berechnet werden sollen ( vorher habe ich über Konstanten den ganzen Clusterbereich angegeben ). Das ermöglicht mir, mit einem DrawCall die kompletten 3D-Clusterdaten zu generieren... wenn das klappt, dann könnte ich noch einen Schritt weiter gehen und mit einem Move diese Daten schließlich holen. Es könnte allerdings auch noch funktionieren, dass ich Daten selbst garnicht mehr an einen eigenen Buffer übergeben muss, da ich ja die Renderdaten in ein extra Surface kopieren muss und vielleicht kann ich das auch direkt dann zum erzeugen des Clusters benutzen.
Weitere Optimierungen, die mir noch im Hinterkopf schweben:
Man könnte einen ähnlichen Shader machen, der mir den Noise-Wert zurückgibt. Denn da das Noise ja eine gewissen Frequenz hat, kann ich bei zu hohen oder niedrigen Werten auch annahmen über die Umgebung treffen. So könnte ich Anhand eines Pixels entscheiden, ob ein Cluster komplett Luft oder Erde ist, und wenn zudem dann keine Veränderungen vom Spieler getätigt wurden, muss das Cluster nicht mehr weiter berechnet werden und kann als leer ( von der Geometrie her ) eingestuft werden.
Da könnt man nun noch weiter gehen und statt einen Pixel, was zum Rendern schon sehr verschwenderisch ist, einfach auch einen 32² Block rendern... wobei jeder Voxel dieses Blockes dann für ein Cluster steht und mir direkt sagt, ob es leer ist oder nicht.
Aber diese Optimierung hebe ich mir noch für später auf. Was ich zeitnaher einbauen werde, ist, dass der Indexbuffer vernünftig benutzt wird. Denn im Moment wird zwar der Indexbuffer verwendet, aber Vertices sind nicht zusammengefasst. So ist das im Moment ziemlicher Overhead.
Ich werde jetzt schonmal ein neues Release online stellen. Allerdings ist das mit dem "auf eine größere Textur" die Clusterschichten rendern gerade deaktiviert, um da den nächsten Schritt angehen zu können.
Vielleicht noch ganz interessant das anzeigen, welches Cluster nun generiert wird auf [F8]
Es hat sich eigentlich nicht groß was geändert. Aber weil ich in dem anderen Thread geschrieben hatte, wo die Screens und Videos hingespeichert werden aber das noch nicht auf dem Server liegt, das Update.
Im Moment Frage ich mich, ob man nicht in kauf nehmen sollte, dass man den Aufbau der Welt sieht. Dann könnte man nämlich das erstellen eines Cluster soweit herauszögern, bis es tatsächlich benötigt wird. Das bedeutet dann natürlich auch weniger Speicherverbrauch. Angenommen man unterirdisch was weiß ich was alles gebaut und bleibt aber nur an der Oberfläche, dann sollte das schon was aus machen.
WIe wäre es den die SIcht soweit einzugrenzen dases möglichgst speichersparend ist. es gibt dann aber ein Fernglas das man per Knopfdruck aufrufen kann dann kannst die restichen Blöcke vorladen so das zb eine Meldung kommt (bitte warten) und man kann dann weiter sehen.
SO auf die Art muss man sich dann zb einen hohen Berg suchen um von dort runtersehen zu können.
Ja, das wäre ja dann sehr speichersparend, also wenn immer nur das generiert wird, was sichtbar ist... dann könnte man alles, was vielleicht eine Minute lang nicht sichtbar ist wieder rausschmeißen.
Im Moment bin ich ziemlich ratlos... habe Artefakte in meiner Landschaft.
Diese treten immer nur in der Diagonalen auf. Der Unterschied ist, dass ich nun die Voxel, die berechnet werden sollen, über eine Textur reingeben... ich denke mal dass der Fehler beim sampeln liegt. Wenn ich mir die einzelnen Bilder für einen Cluster anschaue, dann könnte es schnell vorkommen, dass da was verrutscht...
Hier ist ein Clusterbild zu sehen... wenn man sich das genau anschaut, dann meine ich darauf sogar einen dieser Ausreißer zu erkennen... ein Pixel der da abgeht und nicht hingehört...
Du hast schon bedacht, dass du da nur 16–24 Bits Rechengenauigkeit hast? Ich kenne deine Rauschalgorithmen nicht, aber könnte ja sein, dass die volle einfache Genauigkeit erfordern …
hm vor ein paar tagen liefs noch bei mir, jetzt seh ich leider nur noch ein hellblaues fenster :(
WinXP, älterer Core2Duo und irgend eine Radeon X1900 ;)
Also es muss definitiv an dem neuen Verfahren liegen, also das ich eine Textur benutze... denn in der alten Version funktioniert das tadellos...
Was ich mit Textur: Vorher habe ich einfach die Slices gerendert, Schicht für Schicht und per Constante dem Pixelshader übergeben, welcher Bereich der Welt berechnet werden soll... da so immer ein zusammenhängender Bereich berechnet werden muss, habe ich mir gedacht, eben diese Textur zu machen, in der dann drin steht, welcher Voxel denn nun Berechnet werden soll. So kann ich dann die Voxel so berechnen, dass ich sie hinterher direkt als eindimensionales Array verwenden kann... ich kann mir nur vorstellen, dass da bei der Texturkoordinate was falsch läuft...
Dabei habe ich mit normalen Texturkoordinaten, aber auch mit VPos den gleichen Fehler...
Da ich ja viel Try und Error mache, hab ich dann mal mit Linear und Point Sampling ausprobiert... und mit den Constanten rumgespielt, die sagen, dass ein halbes Texel verschoben werden soll... hat alles nichts gebracht... wenn die Artefakte an der Stelle weg waren, tauchten an anderer Stelle viel krassere auf.
@LONy Kannst du mal einen Screen posten?
Achso, sorry, ich bin echt müde... hatte gelesen, ein halbblaues... ganz blau ist normal... dann biste wohl irgendwo in der Luft oder im Boden... versuch mal mit [F10]... ansonsten würde mir nur einfallen, dass es an den Occlusion Queries liegt.
Hey cool, ist das mit Delphi gemacht? (Wenn ja, willkommen im Club [naja nicht ganz, ich nutze Lazarus])
Generell zum Konzept: Ich bewundere, wie du die Blöcke so rund bekommen hast, jedoch einige Gedanken:
- Minecraft hat total harte Blöcke
- Voxel-Engines wie Iehovah basieren komplett auf rundgelutschten Iso-Surfaces
- Du hast sowas mittendrin: Es sieht sowohl rundgelutscht aus, als auch eckig. Also nicht soo optimal
Ansonsten, coole Sache.
antisteo hat geschrieben:Hey cool, ist das mit Delphi gemacht?
Jap, alles Delphi.
antisteo hat geschrieben:Es sieht sowohl rundgelutscht aus, als auch eckig. Also nicht soo optimal Ansonsten, coole Sache.
Tja, kann ja nicht alles perfekt sein. Allerdings wird es hinterher auch ne Möglichkeit geben, dass eckiger zu machen... weil wenn man eine gerade Wand bauen will, dann ist es bestimmt nicht erwünscht, dass die so rund wird.
width und height sind die Texturgrößen und entsprechen dem Rendertarget sowie der Eingabetextur... habe
da auch schon mit (width-1) und (height-1) rumprobiert, aber dann sind die Artefakte weg, aber an den Clustergrenzen enstehen viel krassere.
"start" ist die Koordinate der kleinsten Voxelkoordinate im Cluster.
SetPS setzt die Pixelshaderkonstante... der erste Parameter ist der Index.
Hier noch die Eingabetextur:
Die ist im Format D3DFMT_A32B32G32R32F
Und gibt die Integerwerte aus... ( hmmm, okay, könnte man noch optimieren ) hatte die jetzt die Darstellung etwas runterskaliert... von den Farbwerten her, sonst wäre ja alles weiß.
So, das Texturformat für die Offsettextur ist nun auf D3DFMT_A8R8G8B8 geändert... die Datenübergabe und der Shader angepasst, aber die Artefakte bleiben.
Wie groß ist denn der Abstand der blauen Pixel? Die scheinen ja durchaus periodisch aufzutreten … vielleicht findet sich die Zahl irgendwo in deinem Algorithmus wieder …?
Mal PIX und Reference Device probiert um Treiber- und Hardwarefehler auszuschließen und die Shader zu debuggen?
@LONy
Das scheint dann ein richtiger Fehler zu sein... hast ne PN...
@Krishty
Um schon mal spontan deine erste Frage zu beantworten, ein Cluster hat 34³ Voxel... da die Artefakte immer diagonal angeordnet sind, wird es sich irgendwo um diese Zahl belaufen. Wenn ich z.B. den StartOffset weg lasse, so das immer das gleiche Cluster in der Landschaft erstellt wird, treten die Artefakte nicht auf. Also scheint es an den Koordinaten zu liegen...
Mit Referencetreiber bekomme ich es irgendwie gar nicht zum laufen... oder meine Geduld ist zu niedrig, aber nach ein paar Minuten sollte doch mal was zu sehen sein.
An den Texturkoordinaten liegt es auch nicht... habe nun das Eingabebild mit dem im Shader verglichen ( also wenn der Shader nur die Eingabetextur rausschreibt )... wenn ich dann auf Difference gehe, ist alles exakt gleich...
Eine weitere Vermutung die ich habe, dass vielleicht wirklich die Genauigkeit zu gering ist... vielleicht weil das Offset addiert wird?
nachdem ich das nun gemacht habe, fällt mir auch ein, dass meine Konstantenübergabe damals auch irgendwas mit 0.5 dazurechnen war... warum weiß ich nicht, vielleicht hat es was mit dem modulo im shader zu tun oder was weiß ich... ist mir auch egal... es klappt und ich bin immer erstaunter wie man ohne plan einfach durch rumprobieren immer auf Lösungen kommen kann.
Für mich klingt das eher, als hättest Du einen linearen Filter bei den Texturzugriffen verwendet. Ein Texturzugriff genau bei 0.000f sampled dann den ersten Texel und den links/oben/vorne benachbarten Texel zu gleichen Teilen. Wer weiß, was dort stand. Mit +0.5 Texeln liegst Du dann genau in der Mitte eines Texels und auch der bilineare Filter liest das korrekte Ergebnis.
Öh... stimmt ja eigentlich was du sagt... aber der Offset wird ja nachdem es aus der Textur gelesen wurde, addiert... also an dem Punkt wird nirgends mehr aus einer Textur gelesen. Das ändert nur noch die Koordinate für das Noise.
Will mal nachziehen und auch noch mein Sonntagsupdate rausbringen... :D
Version 0.0.67
Die Daten für einen Cluster werden nun in einem Drawcall komplett generiert... dadurch sollte es etwas schneller gehen.
Und Cluster werden nur generiert, wenn sie benötigt werden. Also erst, sobald sie Sichtbar sind... das ist vielleicht noch nicht so schön, aber dadurch generiert der sich nicht tot.
Achso, und die Fluggeschwindigkeit ist verdoppelt...
