4. Screenshot Thread - Eine gute Idee?

Screenshot Thread - Eine gute Idee?

  • X

    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 😉

    0
  • M

    celeron 2,6ghz 512mb ram ati radeon irgendwas...

    0
  • M

    und hier: quadcore mit 4x 2,9ghz, 2gig ram, nvidia 8800gt vista...

    0
  • ?

    Hallo

    Machine schrieb:

    und hier: quadcore mit 4x 2,9ghz, 2gig ram, nvidia 8800gt vista...

    Den nehm' ich. 😃

    chrische

    0
  • B

    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 🙂

    *Hier bin ich*

    0
  • M

    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?

    0
  • T

    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 🙂 )

    Bildschirmfoto 1

    Bildschirmfoto 2

    0
  • ?

    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. 😃

    0
  • T

    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 😃

    0
  • T

    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
    0
  • S

    sieht gut aus. kann man irgendwann auf quellen und dokumentation hoffen? 🙂

    0
  • T

    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.

    0
  • R
    Mod

    schaut gut aus, fehlt noch die nacht 😉
    wie ist die framerate?
    ich bin auch auf die doku gespannt 🙂

    0
  • S

    kool, na denn viel glück damit 🙂 👍

    0
  • T

    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.png

    rapso 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.png

    Wenn 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.

    0
  • G

    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

    0
  • T

    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).

    0
  • P

    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 😉

    http://www.abload.de/img/pivke6l7.jpg

    0
  • S

    ich arbeite zur zeit an einer externen mapapplikation für das online-rollenspiel eve-online.

    auf basis der verfügbaren daten (statischer datenbank export von ccp selbst und daten des ingame browsers) ist es möglich positionen der eigenen flotte darzustellen, wegpunktberechnungen durchzuführen und übliche daten über planetarische objekte anzeigen zu lassen. der server, welcher als http-server für den ingame browser dient und daten über die eve-api bezieht ist weitestgehend fertig, nun feile ich an der kartenapplikation selbst.

    dieser screenshot ist schon relativ alt:

    linkage

    hier habe ich noch mit dem GLWidget von QT experimentiert, was äusserst komfortabel ist, allerdings machte mir die performance der eventqueue von QT einige probleme.
    deshalb habe ich angefangen einige generische sachen unabhängig von QT portabel zu gestalten. mal sehen, vielleicht wirds ja nochmal fertig 🙂

    0
  • P

    @_sothis
    Sieht Nett aus, wie sieht es aktuell aus ?

    Also ich hab die letzten Tage noch ein bischen was getan, sieht jetzt so aus :
    http://www.abload.de/image.php?img=pivke_homep.kdj.jpg

    0
Anmelden zum Antworten