Begriff: Radiosity


  • Mod

    wenn du wirklich gute resultate haben möchtest, dann mußt du das vorberechnen und auf lightmaps packen. es gibt zwar versuche die das in echtzeit durchführen, aber die sind nicht wirklich ansehnlich.

    das oberste bild auf http://www.d-engine.de/Screens/100803.jpg ist mit radiosity 😉

    natürlich geht das nur für statische objeckte, für dynamische mußt du ne art irradiance lighting implementieren.

    das API ist dabei unabhängig, das wird mit der cpu vorberechnet und kann auch mit einem softwarerenderer dargestellt werden.

    rapso->greets();



  • Ein relativ umfangreiches (englisches) Radiosity-Tutorial findest du auf:
    http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm
    Dort wird glaube ich auch erklärt, wie man sowas implementieren könnte. Wie schon gesagt wurde, ist das jedoch eine Technik, die etwas langsam ist (ich glaube nicht, dass das in Echtzeit möglich ist). Wird manchmal auch gebraucht um Lightmaps zu berechnen (bin mir nicht sicher, aber ich glaube Halflife verwendete es zur Erzeugung seiner Lightmaps).


  • Mod

    lustig schrieb:

    Ein relativ umfangreiches (englisches) Radiosity-Tutorial findest du auf:
    http://freespace.virgin.net/hugo.elias/radiosity/radiosity.htm
    Dort wird glaube ich auch erklärt, wie man sowas implementieren könnte. Wie schon gesagt wurde, ist das jedoch eine Technik, die etwas langsam ist (ich glaube nicht, dass das in Echtzeit möglich ist). Wird manchmal auch gebraucht um Lightmaps zu berechnen (bin mir nicht sicher, aber ich glaube Halflife verwendete es zur Erzeugung seiner Lightmaps).

    da bin ich mir auch nicht sicher, kann sein dass es von HL benutzt wird, aber die Quake1 engine die sie nutzen hat das nicht gehabt (bzw das spiel hat das nicht gehabt), quake2 hatte radiosity beleuchtung, in quake3 war das wieder weg, weil es lange dauert das auszurechnen und ein grafiker der gut ist, der kann das mit lichtquellen simulieren und in kürzerer zeit sein wunschergäbniss erreichen. dabei sind den grafiker lichtquellen mit negativen lichtstärken wichtig um das gut zu simulieren.

    rapso->greets();



  • Liegt die geringe Geschwindigkeit an der Komplexität der Gleichungen oder ist es ein grundsätzlicher Aspekt dieses Verfahrens, das es langsam macht?
    @lustig: Thx, ich schau mal vorbei, wenn ich Zeit habe



  • Cortex85 schrieb:

    Liegt die geringe Geschwindigkeit an der Komplexität der Gleichungen oder ist es ein grundsätzlicher Aspekt dieses Verfahrens, das es langsam macht?

    Das eine hängt doch gerade am anderen... oder wie soll das gemeint sein?! 😕



  • Es interessiert nur die Anzahl der Elemetaroperationen.

    Bye, TGGC \-/



  • Um Radiosity in Echtzeit zu erzeugen müsstest du das Bild aus der Ansicht jedes einzelnen Lightmap Texels rendern, dessen Helligkeit aufsummieren und dem Texel zuweisen. Das ganze muss mehrere Male gemacht werden, da beim ersten Pass nur die Texel beleuchtet werden, die direkt eine Lichtquelle "sehen". Beim 2. Pass werden auch die Texel heller, die die anderen beleuchteten Texel sehen. Damit es einigermaßen gut aussieht sollte man schon zwischen 4-8 Passes spendieren. Die Texel werden hier auch gerne Lumel genannt, obwohl da noch ein bißchen mehr dazu gehört. Vielleicht kannst du dir ja vorstellen, warum das bis jetzt noch nicht in Echtzeit möglich ist...



  • Und es geht doch 😉

    Bye, TGGC \-/


  • Mod

    TGGC schrieb:

    Und es geht doch 😉

    Bye, TGGC \-/

    volumetrische lichtquellen die direckt beleuchten mögen zwar nett aussehen, aber radiosity ist das nicht. schaut jedenfalls nicht so aus.

    aber es geht, http://www.realstorm.com/ , jedoch schaut es nicht wirklich überzeugend aus.

    rapso->greets();



  • Es macht aber genau das, was oben in der Definition angegeben ist: Die Farbe aus emittierten Licht aus den anderen Flächen und ihrer eigenen Leuchtkraft bestimmen.

    Bye, TGGC \-/


  • Mod

    wenn dem so ist und du die definition erfüllst:

    Radiosity ist ein globales Beleuchtungsmodell für die 3D-Computergrafik. Es beruht auf dem Energieerhaltungssatz: Alles Licht, das eine Fläche empfängt und nicht absorbiert, muss sie wieder emittieren. Außerdem kann eine Fläche auch selbstleuchtend sein.

    dann ist ja gut, auf den beispielbildern sehe ich aber nicht dass eine fläche das empfangene licht zurückemmitiert... wie schon gesagt, volume+area-lights, mehr sehe ich nicht.

    rapso->greets();



  • Bei mir wird alles Licht absorbiert. Wird sonst zu langsam, da mehrere Passes (genau genommen unendlich viele) gemacht werden müssten.

    Bye, TGGC \-/


  • Mod

    wenn alles licht absorbiert wird, wird es nicht als radiosity bezeichnet, weil sonst jede beleuchtung als radiosity bezeichnet werden könnte, natürlich steht das nicht in der definition, denn das sollte ein axiom sein.

    du müßtest nicht unendlich viele passes machen, sondern nur bis zur sättigung. es könnte zwar zur einer fluktuation kommen, aber schlussendlich alles nur ne sache des 'epsilons'.

    falls man es 'realistisch' machen möchte, müßte man von der lichtquelle energieladungen der stärke 6.626e-34Js absenden und dabei würde sich die intensität auch nicht unendlich teilen lassen, sondern atomar auf ein quantum.

    rapso->greets();



  • Wie immer. Du hast Recht. Ich meine Ruhe.

    Bye, TGGC \-/


  • Mod

    TGGC schrieb:

    Wie immer. Du hast Recht. Ich meine Ruhe.
    \-/

    nur ein Held kann ein Heldendasein beenden, gratuliere dazu!

    rapso->greets();



  • Die wahren Helden kommen doch erst morgen wieder! 😉

    Bye, TGGC \-/


Anmelden zum Antworten