Weis nich obs hier rein gehört

Also ich bin in nem Entwiklerteam und ich hab ne Entity liste erstell die ich brauche. Unter anderem war ein entity dabei das licht ausstrahlen sollte, aber nich punktuell sondern en ganzer brush leuchtet (der brush muss aber wirklich leuchten und nicht eifach heller dargestellt werden).

Jetzt ist meine Frage:
Ist es möglich sowas zu erstellen??? (einer aus dem Team war der meinung das man mit D3D nur punktuelle machen kann, wollt aber nochmal sicher gehen)

mir fällt dazu nur das stichwort: Textlights ein....
... denke aber nicht, dass das das ist wonach du suchst.
[edith]
bin aber auch kein Profi... und ob Graphik Design angemessen ist...
eher, andere Probleme, (oder, wenn es um Coding geht) das allgemeine Coding Board.
[/edith]

Resetting politics:
http://www.onlinepartei.eu

das geht entweder über texlights, die dir bekannt sein sollten, oder gar nicht.

Downward future!
I descend...

ja, ich denke aber die frage war eher wie er die texlights machen soll =)

ich weiss es leider nicht und ausserdem gehört das eh ins coding board ->

Move In!

Was bitteschön will er denn da coden? Er nimmt ein Grafikprogramm, erstellt sich die Textur, startet Wally, packt die Textur in eine WAD rein, gibt bei WC/Hammer an, das diese WAD benutzt werden soll und pappt dieser erstmal überall drauf, wo sie hin soll.

Danach öffnet er den Notepad (oder TBLux ect.), lädt die lights.rad aus dem Compilerverzeichnis ein, gibt den Namen der Textur an und definiert die RGBB Werte (RGB Brightness). Und beim nächsten Compilen sollten seine Brushs leuchten wie der Burli (hrhrhr).

So ist die Vorgehensweise in HL. Das Prinzip kann kopiert werden, da ich persönlich viele Def-Files besser finde als kryptische Prereferences in irgendwelchen Editoren. Nun, da er ja nicht für HL was macht, sondern ein eigenes Entity für eine eigene Engine braucht, sollten wir erstmal das Phänomen der Texlights genauer untersuchen:

Ein Texlights emittiert lineares Licht pro Texturzelle. Eine Texturzelle ist in HL z.B. exakt 16 * 16 Units groß. Da das emittierende Licht weder umgelenkt noch gebrochen wird, entsteht das räumliche Umgebungslicht primär vielmehr durch Reflektion an Worldbrushs. Die Standard-Brushentities lassen das Licht durch (außer man sagt ZHLT, daß das Brushentity das Licht blocken soll, Thema is ja bekannt). Ich würde mal behaupten, daß der Normalvektor eines getexlighteten Faces für die Linearität des Lichts zuständig ist. Eine bessere Lösung fällt mir mappingtechnisch und mathematisch nicht ein. Anhand des Normalvektors weiß der RAD-Compiler also, in welche Richtung das Face sein Licht emittieren soll. Technisch würde ich ein Vektorenarray aufbauen, in dem alle Normalvektoren getexlighteter Faces vorhanden sind, wobei man durch partielle Umgebungsberechnung aneinandergrenzende Texturzellen zusammenfassen könnte, so daß eine geschlossene Oberfläche entsteht pro Face. Der Compiler müsste daher nur das Array abarbeiten und die Lichtberechnung vom Face ausgehend beginnen.

Interessant wäre in dieser Betrachtungsweise, daß man - nachdem der Normalvektor eines Faces bekannt geworden ist - Varianten wie Streuungswinkel usw. implementieren könnte. Das Ergebnis für die Lichtberechnung wäre ein rechteckiger Pyramidenstump als "Lichtpoly" (quasi wie der Schein einer Lampe im Nebel), dessen Basis exakt der Oberfläche des getexlighteten Faces entspricht und der entsprechend des Streuungswinkels um soundsoviel Grad in die vier Seitenrichtung auseinandergeht. Reflektionen an Worldbrushes würde ich demnach als Eingangswinkel -> Ausgangswinkel umrechnen und das Lichtpoly in einer abgeschwächten (Licht)Stärke anhand des neuen Richtungsvektors zurückschicken, bis es wieder auf einen Worldbrush trifft und das Spiel von vorne losgeht. Das entspricht meiner Ansicht nach dem ungefähren Verhalten des -bounce Parameters bei RAD. Allerdings glaube ich kaum, daß reflektiertes Licht derart in RAD berechnet wird, da jeder Bounce meistens < 1 Sekunden dauert. Ich gehe mal davon aus, daß jeder Bounce nur eine allgemeine Helligkeitszunahme auf alle bisher berechneten Lichtfelder darstellt und keine exakte Berechnung. Dann würde RAD wahrscheinlich bei -bounce 7 siebenmal solange dauern als sonst :)

Also: Wenn man den Normalvektor eines Faces kennt, von dem Licht emittert werden soll, dann kennt man wenigstens die Richtung des Lichts. Basierend auf dieser Information kann man dann beginnen die Lichtemittierung durchzuführen. Entweder als Lichtpoly oder als punktuelle Texturennachbearbeitung (Pixelumgebungen der vom Licht erreichten Texturen werden farblich bzw. helligkeitsabhängig bearbeitet). Aber wie man sich auch entscheidet, der Umfang des Lichtkegels muß vorher definiert werden (siehe light_spot). Sei es nun als genereller Fixparameter innerhalb des Compilers oder als definierbarer Wert.

Die Texlight selber sollte mit einem 3/4 Helligkeitswert der Lichtdaten selber erhellt werden. Eine 1:1 Erhellung ist manchmal unschön, wenn das Face subjektiv heller "leuchtet" als die Umgebung.

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)

Ähm Textlights würden rein theoretisch funktionieren aber:
Das Licht wird in Echtzeit berechnet und von daher funktioniert es damit nicht (meines Wissens).

Thx für die Antworten

Realtime Radiosity: www.google.de

georg-wicherski@pixel-house.net | http://www.pixel-house.net/ - Coding Resource| http://www.google.de/