(überflüssige) Demo
-
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!
-
So jetzt hab ich den Benchmark eingebaut und die Sources hochgeladen:
http://www.fh-merseburg.de/~roesch/trash/2Dlogo_wp.jpg
Dazu habe ich nicht nur die Auflösung erhöht, sondern auch die Strahlenzahl. Ihr könnt das nachvollziehen, wenn ihr in Render.h die NrOfSectors auf 256 und ColorShift auf 8 setzt. Die Demo läuft dann aber nicht mehr ganz so flüssig ;).
Den Benchmark kann man per "-bench" starten (alles in der readme erklärt). Ich nehme mal an, das man evtl. schon mit einem anderen Compiler die Performance verbessern kann. Falls noch Fragen zum Code sind, nur her damit. Wer (nur zum Angeben) seine Benchmark-Werte zeigen will, wäre ich allerdings, dankbar wenn das nicht unbedingt in diesem Thread wäre, TIA!
Bye, TGGC
-
Wow, Dein Wallpaper sieht ja extrem gut aus!
Vielleicht könnte jemand mit besonders schnellem Rechner davon ja auch eine 1600x1200 (oder zumindestens 1280x1024) Variante rendern? *umschau*
Dass die Sourcen auch dabei sind ist ebenfalls sehr cool!
-
Also ich verzichte erstmal, diese Version hat auf meinem P200 IIRC schon über 30min gebraucht. (also los, optimiert mal! )
Bye, TGGC
-
Wenn ich ein bisschen Zeit habe konvertiere ich das zu Linux, dann kann ich meinen Rechner einfach ein paar Tage rendern lassen ohne Probleme mit Abstürzen etc. zu bekommen, vor allem kann ich da auch bei 99% CPU-Auslastung noch normal arbeiten.
-
Bist du jetzt schon da dran, oder was?
-
omg das ruckelt ja bös
Aber es sieht schon gut aus....
Leider hab ich keine Ahnung von OpenGL sonst würd ich mich damit mal gerne auseinandersetzen...
-
Von OpenGL brauchst Du da auch keine Ahnung haben, es wird ja bloß benutzt, um die Textur darzustellen. Was wir optimieren wollen, sind der Algorithmus und die Berechnungen.
-
Hey TGGC, auch von mir ein großes *respect*. Is echt n ganz schön cooles Teil, dass du den Code freigibst es echt n guter Zug, danke.
mfG D1B
-
Ich warte natürlich auf Optimierungen und 'nen Linux Port!
-
Es geht voran, habe jetzt ein VC++ Projekt erstellt und noch einige Fehler ausgemerzt. In den nächsten Tagen, wenns komplett funktioniert, werde ich es dann hochladen.
-
Original erstellt von TGGC:
Bist Du da jetzt schon dran? ... Ich warte natürlich auf Optimierungen und 'nen Linux Port!Nein, noch nicht, habe in letzter Zeit ein bisschen Stress wegen Zivildienst :(, aber ich vergess sicher nicht darauf, es interessiert mich ja auch...
[ Dieser Beitrag wurde am 15.01.2003 um 12:52 Uhr von nman editiert. ]
-
Es gibt 'ne aufgeräumte SourceCode Version mit VC++ Workspace. Ist jetzt circa doppelt so schnell. Müsste unter LINUX auch recht simpel zu kompilieren sein.
http://www.fh-merseburg.de/~roesch/trash/prev/2d_bench.htm
-
***c:\ZweiD\Renderer\CFastRender.cpp(38) : warning C4244: '=' : Konvertierung von 'double' in 'float', möglicher Datenverlust
c:\ZweiD\Renderer\CFastRender.cpp(39) : warning C4244: '=' : Konvertierung von 'double' in 'float', möglicher Datenverlust
c:\ZweiD\Renderer\CFastRender.cpp(127) : warning C4244: '=' : Konvertierung von 'double' in 'float', möglicher Datenverlust
c:\ZweiD\Renderer\CFastRender.cpp(212) : warning C4244: 'Argument' : Konvertierung von 'double' in 'float', möglicher DatenverlustVISUAL C++ 7.0
Edit by Headhunter : Friendly mode enabled
[ Dieser Beitrag wurde am 16.01.2003 um 14:36 Uhr von Headhunter editiert. ]
-
Edit by Headhunter : Friendly mode enabled
*rofl*
Ähm, TGGC, kannst Du vielleicht nächstes Mal die Dateinamen alle klein schreiben oder bei den #includes zb statt "stdafx.h" "StdAfx.h" verwenden? Linux ist nämlich case-sensitive...
Aber alle Achtung, das ist ja schon um einiges übersichtlicher als die Ursprungsversion(en)!