Screenshot Thread - Eine gute Idee?
-
Verdammt, wollte die Tage auch nen DFF-Loader schreiben, bin ich wohl doch nicht der einzige >_<.
-
Ich arbeite jetzt schon einige zeit an einer engine..
als letztes hab ich mir das wasser vorgeknöpft. is zwar noch ned ganz fertig/perfekt aber ich denk doch schon ansehlich..
-
Interessant. Wenn's nicht zu viel Mühe macht, kannst du nochmal nen Screenshot posten wo man den Übergang vom tieferen Wasser zum Ufer sieht? Arbeitest du mit volumetrischem Nebel?
-
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
-
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
-
-
-
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 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).
