Screenshot Thread - Eine gute Idee?
-
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 fpsfetzt
-
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:
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.jpgFachsimpel: 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öseMomentan 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
-
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.
-
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.pnghalf 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.pngich 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.
-
Gute Idee, mit dem Screenshot-Thread. Da will ich auch mal was präsentieren:
Das Brettspiel Solitär:
http://img691.imageshack.us/i/highscoret.png/
http://img179.imageshack.us/i/game2q.png/
http://img84.imageshack.us/i/gameu.png/Eines meiner schönsten Spiele, wie ich finde.
MfG, Jochen
-
Wenn ich gerade mal dabei bin, hier ein paar Screenshots zum bewundern!
http://gm-squared.de/index.php?target=ingame_1.jpg
http://gm-squared.de/index.php?target=ingame_2.jpg
http://gm-squared.de/index.php?target=ingame_3.jpg
http://gm-squared.de/index.php?target=ingame_4.jpg
http://gm-squared.de/index.php?target=ingame_5.jpg
http://gm-squared.de/index.php?target=ingame_6.jpg f'`8kGruß, TGGC (Was Gamestar sagt...)
-
Die Geschosse würden mit etwas Motion-Bluring bestimmt noch echter wirken.
-
Naja, die Engine ist halt jetzt leider schon 7/8 Jahre alt. Ich bin froh, das sie wenigsten Antialiasing mit vertretbarer Aufwand noch einfuegen liess. Die Screenshots sind aber alle alt und haben noch nicht mal dieses Feature. f'`8k
Gruß, TGGC (Was Gamestar sagt...)
-
@vertexwahn: Ich bewundere die guten alte Software Rastergrafik, wo man noch alles selbst machen musste und deine Engine sieht echt toll aus.
-
Mein letztes Projekt war ein Map Viewer für System Shock 1. Hier sind ein Paar Screens
http://home.arcor.de/cppjunky/images/projects/shock_screen1.jpg
http://home.arcor.de/cppjunky/images/projects/shock_screen2.jpg
http://home.arcor.de/cppjunky/images/projects/shock_screen4.jpgIch überlege momentan, ob ich daraus eine eigene Oldschool 2.5D Engine basteln soll
-
das ist echt cool!
versuch mal http://en.wikipedia.org/wiki/Hqx auf die texturen anzuwenden :), zusammen mit dem filtering koennte das noch was bringen.