(überflüssige) Demo
-
Hier mein überflüssiger Beitrag zu Weihnachten:
http://www.fh-merseburg.de/~roesch/mirror/download/ZweiD.zip(Leider konnte ich die letzten Tage nicht posten, darum erst jetzt.):
Bye, TGGC
-
ACHTUNG AN ALLE: DIE DATEI IST VOLLER VIREN!!!
Nein, Quatsch!
Die Demo gefällt mir sehr gut, besonders dass es so flimmert. Dadurch wirkt es irgendwie wie durch einen Restlichtverstärker gesehen (ich nehme mal an, das Flimmern soll den Zweck von Anti-Aliasing erfüllen?). Schöne Lichteffekte.
Aber mit Weihnachten hat das doch nicht viel zu tun, oder? Nur, dass am Ende "X-Mas" da stehtEDIT: Wenn Du den Quellcode freigibst, können wir Dir sicherlich helfen, das Ding noch ein bisschen zu optimieren...
[ Dieser Beitrag wurde am 27.12.2002 um 14:35 Uhr von TomasRiker editiert. ]
-
sieht gut aus! aber warum son dos ding??
-
gibt den source auch zum download?
-
Und warum ist das Ding im High-Modus so langsam?
-
Wie kommst Du auf die Idee, dass das ein "DOS-Ding" sein sollte?!
Es ist mit 100%iger Sicherheit KEINE DOS-Anwendung. Ich tippe mal auf DirectDraw.
Warum es so langsam ist, ist doch wohl klar. Im "High"-Modus ist die Auflösung höher, es müssen also mehr Bildpunkte berechnet werden...[ Dieser Beitrag wurde am 27.12.2002 um 17:48 Uhr von TomasRiker editiert. ]
-
ne, also die auflösung ist es schonmal nicht.
low.bat - 640 * 480
high.bat - 640 * 480 also die gleiche
ultra.bat - 1024 * 768Außerdem laufen ja Spiele bei mir auch flüssig in diesen Auflösungen. Und in dieser Demo ist nun überhaupt nichts besonderes an Grafik im Gegensatz jetzt zu kommerziellen Spielen.
-
ich hab mal in der readme datei nachgeschaut. eigentlich sollte low.bat eine auflösung von 320x240 haben, aber mein bildschirm zeigt 640 * 480 an. na ja, aber wie gesagt bei spielen geht das ja auch flüssig.
-
Ein Spiel ist doch was völlig anderes als eine Real-Time-Raytracing-Demo!
Vielleicht ist die Auflösung gleich, aber das Raster ist grober. Durch die Interpolation (vielleicht hat er auch Direct3D benutzt und auf eine Textur gezeichnet und dann bilineares Filtern eingeschaltet) sieht man die einzelnen Pixel kaum. Also es werden mehr Bildpunkte berechnet, zwischen denen interpoliert wird.
-
BTW: OpenGL wird benutzt.
-
Aber mit Weihnachten hat das doch nicht viel zu tun, oder? Nur, dass am Ende "X-Mas" da steht
Ich sag ja überflüssig ;). Hab ich aus Langeweie für 'nen unsinnigen Contest gemacht:
http://mcdeck.dword.org/contest/index.htmlsieht gut aus! aber warum son dos ding??
Es ist kein Dos-Ding und benutzt auch kein DX. Es basiert auf einem NeHe Sample und benutzt OpenGL (wie schon korrekt bemerkt wurde). Lag daran das ich hier nur 'ne alte DevC++ 4.0 Version hatte. Meine ganzen CodeSamples usw. hab ich auch nicht hier gehabt, weil ich über Weihnachten nicht an meinen Arbeitsrechner (inkl. Daten) rankomme. Also hab ich mir zur Anzeige halt das erstbeste geschnappt.
Und warum ist das Ding im High-Modus so langsam
Es ist immer gleich schnell, nur werden mehr oder weniger Frames gezeigt.
eigentlich sollte low.bat eine auflösung von 320x240 haben, aber mein bildschirm zeigt 640 * 480 an.
Dann ist die Anzeige falsch oder dein OGL Treiber ignoriert die Auflösung.
Und in dieser Demo ist nun überhaupt nichts besonderes an Grafik im Gegensatz jetzt zu kommerziellen Spielen.
Doch, die physikalisch korrekten Schatten, die einen weichen Übergang haben.
Vielleicht ist die Auflösung gleich, aber das Raster ist grober. Durch die Interpolation (vielleicht hat er auch Direct3D benutzt und auf eine Textur gezeichnet und dann bilineares Filtern eingeschaltet) sieht man die einzelnen Pixel kaum. Also es werden mehr Bildpunkte berechnet, zwischen denen interpoliert wird.
Die Auflösung spielt wirklich kaum eine Rolle (geht nur auf die Fillrate, von der sollte eigentlich genug über sein). Das Bild wird in eine Textur gerendert (ohne HW Support der GraKa!), deren Auflösung ist wirklich wichtig für die Geschwindigkeit. Die Textur wird dann gerendert und dabei bilinear gefiltert. Man kann alles einstellen, einfach mal in der readme oder *.bat schauen, da stehen die parameter drin.
EDIT: Wenn Du den Quellcode freigibst, können wir Dir sicherlich helfen, das Ding noch ein bisschen zu optimieren...
Ja, kann ich in nächster Zeit mal machen. Das Ding könnte eine ordentliche Raumpartition gebrauchen, damit man mehr Primitives benutzen kann. Das hab ich in der kurzen Zeit aber nicht hinbekommen.
zur Technik:
Es handelt sich um einen 2D Raytracer. Die Idee ist, das die Helligkeit an einem Punkt sich dadurch berechnet, wieviel Licht aus allen Richtungen zu dem Punkt kommt. Man müsste also nur in alle Richtungen einen Strahl abschicken und die Helligkeit des getroffenen Objekts rausfinden. Dummerweise gibt es aber unendlich viele Winkel für die man das dann machen müsste, quasi ein Integral. Soviel Zeit hat man aber bei einer Echtzeitberechnung nicht. Also kann man z.b. nur alle 10° einen Strahl losschicken. Das sieht natürlich nicht gut aus, da man dann auf dem Bild lauter Kreissektoren mit 10° Winkel und gleicher Farbe hat. Also habe ich die Winkel immer zufällig in diesem 10° Intervall gewählt, daher das Flimmern. Schickte man genug Strahlen (>~2^8) würde das Flimmern verschwinden. Das ist aber schon zu aufwendig für Echtzeit. Ausserdem könnte man auch noch den Strahlenstart zufällig verschieben (um -0.5 bis 0.5 Pixel) und man hätte ein feines Antialiasing. Was man damit machen könnte wäre zum Beispiel einen 2D Level, der auf Tiles basiert, auszuleuchten. Das könnte man vorberechnen oder evtl. mit etwas Aufwand auch in Echtzeit machen. Aber ansonsten ist's halt wirklich nur Spielerei.Ich hoffe durch den "Technik-Check" bin ich nicht mehr ganz so überflüssig in der Grafikprogrammierung-Abteilung des Boards.
Bye, TGGC
-
Interessant, dieser Ansatz: normalerweise schickt man von jedem Pixel aus einen Strahl zu jeder Lichtquelle. Ist ein Hindernis dazwischen, ist der Pixel dunkel. So kriegt man aber natürlich nicht so schöne weiche Schatten hin... wenn Du dann den Schritt zum 3D-Raytracer machst, dann wird es mit diesem Ansatz schon schwerer, weil ja noch viel mehr Strahlen abgeschossen werden müssen...
-
Original erstellt von TomasRiker:
wenn Du dann den Schritt zum 3D-Raytracer machst, dann wird es mit diesem Ansatz schon schwerer, weil ja noch viel mehr Strahlen abgeschossen werden müssen...In 3D wäre es quasi unmöglich. Man müsste den normalen Strahl, der vom Auge aus abgeschossen wird, verfolgen und von jedem Punkt auf den Strahl in alle Richtungen wiederum Strahlen abschicken. Dann müsste man das entlang des Strahls aufsummieren und evtl. noch mit einer Dichte (in starkem Nebel) sind die näheren Punkte stärker gewichtet, bei "klarer Sicht" haben die nur wenig Einfluss, sondern erst der Punkt wo ein solides Objekt getroffen wird.
-
Das mit dem Source wird noch etwas dauern, da ich erstmal noch einen Benchmark einbauen möchte. Ohne den ist's IMHO sinnlos euch zum Optimieren drauf anzusetzen.
-
Etwas Optimierung könnte wirklich nicht schaden. Ich hab mich zwar noch nie mit Raytracing beschäftigt und hab nicht wirklich eine Vorstellung, wie aufwändig das ist, aber ich denke mit einer Radeon 9700 Pro und einem Athlon XP 2200+ und 512 Mb DDR-Ram sollte es kein Problem sein zumindest mid.bat flüssig anzuschaun... Aber sieht verdammt echt aus, muss ich sagen.
-
Deine tolle Grafikkarte bringt Dir da nichts, weil Ray-Tracing vollständig im Hauptprozessor abläuft. Die Grafikkarte wird nur gebraucht, um das errechnete Bild in Form einer Textur auf den Bildschirm zu bringen.
Ich habe aber mal was von RTRT-Hardware gelesen (RTRT: Realtime Raytracing), die mal geplant war... vielleicht könnte man sowas auch mit Pixel-Shadern machen!
-
Darf man denn überhaupt nicht angeben!
-
Sieht echt recht nett aus, wenn Du die Sourcen ein bisschen überarbeitet hast würden sie mich sehr interessieren!
(Auch weil ich das lieber unter Linux als unter Windows laufen lassen würde...)
-
Hi !
Die Demo sieht echt fett aus, gute Arbeit TGGC
TomasRiker :
vielleicht könnte man sowas auch mit Pixel-Shadern machen!
IMO geht das nicht, da du bei PS doch nur 16 Register zur Verfügung hast. Da kann man nicht viel raytracen.
-
In DirectX 9 sind es einige mehr und es werden sogar schon Loops und Ifs (Konditionale Befehle) unterstützt. Zumindest ein paar Kugeln sollten sich damit rendern lassen, das wäre mal eine interessante Aufgabe
Vor allem mit der neuen High Level Shader Language würde das sicherlich Spaß machen. Man könnte für texturierte Objekte auch die gewöhnlichen Direct3D-Texturen verwenden, mit dem Befehl tex2D kann man bestimmte Texel aus einer Textur samplen.[ Dieser Beitrag wurde am 29.12.2002 um 20:25 Uhr von TomasRiker editiert. ]
