Der "kleine" r_speeds Artikel

Auf dem letzten Swordwarriors Treffen hatte ich mit Dr.Zenz und Dagobert eine kleine Meinungsverschiedenheit über das Entstehen von r_speeds (Anmerkung von Dr.Zenz: und ich hatte Recht!). Ich möchte das ganze hier mal zusammenfassen und die Ergebnisse erklären. Dazu gibts dann noch ein paar kleine Tipps und das ist dann der Inhalt dieses Artikels.

Vorweg: An die, die schon Ahnung von r_speeds und deren Berechnung haben… Erwartet nicht zu tiefgreifendes von diesem kleinen Artikel, er soll in erster Linie denen dienen, die noch neu sind und die den kompletten r_speeds-Artikel noch nicht gelesen bzw. verstanden haben. Es soll einen kleinen Einstieg geben.

Auswirkung des Texturscalings auf die r_speeds

Es ist ja allgemein bekannt, dass Flächen in Half-Life von den Compilern in 224² große Einzelflächen zwecks Berechnung zerschnitten werden und dann in der Engine natürlich auch dementsprechend gerendert werden. Wir waren uns jetzt nicht ganz einig darüber, ob diese 224² Einheiten sich auf die weltlichen Einheiten „units“ beziehen, oder ob das mit der Textur zusammenhängt. Dazu also jetzt zuerst:

Ich hab mich mal schnell drangesetzt und hab im VHE 3 gleich große Brushes gebaut: alle 256³ units, absichtlich so gewählt um brushes zu bekommen die größer sind als die bekannte Zahl 224.

Der erste Brush mit einem Texturscaling von 1 in x- und y-Richtung. In alle Richtungen (xyz) jeweils 256 weltliche Einheiten groß, man sieht dass die Textur genau 4mal auf eine Fläche passt (also die Maße 128² hat, was aber hier jetzt nur zwecks Veranschaulichung eine Rolle spielt):

jeanrspeeds01.jpg

Der zweite Brush hat ein Texturscaling von 0.25 in x- und y- Richtung. In alle Richtungen (xyz) jeweils 256 weltliche Einheiten groß, genau wie der erste. Die Textur passt hier jetzt 8×8, also 64mal drauf. Dazu später weiter:

jeanrspeeds02.jpg

Der dritte Brush hat ein Texturscaling von 4 in x- und y- Richtung. In alle Richtungen (xyz) jeweils 256 weltliche Einheiten groß, genau wie der erste und zweite. Die Textur passt hier jetzt 1/4 mal drauf. Zwecks Anschaulichkeit hab ich sie etwas verschoben, was sich aber auf die Ergebnisse in keiner Weise auswirkt:

jeanrspeeds03.jpg

Glaubt man jetzt also einigen Gerüchten, sollten die Brushes dieselben r_speeds haben. Wir haben gemerkt: haben sie nicht (wozu auch sonst der Artikel. ;)

Folglich sind die 224² Einheiten, nach denen im bsp immer wieder ein Schnitt auf der Fläche erfolgt keineswegs weltliche Einheiten, sondern sie orientieren sich an den Texturpixeln. Die Ergebnisse zeigen.

Brush 1, Tex-Scale: 1, Schnitte nach 224 Texturunits = 224 Weltunits (da Scaling = 1 ist). Dieser Brush wäre in der form zwar von der Texturausrichtung her schön anzuschauen aber r_speeds-mäßig sehr ungünstig:

jeanrspeeds04.jpg

Auch wenn beim zweiten Brush die Schnitte nicht soo gut zu erkennen sind: nach 224 Texturunits wird geschnitten, die r_speeds steigen um ein vielfaches und dazu sieht es auchnoch dumm aus:

jeanrspeeds05.jpg

Und nun der dritte Brush: Huch! Wo ist denn da geschnitten worden? Tja, das zeigt der Versuch sehr schön: garnicht. Weil keine 244 Texturunits auf die Fläche passten, ist die Fläche jetzt als 1 Stück zu berechnen / rendern. Sieht zwar nicht sonderlich schön aus, erzielt aber eine durchaus positive Wirkung:

jeanrspeeds06.jpg

Wer jetzt allerdings sagt: ich bau mir jetzt nurnoch Texturen bis 32 units Größe in jede Richtung und scale die dann dass die passen hat hier was nicht richtig verstanden. Ich will hiermit eigentlich zeigen, dass die Variante, Texturen auf eher unwichtigen Flächen größer zu scalen durchaus von Vorteil ist, da sie die Speeds senkt. Wer sich jetzt einige relativ neue Maps (auch offizielle, vie z.B. von CS:CZ) mit dem command gl_wireframe ansieht wird schnell merken woher die r_speeds von bis zu 1000 w_polies kommen, wo vorher nur 600 waren. Richtig: Man hat höher aufgelöste Texturen verwendet und sie auf die Hälfte heruntergescaled um ein schöneres Aussehen der Map zu erzielen. Aber: Fehlanzeige. Wer kann sich schon bei extrem niedrigen fps eine Map ordentlich ansehen?

Hier gilt es jetzt ein gutes Mittelmaß zwischen Texturgröße und Scaling in Abhängigkeit von der Verwendung zu finden. Zweckentfremdung von Texturen, also Texturen zu nutzen die für anderes gedacht waren, wie z.B. das starke Herunterscalen einer Textur um sie auf ein offenes Rohrende anzupassen sind äußerst schlecht. Lieber die Textur in z.B. Wally kleinerscalen und neu in die wad reinpacken um sie dann bei einem anderen Scaling zu nutzen.

Aufgeräumt mit einer uralten Legende

Ein großer Block (wieder 256³ units) ist zusammengesetzt aus vielen kleinen Stäben:

jeanrspeeds07.jpg

Wie sähen hier wohl die r_speeds-Erwartungen aus? Klar, extrem hoch, quasi „Polywasting“. Die Texturen sind aber auf allen Brushes auf all ihren Seiten gleich ausgerichtet und gescaled. Compile ich das ganze jetzt und sehe mir das mal ingame mit dem Command gl_wireframe an, sieht man folgendes:

jeanrspeeds08.jpg

Es wird wider allen Erwartungen genauso geschnitten wie wenn man alles aus einem Brush baut: nach 244 Texturunits. Selbstverständlich nur auf den Flächen, die absolut eben sind und genau die gleiche Texturausrichtung haben. Würde ich jetzt bei einer Fläche in der Mitte die Textur auch nur ein ganz kleines bisschen verschieben, würde sie die Fläche um sich herum entlang ihrer Kanten in weitere Teile teilen, was dann folglich zu höheren Speeds führen würde.

jeanrspeeds09.jpg

Diese Konstruktion führt wie oben bereits genannt zu folgendem Ergebnis:

jeanrspeeds10.jpg

Dass ein Zylinder eine Fläche auf der er steht entlang seiner Kanten schneidet rührt also nur daher, dass unter ihm ja keine Fläche ist die berechnet wird, sondern dass die Fläche „auf der er steht“ nur genau bis zu den Berührungskanten geht. Daher kommt auch, dass die Fläche eben nicht zerschnitten wird, wenn der Zylinder (oder allg. das Objekt) ein brushbased Entity ist: Es befindet sich unter dem Objekt eine Fläche, die in großen Stücken berechnet werden kann.

Ausserdem ist auffällig, dass bei vielen brushes, die eine Fläche ergeben mit derselben Texturaufrichtung darauf, die Compilezeit für die Lichtberechnung (rad) nicht steigt.

Ich hoffe, dass dieser Artikel in Zukunft einigen von Euch beim Leveldesign helfen wird.

Danke an Dr.Zenz und Dagobert.

Die Verwendung aller Dokumente einschließlich der Abbildungen ausschließlich zu nichtkommerziellen Zwecken. Verbreitung des Dokuments auf Speichermedien, (insbesondere auf CD-ROMs als Beilage zu Zeitschriften und Magazinen oder sog. "Mission-Packs" etc.) ist untersagt.
 
half-life/tutorials/der_kleine_r_speeds_artikel.txt · Zuletzt geändert: 2004/12/18 22:33 von Dr.Zenz