Unabhängig davon, wo sich in einer mit Hammer gebauten Half-Life(1)-Map Wasser befindet, ich stehe immer vor folgendem Problem:

Die Oberfläche des Wassers wird gleichmäßig ausgeleuchtet, auch wenn beispielsweise durch Brushes zwischen ihr und der Lichtquelle eigentlich Schatten geworfen werden müssten.
Es spielt dabei offensichtlich keine Rolle, welcher Art die Lichtquelle ist (standard Light entity, Texture Light, Env. oder Spot).
Ich habe die verschiedenen Graphikmodi (D3D, OGL, Software) ausprobiert und komme auch nach dem Durchwelzen der ZHLT-Reference zu keiner Lösung.

Das hängt nun anscheinend nicht nur mit der Wasser-Textur und auch nur bedingt mit dem func_water-Entity zusammen: Es ist wohl auch func_walls und anderen mit Entities belegten Brushes nicht möglich, Schatten zu empfangen, sobald sie nur ein wenig transparent sind. Egal, welche Rendermodi ich verwende. Wie ihr merkt finde ich das alles ein bisschen verwirrend - Schaut euch am besten die Screenshots an.

Bei Interesse an meinem Problem, lässt es sich denke ich sehr gut ausprobieren, aber bestimmt hatte es jemand von euch schonmal selbst, also:

Kann die HL-Engine das?
Wenn ja, wie muss ich kompilieren lassen/bauen?
Wenn nein, hat jemand eine Idee, das Problem elegant zu umgehen?

Screenshots (Direct3D)

Brush mit !Wasser-Textur und Transparenz
Brush mit !Wasser-Textur ohne Transparenz
Brush mit Wasser-Textur, jedoch ohne "!"-Label. Transparent.
Brush mit nicht-!-Textur und ohne Transparenz - Hier sind mehr oder weniger deutlich die Schatten auf dem Teil der Oberfläche zu sehen, der vom Licht aus gesehen unter den Vorsprüngen liegt. Um die geht's mir.

Das die Art der Lichtquelle keinen Einfluss hat, liegt daran, dass die Light-Entities im Endprodukt nicht mehr vorliegen. RAD ist dafür zuständig aus den Infos der Lights eine Lightmap zu generieren.
Afaik wird alles was einen Rendermode != Normal hat auch nicht "gelightmapped", womit sich die Frage ob es die HL-Engine kann von meiner Seite her nur mit nein beantworten lässt. Aber wenn du Glück hast hat irgendwer auch andere Erkenntnisse (grad was HiDef-Projekte wie HLFX angeht).
Theoretisch ließe sich da bestimmt auch was mit Dynamic Lights deichseln aber das wird allerhöchster Wahrscheinlichkeit nach die Performance killen.

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Danke für die rasche Antwort und die Aufklärung in Sachen RAD. Werde mir das mal alles genauer anschauen.
Die Features von HLFX sehen ziemlich vielversprechend aus, die Demo läuft leider nicht. Danke aber für den Tipp. Mein russisch ist leider ziemlich beschränkt, deswegen verstehe ich nicht wirklich, was die Leute da machen.

Ich wollte eigentlich nur wissen, ob die unveränderte HL-Engine das hinbekommt, was du verneint hast.
Vielleicht kennt jemand einen anderen Weg?

Dynamic Lights hatte ich bisher als Light-Entities verstanden, bei denen zwei Zustände berechnet werden. (= 2 Lightmaps?)
Bitte um Korrektur.
Das würde mir ja auch nicht weiterhelfen, oder?

Dynamic Lights sind wie der Name schon sagt dynamisch. Sprich sie können sich in der Map bewegen, ihre Intensität/Farbe/Strahlungsrichtung ändern und was man nicht noch alles mit Licht anstellen kann und dass alles wirkt sich direkt auf die Szene aus. Die Taschenlampe in HL ist iirc nen dynamisches Licht (nicht der Kegel, den du siehst, sondern die "Aura" die andere Player sehen wenn du die Funzel aktivierst).
Wie schon gesagt sind die Light-Entitäten (light, light_spot, light_environment) nicht dynamisch. Für On/Off bzw die Custom Light-Styles werden wie du schon richtig vermutet hast mehrere Einträge in die Lightmap (für die betroffenen Bereiche) geschrieben, die dann ingame entsprechend verwendet werden.

Was die Leute von HLFX genau machen kann ich dir auch nicht mit Gewissheit sagen, dazu hab ich das Projekt nicht ausreichend verfolgt. Das war eher ein Tipp ins Blaue, dass solche Projekte da evtl ne Neuerung haben könnten, die dass von dir besagte Verhalten ermöglichen könnten.

edit: Aja das ist keineswegs die bottom line. Das ist lediglich mein Kenntnisstand, evtl gibts ne Möglichkeit.

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Alles klar. Danke!

Einstweilen hab ich das Problem kaschiert, indem ich analog zum "Dynamische Schatten faken" Tutorial den betroffenen Teil der Wasseroberfläche mit transparenten, black-texturierten func_illusionary überdeckte.
Es sähe fast zufriedenstellend aus, wäre der Rand weichgezeichnet.
Das ließe sich durch eine Fade-Textur sicher machen, nicht aber mit denen der nativen HL-WADs.
Natürlich "sieht" man durch das Wasser nur den durch das func_illusionary verdunkelten Hintergrund, das ist aber nicht besonders aufällig.

Ich werd schon noch was finden.

gab es nicht einen befehl zum runterskallieren der lightmap-abstufungen?
ansosnten hätte ich nen schönen lösungsansatz

fr?her "M.D.Freezer"

Zitat:

-scale # Set global light scaling value.

This option scales the final light values right after the direct lighting layer is added to the radiosity bounced lighting layer. Low values make the world darker, higher values make it brighter.

Die einzigen Rendermodi bei denen die Lichteinwirkung noch eine Rolle spielt sind normal und solid. Bei allen anderen wird die Lichteinwirkung nicht mit einberechnet. (sie ist aber trotzdem kompiliert; man setze ein entity, dass z.B. im rendermode texture kompiliert wurde, mit einem env_render in den normalen rendermodus, und Licht und Schatten sind wieder erkennbar)

Workaround: Wenn Transparenz ein Muss ist, Lichteinwirkung allerdings auch, dann wird man das func_water in mehrere quaderförmige func_waters unterteilen müssen, die da aneinander grenzen, wo ein scharfer Helligkeitsübergang ist, und dementsprechend das renderamount für die func_waters höher stellen, die im hellen Licht sind.

Man kann sich das Wasser ruhig so zusammenschnippseln, solange jedes func_water aus einem quaderförmigen brush ist.

Generell gilt: Je dunkler der Raum umso geringer der renderamt, wenn man texture rendermode benutzt. (Man denke an viel zu helle Glasscheiben in finsteren Räumen; sehen furchtbar aus.)

Wenn Farbwechsel auch eine Rolle spielen, wird Texturbearbeitung mit ins Spiel kommen. Ab da wird es aber ganz ehrlich zu aufwendig.

666 BPM

Das ist verdammt wichtig zu wissen und für mich jetzt auch nachvollziehbar. Vielen Dank.

Ich habe die Methode, mehrere func_water-brushes zu verwenden, ausprobiert. Das Ergabnis ist wirklich viel besser als mit func_illusionary zu überdecken. Wenn ich zusätzlich noch das ZHLT-LightFlag auf Opaque setze krieg ich durch die Schatten, die auf den Grund geworfen werden, ein befriedigendes Endprodukt.

Danke euch allen. Ich hab durch euch einiges über HLRAD gelernt.