Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Naja, wenn der Treiber in den bösen Modus schaltet, könnte man eventuell darüber nachdenken, den Mittelteil der Szene (nicht nur einen Pixel, vielleicht so 1/3 des Bildes insgesamt, nur halt die Mitte) in eine separate Textur zu kopieren, diese dann als 1x1 oder vielleicht auch größer, 4x4 oder 16x16 zu rendern und dann nur das auszuwerten. Um sozusagen die Stichproben (und eine "kostenlose" lineare Interpolation dazu) von der Grafikkarte erledigen zu lassen. Dann musst du das nurnoch zusammenzählen und mitteln. Falls glHistogram seinen Dienst verweigert .
Gruß Lord Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
@Helligkeit: Rendere doch einfach deine Szene ohne Texturen, Effekte etc. nur Objekte und Licht in eine kleine Textur (32*32 dürfte reichen). Daraus berechnest du dann einfach den Durchschnitt ist hast prinizipiell die Helligkeit, die der Spieler gerade wahrnimmt.
Registriert: Mi Mär 09, 2005 15:54 Beiträge: 372 Wohnort: München
Programmiersprache: Delphi, C#, FPC
FrenK hat geschrieben:
Wenn ich dich richtig verstanden habe erstellst du bei jedem Transformationsforgang das VBO neu.... warum speicherst du nicht eine Matrix zu den Vertex Daten und veränderst nur die??? Ich meine es würde ja schon mal verhindern das du ständig das VBO neu füllen müsstest...
Was sich mir nicht erschließt ist warum du bei Verschieben, Skalieren, Rotieren etwas an den Material VBO ändern musst ...
Das mit der Matrix mach ich eh im Programm selber - es geht mir bei den VBOs jetzt gerade nur um den Editor. Das Konzept schaut so aus, dass der Editor die finalen Vertex-Daten liefert. Daher muss ich im Editor alle Transformationen, Skalierungen und Rotationen auf jedes Vertex wirklich anwenden.
Da man im Editor relativ oft die Vertex-Positionen oder die Texturkoordinaten ändert und ich im Editor per VBO rendern würde, müsste ich den VBO im Editor immer wieder neu erstellen.
Jetzt ist es so: für jedes Material wird ein VBO erstellt. Dieser VBO ist genau auf das Material zugeschnitten. Somit hat ein Material, welches keine Texturen hat, auch keine Texturkoordinaten im VBO. Wenn ich jetzt einen Würfel habe und das Material davon ändere, müsste ich zuerst den Würfel aus dem alten VBO raushauen (also den alten VBO ohne den Würfel neu erstellen) und dann den VBO vom neuen Material neu erstellen, da dort ja dann der Würfel mit rein kommt.
Lord Horazont hat geschrieben:
Naja, wenn der Treiber in den bösen Modus schaltet, könnte man eventuell darüber nachdenken, den Mittelteil der Szene (nicht nur einen Pixel, vielleicht so 1/3 des Bildes insgesamt, nur halt die Mitte) in eine separate Textur zu kopieren, diese dann als 1x1 oder vielleicht auch größer, 4x4 oder 16x16 zu rendern und dann nur das auszuwerten. Um sozusagen die Stichproben (und eine "kostenlose" lineare Interpolation dazu) von der Grafikkarte erledigen zu lassen. Dann musst du das nurnoch zusammenzählen und mitteln. Falls glHistogram seinen Dienst verweigert .
Gruß Lord Horazon
Das Problem mit dem glHistogram hat sich sowieso erstmal erledigt, da meine Grafikkarte die Funktion nicht unterstützt und ich das somit nicht ausprobieren kann . Ich hab heute mal nen einfachen Versuch gestartet, der eigendlich schon ganz gut funtkioniert - jedoch nicht wirklich schön ist (von der Implementierung). Ich lese mir vom finalen Bild 26 Pixel aus, bilde den Durchschnitt und hab dann somit nen groben Helligkeitsüberblick. Das funktioniert eigendlich ganz ok, jedoch bin ich mit der Implementierung (wie gesagt) überhaupt nicht zufrieden. Zum auslesen benutzt ich glReadPixel - und das 26 mal .
Seth hat geschrieben:
@Helligkeit: Rendere doch einfach deine Szene ohne Texturen, Effekte etc. nur Objekte und Licht in eine kleine Textur (32*32 dürfte reichen). Daraus berechnest du dann einfach den Durchschnitt ist hast prinizipiell die Helligkeit, die der Spieler gerade wahrnimmt.
Noch nen RenderPass - bei 6 Spotlights und 2 Point-Lights hab ich jetzt schon 18 Depth-Passes für die Shadow-Maps, 1 Pre-Depth-Pass und dann noch 18 Color-Passes (wegen den Lichtern, jedoch mit glClipPlane eingeschränkt). Dann kommt noch der Post-Scene-Render-Pass ... - und jetzt das ganze noch mal 2, wenn ich das mit der weiteren Textur machen würde ... ich glaub das lass ich erstmal
Vielleicht solltest du nicht alle Lichtquellen / Schatten dynamisch machen. Lohnt sich imo nicht und verbraucht wie du bereits sagtest sehr viele Renderpasses. Wird in aktuellen games glaube ich auch nicht so gemacht (HL2 hat erst mit der Orangebox dynamische Schatten bekommen afaik und da auch nur für die Taschenlampe). Meistens hat man da wohl eher 1-2 dynamische und bis zu 4 statische Lichter aufm Schirm.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
littleDave, was hälst du denn von meinem Vorschlag? Der erspart dir den zusätzlichen Renderpass (naja, größtenteils), indem du nur den Ausschnitt kopierst und dann kleiner mit linearer Interpolation auf nem ortho-quad zeichnest. Dann kannst du mit glReadPixels oder glGetTexImage2D einfach und vermutlich schneller als mit 26 aufrufen von glReadPixels die Daten erhalten.
Gruß Lord Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Mi Mär 09, 2005 15:54 Beiträge: 372 Wohnort: München
Programmiersprache: Delphi, C#, FPC
Seth hat geschrieben:
Vielleicht solltest du nicht alle Lichtquellen / Schatten dynamisch machen. Lohnt sich imo nicht und verbraucht wie du bereits sagtest sehr viele Renderpasses. Wird in aktuellen games glaube ich auch nicht so gemacht (HL2 hat erst mit der Orangebox dynamische Schatten bekommen afaik und da auch nur für die Taschenlampe). Meistens hat man da wohl eher 1-2 dynamische und bis zu 4 statische Lichter aufm Schirm.
Für das finale Game wollt ich schon (fast) alle Lichter dynamisch machen - und im Moment geht das noch sehr gut - es läuft aufm Laptop mit 1024x600 relativ flüssig (ca. 20-24 FPS) - mit Depth-of-Field. Jedoch sind 8 Lichter schon sehr viel, es werden wahrscheinlich ca. 2-5 Lichter pro Szene zu sehen sein. Zudem sieht der der aktuelle Release-Plan so aus, dass es in 2 Jahren mal fertig sein wird. Bis dahin wird dann die Rechenpower doch etwas steigern
Lord Horazont hat geschrieben:
littleDave, was hälst du denn von meinem Vorschlag? Der erspart dir den zusätzlichen Renderpass (naja, größtenteils), indem du nur den Ausschnitt kopierst und dann kleiner mit linearer Interpolation auf nem ortho-quad zeichnest. Dann kannst du mit glReadPixels oder glGetTexImage2D einfach und vermutlich schneller als mit 26 aufrufen von glReadPixels die Daten erhalten.
Gruß Lord Horazont
Bis jetzt find ich die Idee bisher nicht schlecht - jedoch hab ich bisher noch keine Zeit gehabt, das mal auszuprobieren - morgen werd ich mal gucken . Aber vom Lesen her find ich das eine wirklich gute Idee.
Aber ich schau, dass ich das morgen mal versuche, so zu lösen. Werd mich melden, sobald ich es geschaft habe (oder sobald Probleme aufkommen ).
Ich hab noch mal eben nen Video erstellt - dabei könnt ihr sehen, wie das ganze dann ungefähr ausschauen könnte. Das Video hab ich hier mal verlinkt. Bisher ist das noch nicht so ausgereift, daher ist das noch nicht final. Jedoch find ich es schon relativ gut und (bis auf das Auslesen der Helligkeit) sehr einfach zu erstellen.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Ich finde, der Übergang ist noch zu schnell. Und wenn erst die "nachleucht"-Flecken dazukommen, ist das ganze perfekt (oder sind die etwa schon da aber noch nicht intensiv genug?)
Gruß Lord Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Do Sep 25, 2003 15:56 Beiträge: 7810 Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ja der Übergang ist etwas zu schnell.
Anstatt einer Taschenlampe kannst ja auch eine"Halte Hand vor Lichtquelle"-Aktion einbauen, mit der man das Blenden reduziert.
_________________ Blog: kevin-fleischer.de und fbaingermany.com
Registriert: Mi Mär 09, 2005 15:54 Beiträge: 372 Wohnort: München
Programmiersprache: Delphi, C#, FPC
So, ich hab mich gestern und heute hingesetzt und mal die Sache mit der Blenden-Simulation überarbeitet.
Diesmal hab ich sogar was besonderes: die erste Version, die ihr downloaden könnt. Jedoch eins vorweg: das ganze ist noch im PRE-PRE-PRE-PRE-Alpha Stadium. Daher kann ich für nichts garantieren. DIE BENUTZUNG IST AUF EIGENE GEFAHR.
Um das Programm ausführen zu können, braucht ihr mindestens eine OpenGL 2.0 Grafikkarte.
die Steuerung könnt ihr mit einem Druck auf "H" einsehen
im Ordner "config" könnt ihr in der Datei "app.config" Auflösung und Fullscreen ändern.
Im Ordner "logs" wird die Log-Datei geschrieben. Diese wird bei jedem Start geleert. Wenn ein Problem auftreten sollte, dann kann ich damit schonmal etwas anfangen
Der Download-Link befindet sich auf dieser Seite unter "Tech Demos" (ca. 5 MB).
Registriert: Fr Jan 04, 2008 21:29 Beiträge: 419 Wohnort: Lübeck
also bei mir läuft alles einwandfrei. Ist echt ne schöne Sache sich das mal live ansehen zu können. Die Steuerung ist zwar gewöhnungsbedürftig, aber ist ja bloß ne techdemo, da gehts ja "bloß" um die saftige Grafik
Registriert: Mi Mär 09, 2005 15:54 Beiträge: 372 Wohnort: München
Programmiersprache: Delphi, C#, FPC
Sellmann hat geschrieben:
also bei mir läuft alles einwandfrei.
Das ist schon mal sehr gut
Sellmann hat geschrieben:
Ist echt ne schöne Sache sich das mal live ansehen zu können. Die Steuerung ist zwar gewöhnungsbedürftig, aber ist ja bloß ne techdemo, da gehts ja "bloß" um die saftige Grafik
Ja, die Steuerung ist so ne Sache - aber wie du bereits gesagt hast - ist ja nur ne Tech Demo. Freut mich, dass die Grafik gut ankommt . Wenn man die Szene selbst immer und immer wieder sieht, fallen einem viele Sachen nicht mehr auf.
Registriert: Do Jun 28, 2007 17:58 Beiträge: 193
Programmiersprache: Pascal, C
Hi,
deine Demo läuft auch bei mir (HD 4650) einwandfrei (konstant 60 FPS) und sieht prima aus. Interessant zu wissen ist nur, wie sich deine Engine bei größeren Levels verhält.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Wow, hübsch . Gefällt mir - nur meine GF7600 ist ein wenig schwach dafür. Bei allen acht lichtern und Posteffects (btw, funktioniert das Nightvision eigentlich schon?) gehts auf 16 FPS in die knie. Wobei ich dazu sagen muss, dass ich das erst garnicht gemerkt habe. Sah einfach immernoch zu gut und zu flüssig aus. Hast du Time Based Movement?
Das einzige, was mir unschön aufgefallen ist, ist der Depth-Of-Field effekt. Der ist mir zu hart, außerdem sieht es an den Wänden so aus, als ob das ein konstant breiter streifen wäre und so. Sieht halt irgendwie komisch aus. Kann aber auch an meiner Hardware liegen. Ich hab dir mal nen Screenshot hochgeladen hier.
Weiter so!
Gruß Lord Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Nachtsichtgerät wir mit der Leertaste benutzt. Steht übrigens mit den anderen Tastenbelegungen in den Infos, wenn man "H" drückt.
Bei mir läuft es auch einwandfrei zwischen ~130fps mit nur einem und ~16fps mit allen Lichtern auf ner 7800GTX256. Der DoF-Effekt ist mir auch eher negativ aufgefallen, weil er zu stark ist. Kann aber auch daran liegen, dass die Lampe und der Fokus nicht in einem Punkt liegen, man will also mit der Taschenlampe irgendwo hinsehen, aber der Teil wird dann verwischt. Ansonsten wirklich gute Arbeit!
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Ist mir klar, dass das Nightvision auf leertaste liegt - nur passierte da bei mir abgesheen von dem hinweis unten rechts, dass das NightVision aktiv ist, rein garnichts.
Gruß Lord Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.