Hi!
Beim Lesen der "Problems"-Datei der aktuellen ZHLT-Version (1.60) bin ich auf die HINT und SKIP Texturen gestoßen. Zu HINT waren Tutorial-Links angegeben, aber wozu sind SKIP-Texturen gut? Zu den HINT-Texturen: Ist der r_drawflat-Modus das Äquivalent zu gl_showtris 1 bzw. gibt es in HL ein Äquivalent? Wird in HL überhaupt ebenfalls alles in Triangles aufgeteilt? Und was ist mit "don't run CSG" gemeint, ich meine, ohne das geht es doch nicht, oder?

Schon mal vielen Dank im Voraus!

CU
Siyphos

....ich kann nur zu gl_showtris etwas sicheres sagen: leider leider gibt es dieses Kommando nur in Quake 1/2 und nicht in HL. Es entspricht auch nicht dem r_drawflat-Kommando. Mit gl_showtris kann man in Quake 1/2 die Dreiecke ("Polygone") sichtbar machen, in die die Flächen aufgeteilt werden, die man mit r_drawflat sieht. Ansonsten funktioniert HL genauso (Aufteilung in Dreiecke), die Engine basiert ja auf der Q1-Engine.
Mit der SKIP-Textur kann man -glaube ich- Bauteile einer Map "markieren", so daß sie beim Kompilieren nicht berücksichtigt werden, an ihnen also z.B. keine eigenen Leafs ausgerichtet werden.....ist aber nur eine vage Vermutung...
Mit "don't run CSG" kann ich momentan überhaupt nichts anfangen, hab noch nichts drüber rausfinden können..

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

Ich bin's nochmal!
Zu Anfang erstmal vielen Dank! Allerdings habe ich noch ein paar Fragen...
Wenn ich in einem HL-Level r_drawflat anwende, sehe ich meist rechteckige Teilflächen - sind dies dann in Vierecke zusammengefaßte Dreiecke und müßten die dann nicht sichtbar gemacht werden können? Zu den Tuts: In den HINT-Tutorials stand in etwa folgendes: Wenn ich z.B. in einem Eckgang vor der Ecke stehe, so daß ich noch nicht die andere abknickende Wand und den Raum dahinter sehen kann, kann es passieren, daß die engine dies bereits tut, weil ich mich auf demselben Dreieck befinde, das auch die Punkte abdeckt, von denen aus ich um die Ecke blicken könnte. Wenn ich nun an die Sichtgrenze, d.h. an die Stelle, wo ich noch nichts sehen kann, eine Art HINT-Wand baue, wird das Dreieck geteilt und die Berechnung verläuft so, daß ich an besagter stelle noc nichts sehe und auch die engine noch nicht den anderen Raum berechnet. Solche Stellen mit Drawflat zu erkennen, stelle ich mir jedoch etwas schwierig vor, allerdings habe ich einen Fall, in dem es daran liegen könnte, daß die Polys nicht runtergehen: eine Donuttür, deren Mittelwand abgeflachte Enden hat, so daß sie nicht so störend wirkt; obwohl sie weit genug über die Breite der Türen hinausgeht, sinken die Polys nicht richtig und bei r_draworder ist das Ergebnis "unsauberer", als bei einer Donuttür im selben Level dergleiche Bauart. Allerdings erkenne ich nur sauber getrennte Vierecke. Könnte das Problem nicht durch HINTs gelöst werden? Also müßte ich doch einen HINTwall setzen können und in HL funktioniert das dann wie in Quake1/2? Übrigens wäre das doch dann eine effektive r_speeds-Reduzierung, die in Deinen übersetzten Artikel noch reingepackt werden könnte, oder? Andererseits finde ich solche Stellen schwer erkennbar und in den englischen Tuts stand, daß es schlimmer als das mit HINTs zu behebende Problem ist, wenn man dort HINTs setzt, wo sie nicht gebraucht werden, weil dann ja zuviele Dreiecke gesplittet werden. Zu dem "don't run CSG": Beim Überfliegen habe ich mich vertan, sorry. Der Autor bezog sich darauf, was passiert, wenn man aus Versehen den HINTwall in den void ragen läßt, weil man ihn durch die Begrenzungsmauern gezogen hat: "As shown in the diagram, the hint brush ... completely slices through the section of hallway. DO NOT USE CSG!!! You will create a leak if you do. The hint brush is not rendered, and is only used by VIS (more on that in part 4)."
So, das war's, vielleicht hast Du ja noch ein paar Tips zum Umgang mit HINTs - wäre sicher hilfreich!

CU

Sisyphos

Die Farbflächen, die man mit r_drawflat sieht, sind in der Tat die Flächen, die in Dreiecke aufgeteilt sind. Diese Dreiecke kann man aber in HL leider NICHT sichtbar machen :(:(:(. Wenn ich den Sachverhalt aber richtig verstanden habe, so richtet sich die HL-Engine im Gegensatz zur Quake-Engine beim vising sowieso nicht an den Dreiecken, sondern an den Leafs, die qbsp berechnet (siehe r_speeds-Artikel) und die werden ja anhand der bestehenden Brushes bzw. deren Seitenflächen erstellt. Vielleicht wurde ja auch deshalb auf das gl_showtris-Kommando in HL verzichtet(?).
Was Dein Problem mit der Donuttür angeht, so hab' ich die Stelle mit den "abgeflachten Enden" noch nicht so richtig kapiert (vielleicht nochmal etwas genauer beschreiben, oder ein Bild posten/mailen). Ansonsten kannst Du die Problemstelle(n) auch herausfinden, indem Du mit r_draworder 1 (evtl. zusätzlich r_drawflat 1) an der Tür herumläufst und genau darauf achtest, ab welcher Stelle die Engine anfängt, die dahinterliegenden Räume zu rendern.
ImaTarget hat kürzlich im Beiträge-Forum einen Link zu einem sehr anschaulichen Post über Hint-Brushes gepostet. Leider sind die (absolut unverzichtbaren) Bilder zu diesem Post momentan nicht mehr online, so daß der Post relativ nutzlos ist. Ich habe ihn mir aber inklusive Bilder auf die Festplatte gezogen. Falls Du willst, kann ich dir den Kram mal mailen (sind aber ca. 2,5 MB!).
Was mein Wissen über Hint-Brushes angeht, kann ich nur sagen, daß ich auch nur sehr wenig Erfahrung damit habe. Aber ich glaube, wenn man mal die Zusammenhäge kapiert hat, dann ist die Sache nur noch halb so wild, wobei man von Fall zu Fall entscheiden oder auch oft einfach >ausprobieren< muß, ob ein Hint die r_speeds positiv oder negativ beeinflusst.

Was meinen r_speeds-Artikel angeht, so muß ich doch betonen, daß ich den nicht übersetzt, sondern selbst geschrieben habe =)=)....>schulterklopf<

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

Erst mal vielen Dank crid und sorry wegen der "Übersetzung" - ich hatte einen ähnlichen, englischen r_speeds-Artikel im Kopf und unverschämt, wie ich nun mal bin ;)...
Zu der abgeflachten Donuttür: die Mittelwand ist ca. 50 Grids dick und 256 Grids breit, so daß die betroffenen Türen mehr als abgedeckt werden. 32 Grids von jedem Rand entfernt (von oben betrachtet) sind Schnitte angebracht, so daß nur ein 16 Grid breiter Teil bleibt, der noch wie eine Standardwand aussieht. Der solid ist also ein Achteck. (Stell es dir wie eine normale Wand vor, an deren beiden kurzen Enden - von oben betrachtet- je ein Trapez klebt); in r_draworder wird die Wand durchsichtig an den Stellen, wo die Trapeze kleben; die Donuttür schließt sich an eine Haupthalle an und an einen Gang, an den Räume angrenzen; komme ich aus Gangrichtung und steh direkt vor der Mauer, sind die wpolys bei 500 oder so, umgekehrt bei 70 - seltsam, oder? Ohne Wand sind sie in beiden Fällen bei 500-700. Zu den HINTS: Ich glaube, ich komme vielleicht später mal auf das Angebot zurück, im Moment lerne ich lieber mal, mein Level noch mit Felsen und Außenwelt auszustatten. Wenn es grob fertig ist, kann ich dann immer noch anfangen, herumzuexperimentieren im Kampf gegen die wpolys. - Ich hasse es nur, Sondertexturnamen zu kennen, ohne zu wissen, wozu sie gut sind.

CU
Sisyphos

...ich würde zuerst mal versuchen, an der Visblocker-Wand in der Tür die abgeflachten Ecken wegzulassen. Evtl. setzen an diesen schrägen Teilen leafs an, die sich irgendwie ungünstig auf die Sichtweite der Engine auswirken.

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/