(überflüssige) Demo
-
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. ]
-
überflüssig ?
Also bei mir ruckelt das Teil extremDie Schatten sehen aber toll aus !
-
Etwas Optimierung könnte wirklich nicht schaden.
Naja, am Speed der aktuellen Szenen wird man nicht viel drehen können. Aber bei höheren Primitivzahlen könnten man sicher was rausholen.
Darf man denn überhaupt nicht angeben!
Dafür solltest du die Version mit dem Benchmark abwarten
Auch weil ich das lieber unter Linux als unter Windows laufen lassen würde
Bis auf WinMain und OpenGL (De)Init sollte das eigentlich problemlos gehen.
Sieht echt recht nett aus
Die Demo sieht echt fett aus
Was hattet ihr denn erwartet
P.S.: Einbau des Benchmarks ist schon angelaufen, zum Dokumentieren hab ich allerdings nicht so die Zeit.
Bye, TGGC
-
Ich habs immer gesagt. Echte Programmierer dokumentieren ihren Code nicht
-
@Gombolo
Echte Programmierer werden auch nicht fürs dokumentieren so gut bezahlt.
-
HI
Sieht richtig richtig gut aus ^^. Beeil dich mal mitm Source .) ODer erzähl mal bissl genauer, wie man das macht. Ich versuch mich schon selbst dran. Nicht um was besseres als du zu schreiben (geht auch gar nicht .) Sondern nur einfach zum lernen, weil ich noch nie mit raytracing angefangen hab :). Der Source muss wirklich nicht dokumentiert werden (solange er schön übersichtlich ist )
k
cu[ Dieser Beitrag wurde am 30.12.2002 um 01:56 Uhr von Squolly editiert. ]
-
Echte Programmierer werden auch nicht fürs dokumentieren so gut bezahlt.
Doch, eigentlich schon, Dokumentieren des Quellcodes gehört ja zum Implementieren. Nur den Vorgang bei dem diese Demo entstand würd ich nicht "programmieren" nennen.
Nicht um was besseres als du zu schreiben (geht auch gar nicht .)
LOL
ODer erzähl mal bissl genauer, wie man das macht.
Weiter oben hatte ich es ja bereits beschrieben, aber das ist ja nicht das "normale" Raytracing. Das funktioniert ungefähr so:
Du legst einen Kamerapunkt und eine Zeichenfläche (z.b. Viereck, kann aber auch gewölbt sein u.ä.) im 3D Raum fest. Dann teilst du die Zeichenfläche in entsprechend viele Pixel ein, die das Bild am Ende haben soll. Dann werden von dem Kamerapunkt zu jeden Pixel Strahlen "geschossen", entweder nur einer durch die Mitte oder auch mehrere (Supersampling?!). Dann wird jeder der Strahlen getestet ob er ein Objekt im 3D-Raum schneidet. Die Schnittpunkte mit Kugeln oder Ebenen lassen sich ja mathematisch simpel berechnen. Dann suchst du am Schnittpunkt die Normale und suchst alle Lichter die vom Schnittpunkt aus sichtbar sind. Da die Lichter i.A. nur Punktlichter sind, ist das auch simpel (schneidet die Verbindungsgerade ein anderes Objekt?). Jetzt wird aus Entfernung, Einfallswinkel und der Materialbeschaffenheit der Einfluss aller Lichter berechnet. Dabei gilt je stärker der Einfallswinkel von der Normalen abweicht, um so geringer der Einfluss des Lichts. Dann werden die Lichstärken addiert und mit der Materialfarbe multipliziert was die Farbe des Pixel bestimmt. Werden mehrere Strahlen pro Pixel gesendet, wird der Durchschnitt genommen. Die ganze Sache kann man dann noch beliebig erweitern, z.b. Oberflächen, die den Strahl reflektieren oder brechen, andere 3D-Objekte wie Zylinder, Kegel oder Hyperbolide, Lichter, die nur in bestimmte Richtungen scheinen und Materialien mit 3D-Texturen...Grundsätzlich ist so ein Teil besser geeignet für Realtime, da für jeden Pixel zunächst mal nur ein Strahl pro Pixel benötigt wird.
Vielleicht findet sich ja mal jemand, der ein Frontend zu dem Teil bastelt, mit dem man Kreise und Linien platzieren kann. Wenn man dann noch Schriftzüge mit TTF machen könnte, wäre das ein cooles Tool um sich Logos zu erstellen ;).
Bye, TGGC
-
Original erstellt von TGGC:
Bis auf WinMain und OpenGL (De)Init sollte das eigentlich problemlos gehen.Wobei Du das ja wohl auch relativ einfach auf GLUT umstellen könntest, oder?
PS: Ich hab mir die Demo noch mal auf "Ultra" angesehen, das is zwar reichlich lahm auf meinem 650er-Athlon, sieht aber echt Spitze aus - Kompliment!
