Screenshot Thread - Eine gute Idee?
-
Also hier kannst du's schonmal runterladen: http://bloody-blades.de/dev/3D Solar System - Setup.msi
suess! schatten (und damit mondphasen etc) waeren noch schoen
Die Groessenverhaeltnisse sind etwas merkwuerdig:
Wenn man (ohne "vergroesserte Planeten") von der Erde Richtung Sonne schaut, ist die Sonne zu klein um sichtbar zu sein...
-
hellihjb schrieb:
Also hier kannst du's schonmal runterladen: http://bloody-blades.de/dev/3D Solar System - Setup.msi
suess! schatten (und damit mondphasen etc) waeren noch schoen
bei dir gehts? komisch...
-
hellihjb schrieb:
suess! schatten (und damit mondphasen etc) waeren noch schoen
Die Groessenverhaeltnisse sind etwas merkwuerdig:
Wenn man (ohne "vergroesserte Planeten") von der Erde Richtung Sonne schaut, ist die Sonne zu klein um sichtbar zu sein...Oh man lass mich bloß damit in Ruhe *g* Ich hab schon so viel Zeit in das Programm investiert.... ich weiß, dass der Mond eigentlich rein müsste und Schatten auch noch cool wären, aber irgendwie mangelts momentan an Lust und Zeit
Der Abgabetermin rückte eben näher und ich wollte lieber noch die Hilfe und solche Sachen einigermaßen gescheit schreiben.Dass mit der Sonne ist mir auch schon aufgefallen, aber die Größen müssen stimmen. Ich könnte mir vorstellen, dass das hier eventuell ein Genauigkeitsproblem ist.
Machine, welches OS benutzt du denn? Gib mal paar Daten von deinem Rechner
-
celeron 2,6ghz 512mb ram ati radeon irgendwas...
-
und hier: quadcore mit 4x 2,9ghz, 2gig ram, nvidia 8800gt vista...
-
Hallo
Machine schrieb:
und hier: quadcore mit 4x 2,9ghz, 2gig ram, nvidia 8800gt vista...
Den nehm' ich.
chrische
-
Ein Teilgebiet Indonesiens, die Farbe richtet sich einfach nach der Höhe, es gibt 158x259 Höheninformationen und ich bin froh, das das Ding langsam recht gut aussieht
-
chrische5 schrieb:
Hallo
Machine schrieb:
und hier: quadcore mit 4x 2,9ghz, 2gig ram, nvidia 8800gt vista...
Den nehm' ich.
chrische
jaaa, den wollen viele haben
warum läuft die simulation nur nicht.. wird da irgend n framework benötigt, oder so?
-
Hallo allerseits!
Als einstandspost will ich hier mal die ersten Screenshots meines aktuellen privaten Programmier-Projektes einstellen
Das ganze soll mal in einem Opensource Online Role Playing Game enden- wobei ich
mich zzt mehr auf die Subsysteme der Engine konzentriere (ist doch alles recht aufwendig )
-
Das sieht aus, als könnte es mal ein nettes Spiel werden. Was gibt es denn spielerisch schon so zu bieten? Kann man schon mehr machen als herumlaufen? Wird das Terrain geLODet? Soll der Himmel einen Sonnenaufgang darstellen? Falls ja, der wäre allerdings noch verbesserungswürdig.
Ne Konsole braucht natürlich jedes Spiel, hab ich inzwischen auch schon eingebaut.
-
Der spielerische Inhalt besteht momentan nur aus Testfunktionen-
zzt kann man zb. Klötze werfen um die Physik Engine zu testen.
Das Terrain wird mit einem einfachen Algorithmus GeLODed- was auch bitter nötig
ist . Der Himmel besteht nur aus einer Sphere mit einer Sonnenuntergangs Textur + Wolken Textur + Shader - ist nicht der weisheits letzter Schluss - aber das muss erstmal reichen.
Die Konsole ist zentraler Bestandteil der Engine - das Komplette System kann über diese gesteuert werden. (Events, etc.)
Momentan konzentriere ich mich aber darauf das Physik Modul (ODE) ordentlich zu integrieren. Damit sich die Avatare ordentlich abwickeln/abrollen können
-
So, ich bin mal so frei mein Projekt vorzustellen.
Im Rahmen meiner Master-Thesis habe ich eine Anwendung zur GPU-basieren Berechung von Atmospheric Scattering zur Echtzeit-Darstellung eines dynamischen Himmels sowie Aerial Perspective geschrieben.
Ein paar Screenshots findet man hier.
Einige Infos zur Implementierung:
- Theorie: Atmospheric Scattering (für Himmel und Terrain Aerial Perspective), basierend auf den Papern von Nishita
- Technik: DirectX10, SM4.0, C++
- Himmel: Implementiert in 2 unterschiedlichen Techniken. Einmal als SkyDome, wobei das Inscattering für jeden Dome-Vertex im Vertexshader berechnet wird. Ferner als SkyBox - hier werden pro Frame die 5 Seiten der Box berechnet (pro Rendertarget Texel wird ein Ray in die Scene geschossen und beim Schnittpunkt mit der Atmosphäre das Scattering ausgeführt) und anschließend die Box selber gerendert. Die Dome-Technique hat auf meiner GTX 8800 ca. 2900 FPS und die Box-Variante ca. 1000 FPS.
Zur Laufzeit können die Techniken gewechselt und sämtlichen Parameter des Atmospheric Scattering geändert werden. - Terrain: Höhendaten gespeichert als FP32-Stream, Normalenberechnung per MWE, Texturierung per Texture Splatting (5 Schichten, automatische Alphamap Generierung). LOD: Bruteforce
-
sieht gut aus. kann man irgendwann auf quellen und dokumentation hoffen?
-
Nun ja, ich schreibe gerade an meiner Thesis und wenn die fertig ist, hat man quasi eine komprimierte 80 Seiten Dokumentation.
Bis dahin hab ich ein kleines Video erstellt: http://www.youtube.com/watch?v=lyPhwGoAqRw
Die Qualität ist zwar mies, aber man bekommt einen kleinen Eindruck, wie es in Bewegung aussieht.
-
schaut gut aus, fehlt noch die nacht
wie ist die framerate?
ich bin auch auf die doku gespannt
-
kool, na denn viel glück damit
-
rapso schrieb:
schaut gut aus, fehlt noch die nacht
Öhm, die Nacht ist eigentlich bereits drinnen. Sieht man auch in dem Video und auf einem Screenshot in der Galerie.
Hab gerade nochmal einen Screenshot mit etwas höherem diffusen Licht gemacht:
http://www.infoboard.org/screenshots/msc thesis/night.pngrapso schrieb:
wie ist die framerate?
Mit dem SkyDome Ansatz (Berechung der Rayleigh- und Mie-Inscattering Intensity für jeden Vertex einer Hemisphäre) erreiche ich bei einem 900x600 Fenster auf einer GeForce 8800 GTX ca 2500 FPS, siehe Titelzeile:
http://www.infoboard.org/screenshots/msc thesis/fps1.png
Bei dem Box Ansatz (Pro Frame rendern in 5 Seiten einer Skybox, wobei für jeden Texel die Farbe per Raycasting errechnet wird) komme ich auf ca 800 FPS:
http://www.infoboard.org/screenshots/msc thesis/fps2.pngWenn ich noch das Terrain mit Brute Force (mit über 500 000 Vertices) plus Aerial Perspective aktiere, habe ich ca. 200 FPS. Die große Performance-Bremse ist also das Brute Force Rendern des Terrains - hier könnte man mit einem LOD Algo noch viel rausholen. Aber das Terrain und LODs waren nicht Bestandteile meiner Arbeit, drum wollte ich da nicht zu viel Zeit verschwenden.
-
this->that schrieb:
Einige Infos zur Implementierung:
- Theorie: Atmospheric Scattering (für Himmel und Terrain Aerial Perspective), basierend auf den Papern von Nishita
- Technik: DirectX10, SM4.0, C++
- Himmel: Implementiert in 2 unterschiedlichen Techniken. Einmal als SkyDome, wobei das Inscattering für jeden Dome-Vertex im Vertexshader berechnet wird. Ferner als SkyBox - hier werden pro Frame die 5 Seiten der Box berechnet (pro Rendertarget Texel wird ein Ray in die Scene geschossen und beim Schnittpunkt mit der Atmosphäre das Scattering ausgeführt) und anschließend die Box selber gerendert. Die Dome-Technique hat auf meiner GTX 8800 ca. 2900 FPS und die Box-Variante ca. 1000 FPS.
Zur Laufzeit können die Techniken gewechselt und sämtlichen Parameter des Atmospheric Scattering geändert werden. - Terrain: Höhendaten gespeichert als FP32-Stream, Normalenberechnung per MWE, Texturierung per Texture Splatting (5 Schichten, automatische Alphamap Generierung). LOD: Bruteforce
Hallo,
die Screenshots schauen super aus, respekt. Ich habe mich vor einiger Zeit ebenfalls mit den Thema auseinander gesetzt, daher würden mich einige Details deiner Implementierung interessieren:
1. Warum benutzt du Direct3D 10? Ich kann für den Anwendungsfall keine großen Vorteile sehen (höchstens vielleicht fürs Terrain).
2. Berechnest du die Lookup-Table für die Luftdichte auf der Grafikkarte oder auf der CPU?
3. In welchen Intervall berechnest du die Lookup-Table neu?
Danke im voraus & Gruß
gruntle
-
gruntle schrieb:
1. Warum benutzt du Direct3D 10? Ich kann für den Anwendungsfall keine großen Vorteile sehen (höchstens vielleicht fürs Terrain).
Hauptsächlich weil es der Fachbereich meiner Uni wollte;) Es ging quasi auch darum die neueste Technik zu benutzen, um die Verwendbarkeit von Atmospheric Scattering in aktuellen Echtzeit-Anwendungen zu ermitteln. Wirklich notwendig wäre nur SM3.0 für den Vertex Texture Fetch gewesen.
gruntle schrieb:
2. Berechnest du die Lookup-Table für die Luftdichte auf der Grafikkarte oder auf der CPU?
Das sind meine 2 wichtigsten Formeln:
http://www.infoboard.org/screenshots/scattering.png
und ich berechne die Optical Depth t (für Rayleigh und Mie) sowie die Dichte e^(-h/H0) (wieder für Rayleigh und Mie) auf der CPU vor. Diese 4 Werte passen genau in einen Texel mit RGBA Format einer 2D Textur (Lookup table).
Zur Laufzeit hab ich dann lediglich das äußere Inscattering Integral - alle Werte innerhalb dieses Integrals sind nur noch Texture Fetches in die LUT.
Es gibt zwar noch einige Fallstricke, aber das führt hier zu weit;)gruntle schrieb:
3. In welchen Intervall berechnest du die Lookup-Table neu?
Die x-Achse der LUT enspricht der Höhe in der Atmosphäre, die y-Achse beschreibt einen Winkel. TexCoords von (0.5, 0.5) ensprechen z.B. einem Strahl, der auf halber Höhe der Atmosphäre startet und im 90° Winkel abgefeuert wird. An dieser TexCoord steht dann die Optical Depth t für diesen Strahl.
Die LUT wird einmal bei der Initialisierung der Anwendung berechnet und danach nie mehr. Da sie nur von der Höhe der Atmosphäre und der Dichteverteilung abhängt, die sich ja nicht so oft ändern;), ist es auch nicht notwendig. Dennoch kann die LUT zur Laufzeit verändert werden - das sieht man in dem youtube Video, wo ich die 2 Regler ganz unten rumschiebe (das verändert die Rayleigh, Mie Dichte).
-
Huhu,
ich hab gestern mal angefangen mein kleines Homeproject
zu starten. Es soll natürlich noch wachsen, später soll
auch noch ein Terrain per HeightMap mit implentiert werden,
Texturierung kommt selbstverständlich auch noch
