Willkommen ~Gast!
Registrieren || Einloggen || Hilfe/FAQ || Staff
Probleme mit der Registrierung im Forum? Melde dich unter registerEin Bild.
Autor Beitrag
000
21.02.2001, 06:05
Legolas



Welche Werte empfehlt Ihr für die "Grundraum"grösse? Damit das spätere Level auch auf langsameren Rechnern vernünftig läuft? Oder ist es besser kleinere Räume zusammenzusetzen?

--

zum Seitenanfang zum Seitenende Profil || Suche
001
21.02.2001, 13:54
Amon



Das kann man so allgemein eigentlich nicht sagen. Auch ein großeer Raum kann mit Visblockern usw. auch auf langsameren Systemen noch gut laufen. Ich würde aber allerdings auf riesige freie Flächen verzichten, weil die dann auch noch auf einem guten System grotte laufen könnten.

Die maximale Größe kann man jedenfalls nicht so genau bestimmen. Da hilft eigentlich nur ausprobieren.

--

Ein weiterer Auszug aus "Die gesammelten Werke von Amon"

Public Enemy Modification

zum Seitenanfang zum Seitenende Profil || Suche
002
21.02.2001, 14:06
Destillator



Du musst auf die r_speeds acht geben, die sollten nicht über 1000 gehen. Die größe des Raumes macht nach meiner erfahrung nichts aus, nur dass die wahrscheinlichkeit dass viele spieler im bild sind natürlich wächst.

--

t@sk-force mod
Bombs don't kill people, explosions kill people.

zum Seitenanfang zum Seitenende Profil || Suche
003
21.02.2001, 15:09
Linga
Administrator


ein grosser raum produziert ne menge patches und dadurch r_speeds.

aber grosse halle muss nicht gleich hohe r_speeds sein. grosse flächen fressen nur wegen der be#@$%! aufteilung in patches und wenn man ne recht strukturlose texturnimmt und die hochscaled ist das problem auch weg.
in ner' grossen halle (auch eine outdoor map ist nichts weiter als eine halle)ist die visperformance das problem, da man eine menge an cells hat die getraced werden müssen und das frisst auch ordentlich rechenzeit (cell-to-cell visibility)
es gibt noch feinere methoden als die cell to cell visibility berechnung welche jedoch immer mehr rechenzeit damit verbringen die maps zu tracen. es gibt auch engines die objekt für objekt tracen doch es gibt noch keine gescheite methode das tracen rechenzeitschonender durchzuführen. selbst eine niedrigere auflösung der rays bringt da nichts und ausserdem kommt es dabei zu sichtbaren fehlern da einige objekte nicht erfasst werden. die engine tracet also nur grobe zoonen und berechnet deren gesammten inhalt (PVS). jeh nach geometrischer struktur ist die aufteilung in leafs unterschiedlich und sie kann durch plazieren von hintbrushes manipuliert werden.

--

zum Seitenanfang zum Seitenende Profil || Suche
004
22.02.2001, 04:27
Legolas



Nur mal so 'ne Frage ... wo seh ich denn die r_speeds??? :)

--

zum Seitenanfang zum Seitenende Profil || Suche
005
22.02.2001, 09:19
mani



Nicht über 1000?Gilt das auch im SP?? Ich hab in meinem Raum 6 Wände*g*+ 3 Wände + 3 durchsichtige, 1 GMan, 1 Spieler*g*, ja das wars!
Und ich hab ca. 1300 r_speeds
Ach ja, um die zusehen mussu HL mit -dev -console (einzugeben beim Run-Fenster in WC, in der obersten Zeile) starten. Dann im Spiel in die Konsole wechseln mit "^" und dann "r_speeds 1" eingeben, Konsole ausschalten mit "^".

--

zum Seitenanfang zum Seitenende Profil || Suche
006
22.02.2001, 19:31
BSE_crid



@Legolas: r_speeds-Artikel lesen! Link oben in der roten Zeile.

--

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

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

zum Seitenanfang zum Seitenende Profil || Suche