Screenshot Thread - Eine gute Idee?



  • an dem arbeite ich noch.. zur zeit male ich einfach das terrain blau an, je tiefer, desto blauer.. schaut eigentlich ganz passabel aus, braucht nicht viel performance und stört nicht, weil sowieso das ganze terrain ab einer bestimmten tiefe unter wasser steht


  • Mod

    spong3bob schrieb:

    an dem arbeite ich noch.. zur zeit male ich einfach das terrain blau an, je tiefer, desto blauer.. schaut eigentlich ganz passabel aus, braucht nicht viel performance und stört nicht, weil sowieso das ganze terrain ab einer bestimmten tiefe unter wasser steht

    👍 so hab ich es auch angestellt als gerade die ersten vertexshader raus waren.
    du kannst zudem mit ein bissl sinus die textur (oder auch ein wenig die geometrie) vom terrain wabbern lassen mit zunehmender tiefe.



  • Hier mal ein bild von meinem raytracer an dem ich gerade rumspiel, bisher nichts aufregendes eingebaut nur das gundgerüst, aber es wird langsamm *g*.

    http://www.urbsch.at/files/raytracing.png

    Was bisher drinn ist:
    Intersections für Dreieck und Kreis
    Octree
    Schrift per freetype
    Multithreading (Threadpooling)
    Texuring (nur ohne schöne texturverwaltung daher erstmal aus)
    Obj files Loader
    "Steuerbar" über netzwerk mit console (in c# geschrieben) (nur ganz simpele sachen wie "kameraposition setzen" oder "dreieck hinzufügen")
    hmm mehr fällt mir gerade nicht ein *g* (bisher nichtmal transparenz oder reflektionen^^)

    (Die Sphere besteht aus 2000 dreiecken und es gibt 2 lichter)

    Gruss



  • gpu raytracing:
    screen1
    screen2



  • hellihjb schrieb:

    gpu raytracing:
    screen1
    screen2

    openrt? :xmas1:



  • Ne, code selbst 😉



  • hellihjb schrieb:

    Ne, code selbst 😉

    sieht gut aus. wie lange hat er gebraucht? 🙂

    edit: dämlich ausgedrückt. ich meine wie lange hat das rendern gedauert? 🙂



  • Sieht echt gut aus...

    Aber mich interessieren auch mal die "FPS" 😃



  • Sind ja nur 4 Wuerfel, die laufen auf meiner Geforce 8600 in 640x360 mit rund 100 fps.
    Hier in Bewegung - allerdings nur 24 fps 😉



  • hellihjb schrieb:

    Sind ja nur 4 Wuerfel, die laufen auf meiner Geforce 8600 in 640x360 mit rund 100 fps.
    Hier in Bewegung - allerdings nur 24 fps 😉

    fetzt 👍


  • Mod

    da stimm ich zu. mal ein raytracer der nicht nur daten ausspuckt, sondern eyecandy. und die demo fetz eh, wie immer bei helli 😉

    ich hatte auch mal nen nachmittag fuer einen raytracer auf gpu geopfert (mit cuda). es sieht nicht ganz so praechtig aus, ich hab gerade noch nen schoenen psychedelic 'shader' draufgepackt. laeuft bei 512*512pixeln mit 1fps bei 54000spheres. wobei pro pixel jede sphere gecheckt wird (8800gt), das koennte man aber noch optimieren (ich berechne bei jedem treffer den shader und 'blende' additiv, es wuerde eigentlich reichen erst die richtige surface zu finden und am ende einmal zu shaden, zudem besteht mein shader aus einigen cos+sin+pow).

    ich hab noch einen prototype fuer ein hierarchycal-grid der laeuft zZ aber nur auf cpu. (da die weihnacht mir neue spielsachen beschert hat, werd ich kaum dazu kommen das auf cuda zu portieren 😞 )

    hellihjb, gibt es ein wenig tech-fachsimpel von dir zu deiner demo? 🙂



  • rapso schrieb:

    hellihjb schrieb:

    screen1, screen2, video

    gibt es ein wenig tech-fachsimpel von dir zu deiner demo?

    Viel zu "fachsimpeln" gibt es eigentlich nicht, da alles sehr simpel ist:
    Die "Objekte" (im Moment zwei, Chamfer-Box und Ebene) werden als Polygone gerendert.
    Pro Pixel wird der Strahl von Kamera zum Fragment an der Normalen gebrochen und gespiegelt.
    Der gebrochene Teil verlaeuft weiter durch das Objekt und wird beim naechsten Schnittpunkt wieder gebrochen (Strahl verlaesst das Objekt und trifft ggf ein anderes) und reflektiert (verlaeuft weiter im Objekt).
    Schnittpunkte werden anhand einer parametrisierten Darstellung des Objektes berechnet (im Fall der Chamfer-Box wird einfach der Schnittpunkt mit einem Wuerfel berechnet, liegt dieser am Rand einer Flaeche wird die "schraege" Normale genommen).
    Faellt ein Strahl senkrecht auf eine Flaeche geht mehr Licht durch das Material, trifft er schraeg auf wird mehr reflektiert, jede Teilkomponente wird anhand des zurueckgelegten Gesamtwegs gewichtet (1/Distanz^2), zusaetzlich gibt es eine Alphamap damit die diffuse Gesamtlichtdurchlaessigkeit variiert.
    Pro Strahl werden 3 Brechungs-Iterationen verfolgt, mehr ist moeglich, vom eigentlichen Material ist dann (wegen Distance-Attenuation) aber kaum noch was zu sehen und es vervielfacht sich nur die Spiegelung der Lichtquelle.
    Die Normalen sind aus Polygon- und durchschnittlicher Vertexnormalen gewichtet was die Reflektionseigenschaften interessanter macht (die eigentlich flachen Seiten werden ein bischen zum Parabolspiegel).
    Der Brechungsindex ist beliebig und betraegt im Screenshot 1.5. Mehr sieht "cooler" aber unnatuerlich aus, weniger waere realistischer aber weniger effektvoll.
    Fuer den Boden werden jeweils Strahlen von der Oberflaeche zur Lichtquelle betrachtet und ueberprueft, wie nah sie nach der Brechung am Objekt am Lichtzentrum vorbei gehen. Korrekt waere die Lichtmenge der Strahlen die den Wuerfel verlassen und den Boden treffen aufzusummieren; wuerde aber sehr "noisy".
    Bisher wird nur die naechste Lichtquelle betrachtet weil der Einfluss entfernterer Lichter gering ist (das Licht faellt in sehr flachem Winkel ein).
    Hier besteht aber noch Potential. Licht das aus einem Wuerfel austritt und an einem anderen zum Boden reflektiert wird, wird noch nicht betrachtet.

    Wenn's mal was Neues gibt, stell ich mal wieder 'nen Screenshot rein.



  • Ich steuere mal gute alte Rasterizer-Grafik bei - ich spiele ziemlich gerne mit shadow mapping rum. Ich habe eins mit randomisiertem lookup implementiert, ein ähnliches Verfahren kommt bei Crysis zum Einsatz. Außerdem werden die Lichtbeiträge pro Lichtquelle aufaddiert, der Schatten einer Lichtquelle dunkelt also nicht das Licht einer anderen ab (zwei Lichtquellen werden hier dargestellt).

    http://firbach.dyndns.org/garbage/shadows-0.jpg
    http://firbach.dyndns.org/garbage/shadows-1.jpg
    http://firbach.dyndns.org/garbage/shadows-2.jpg

    Fachsimpel: Für den Lookup wird mit Hilfe einer Poisson-disk der offset innerhalb der shadow map bestimmt. Damit die einzelnen samples nicht nur gegeneinander verschoben sind und ansonsten wieder die fetten Texel in die Szene projiziert werden, wird die disk für jeden Pixel zufällig rotiert. Ich biete mehrere Detailstufen an, auf dem Screenshot sind pro Pixel 16 Stichproben genommen, ab 5 sieht es eigentlich schon gut aus, ab 8 fällt auch bei bewegter Lichtquelle kaum noch ein Rauschen auf. Aus diesem Grund habe ich beschlossen, auf PCF oder Blurr, was in manchen Papers noch zusätzlich vorgeschlagen wird, ganz zu verzichten.

    Die shadow map selber wird ohne alpha-test gerendert, deswegen sieht man die einzelnen Blätter nicht. Das spare ich mir absichtlich ein, da ich auf lange Sicht sowieso noch plane, die disk entsprechend der blocker-receiver Distanz zu skalieren und das würde die Blätter vermutlich besonders betreffen (im Moment ist die Größe der Penumbra hart in den Shader eingecodet).

    Ich benutze übrigens Ogre als Grafikengine, das nimmt einem natürlich die ganze Shader-Programmierung nicht ab, aber zumindest das Einstellen der Lichtkamera. Die Shadersprache ist Cg.



  • hellihjb schrieb:

    [...]Wenn's mal was Neues gibt, stell ich mal wieder 'nen Screenshot rein.

    Da koennte man ein witziges 4k Intro draus machen. 😉

    Gruß, TGGC (Der neue Game Star)



  • Mal gelöscht.



  • Hier kann man meinen Software Raterizer bestaunen:

    http://loop.servehttp.com/~vertexwahn/uploads/software_screenshot9.png

    für Schatten wird Shadow Mapping/PCF/64 Samples/Irregular Sampling genutzt
    die Framerate ist jenseits von gut und böse 😉

    Momentan arbeite ich an einen Shader Interpreter, den ich schnell zusammengehackt habe. Die Arbeit daran werde ich mangels Zeit aber demnächst wieder einstellen:
    http://loop.servehttp.com/~vertexwahn/uploads/shaderInterpreter.png


  • Mod

    einer der schoensten rasterizer den ich sehe (also output maessig),

    wenn du shader eh als source hast, brauchst du nicht wirklich was interpretieren, schreib dir die noetige kleine lib fuer standartfunktionen und dazu typedefs auf float4 usw. und bau es als dll (die du dynamisch einladen kannst).



  • Nachdem immer alle nach Screens schreien, hab heute mal OpenGL-Shader implementiert. Das farbige im Hintergrund ist ein simpler Shader:
    http://img689.imageshack.us/img689/6757/screenshoth.png
    Nix besonderes, aber Ihr wolltet es ja so 😛

    // Vertex-Program
    
    // Globals
    varying float xpos;
    varying float ypos;
    varying float zpos;
    
    /* Main Method */
    void main(void)
    {
        xpos = clamp(gl_Vertex.x,0.0,1.0);
        ypos = clamp(gl_Vertex.y,0.0,1.0);
        zpos = clamp(gl_Vertex.z,0.0,1.0);
        gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
    }
    
    // Fragment-Program
    varying float xpos;
    varying float ypos;
    varying float zpos;
    
    void main (void)
    {
        gl_FragColor = vec4 (xpos, ypos, zpos, 1.0);
    }
    

    rya.



  • Ich finde diesen Screenshotthread wirklich toll. Das habe ich noch in keinem anderem Forum gesehen. Es ist auch toll sich durch die Seiten zu klicken und mal einfach zu sehen an was die anderen alle so arbeiten. Also ich bin wirklich sehr begeistert.


  • Mod

    Hatte letztes wochenende den quake1 source gezogen und ein wenig reingeschaut und irgendwie angefangen ein paar dinge zu erweitern, erstmal die MegaGraphLib durch standard win funktionen ersetzt, dann 32bit output eingebaut statt 8 bit, dann nach und nach 32bit durch die ganze engine gezogen. dann war es noch ein schrittchen um Bilineares filtering einzubauen. dann mittels vtune ein paar suboptimale stellen gefunden (ich nutze ja nur den c code software rasterizer, nicht asm) und es auf die 2.5fache performance gebracht und deswegen 640x480 eingeschaltet (laeuft weiterhin mit den 72fps limit von Q1)

    Quake 1 level: dm1
    http://www.rapso.de/ranz/Quake/009.png

    half life level support dazu:
    http://www.rapso.de/ranz/Quake/011.png
    http://www.rapso.de/ranz/Quake/012.png
    http://www.rapso.de/ranz/Quake/013.png

    ich sollte jetzt die finger davon lassen bevor bumpmapping und post effects in software drinnen sind.

    btw. die screenshots sind aus der debug version, deswegen die fps.


Anmelden zum Antworten