was verstehst du denn nicht? du müsstest es doch eh schon im Prinzip für deine crowd nutzen, fürs Lighting musst du bloß nochmal ein paar extra Portale ziehen. Dann sparste auch gleich diesen ganzen performancehungrigen Technobabble BS

_________________
Meine Homepage

Also ich hab' auch nicht verstanden was du eigentlich meinst. Was ist denn der Bereich A? Ein Volumen um die Lichtquelle? Wenn man das beliebig wählen kann, kann der so groß sein das man mit ziemlicher Sicherheit sagen kann das sich A mit Objekten aus B schneidet-
Wenn man A so klein wie möglich wählt hat man bei Punktlichtern nur einen Punkt in dem sich garkeine Objekte befinden.

Und ich glaube Portale nutzen auch nichts, wenn er nur einen großen Raum hat mit allen Lichtern.


Mir ist aber noch was anderes eingefallen was vllt hilft: Wenn sich zwei Lichter an fast der selben Stelle befinden, können die sich auch die Shadowmap teilen. Wenn die schattenwerfenden Objekte weit genug entfernt sind merkt man die Verschiebung kaum, höchstens wenn sich beide Lichtkegel überschneiden.

Fast richtig, jetzt schau dir noch einmal den verlinkten Artikel etwas genauer an, spiel ein bissl rum und dann dürfte der große Aha-Effekt langsam einsetzen

_________________
Meine Homepage

ich wüsste nicht was der Effekt mit Portalen zu tun hat?! Aber egal, aufjeden fall hab ich daran auch schon gedacht.. Also wenn Abstand zu den Lampen z.b. <0,5m dann gleiche Schatten... Man hat ja mal 40 Lampen auf einer truss nebeneinander.. da geht das..
Würde bei großen anlagen vielleicht 20% RAM sparen..

Warum verändert sich aber bei mir nix an der Auslastung wenn ich RGB4 anstatt RGB8 nutze für FBOs?

Machs dir doch net so kompliziert, machen wir mal ein einfaches Beispiel:
Du hast einen Raum A , in Raum A steht eine Bühne und ein Zuschauerbereich. Da deine Security echt gute Arbeit
leistet kommt auch keiner der Zuschauer auf die Bühne, also teilen wir Raum A in zwei Räume dir wir AA und AB nennen.
Da sich alle Lichtquellen in AA befinden wissen wir das die Punkte ( C1..CN ) außerhalb von AA natürlich auch nur Photonen von
AA empfangen können. Wenn wir nun Anhand der Normalen von C eine neue Kameraebene erzeugen und auf
dieser den Würfel (oder Cube auf neudeutsch) abbilden der sich aus den Grenzflächen von AA ergibt, so erhalten wir für
C die Sichtbaren Punkte (D1..DN) auf diesen Würfel. Nun verteilt man in AB eine große Anzahl an Portalen die auf eine kleine
Anzahl an Viewports (B1..BN) verweisen.Schicken wir nun für jedes sichtbare C Strahlen nach D(C) so schneiden wir dabei die
Portale und erhalten dabei die Punkte (E1..EN). In B können wir nun ein paar Zuschauer rendern und erhalten dadurch nun
eine extrem billige und vor allen große Crowd. Außerdem kann man extrem schnell für jedes sichtbare C bestimmen ob
D(C) von E(C) verdeckt wird. Und nun zählens mal 1&1 zusammen und überlegen mal was wir da jetzt nur mit Cubemaps
und Portalen gebaut haben.

_________________
Meine Homepage

Kann sein das da auf irgendeine 2er-Potenz aufgerundet wird. Also entweder wird intern pro Kanal immernoch mit min. 8Bit gerechnet oder es gibt insgesamt eine untere Grenze von z.B. 32Bit.
Ich hab das bei mir auch das RGBA und RGB gleich viel Speicher verbrauchen. Kannst ja mal GL_LUMINANCE8 versuchen.

Man kann auch eine Textur als ColorAttachment für mehrere FBOs verwenden. Da ist der Unterschied insgesamt eigentlich nicht mehr ausschlaggebend.

yunharla, wäre nett, wenn du das mal in Klartext formulieren könntest, worauf du hinaus willst, und was es bringt. Ich verfolge die Unterhaltung nur nebenbei und bin mir nicht sicher, worauf du hinaus willst. Meinst du, die Grenzfläche zwischen Bühne und Tanzfläche in Rechtecke zu teilen und von diesen aus die Cubemaps zu berechnen?

greetings

_________________
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

Sry ich nix Deutsch kommen
Dann wollen wir mal das wichtigeste übersetzen:


C ist die Menge aller Punkte auf einer Oberfläche:

Nehmen wir nun ein einzelnes C

dann können wir sagen was das einzelne C auf der Cubemap (welche ein Objekt mit Lichtern abbildet)

sowie unseren Es

so alles sieht.
wenn nun nach alle dem ein Lichtpunkt aus unserer Cubemap gesehen werden kann

dann erhält dieses einzelne C ein paar Photönchen

und da wir eine Szene haben die sich so leicht Rendern lässt machen wir das ganze nochmal und erhalten für C

und können damit C wieder etwas ausleuchten


spart man sich mindestens 9/10 an Ram im Vergleich zu jetzt und ist dabei auch noch schneller
das ganze klappt allerdings nur wenn man eine traurige Kindheit hatte:

_________________
Meine Homepage

Mit den ganzen Bildchen ist das schon wesentlich verständlicher.
Im Grunde ist das so ähnlich wie Radiosity oder das hier.

Allerdings bin ich mir noch nicht so sicher in wie fern das schneller oder speichersparender ist. Hat man da nicht haufenweise Cubemaps? Selbst wenn die nur eine niedrige Auflösung haben kommt da bei mehreren hundert einiges zusammen.
Und wenn sich ein Spotlight dreht muss man die betroffenen Cubemaps neu berechnen, oder man hat für jedes eigene Cubemap-Sets.

überlegens mal was er alles in Seiner Szene hat, denk dir am besten mal die Zuschauer auf
dem Screenshot im Nebelthread an. Die Raumaufteilung ist so einfach das man vielleicht
10-15 cubemaps bräuchte. Dazu kommen dann noch die Texturen die man so braucht sowie
ca 10-20 imposter fürs Publikum ... sollte nicht mehr als 40-80mb fressen. wobei das natürlich
jetzt nur so quer übern Daumen gepeilt ist.

_________________
Meine Homepage