Ich schau mir hier ja immer jeden neuen post an und besonders die compile vorgänge interessieren mich!
Soweit ich gehört hab ist es ganz ormal einen ganzen tag zu compilen!
Aber mich würde noch interessieren wodran genau die länge der vorgänge in vis und rad abhängt! Liegt es an der größe der map a der anzahl der lights oder sonst wo dran?
Es ist zwar kein wichtiges thema aber trotzdem hätte ich gerne ein paar antworten!

Es gibt keine "normalen" compilezeiten, denn es hängt
- vom Rechner, besonders dem RAM ab
- von der Sichtweite der Map ab. Um die Sichtweite nicht zu groß werden zu lassen sollte man z.B. in einen Gang (nur mal so als beispiel) der von einem großen raum in einen anderen großen raum führt, eine Kurve reinmachen, damit man nicht vom einen Raum in den anderen schauen kann.
- von der Anzahl der Objekte einer map. Jede Fläche muss von RAD beleuchtet werden. Umso mehr Flächen desto länger dauerts.
- mehr fällt mir nicht ein

Um die compilezeiten kurz zu halten kann man externe compiler, z.B. HLCC verwenden. Der Vorteil solcher compiler ist es, dass man compilen kann, ohne dass WC im hintergrund weiterlaufen muss. Dadurch stehen dem compilen mehr Resourcen zur Verfügung, die sonst von WC verwendet würden.
Der -high Parameter (man kann ihn bei den ZHLT verwenden) kann den compilevorgang auch beschleunigen, allerdings kann man dann am PC nichts mehr machen, da fast die ganze Rechenpower fürs compilen verwendet wird.

aha ok!Also kann man die compile dauer genauso verkürzen wie die r_speeds oder? Mit visblockern und so!

Ja, wenn man sauber mappt (auf visblocking und andere tricks achten, siehe r_speeds artikel) dann ist auch ne große und detailierte map relativ schnell durch.

aber bei mir ist das problem dass ich eine relativ große fläche verwende! es ist praktisch nur ein riesiger raum wo noch ein paar kleinere räume drin sind!
und deshalb lässt es sich da mit bestimmten methoden nicht so gut handhaben!

yepp
das ist auch genau mein problem
wie soll man ne outdoor map in einem großen raum mit grßen sichtweiten spielbar bauen?
mit vis blockern natürlich usw, aber wenn das nicht so richtig umzusetzen geht???
siehe meine schiffsmap im thread von mir oder
http://www.freecfm.com/b/bone/maps/index.html

cya

-Bone_Collector-

Half-Life ist nunmal nichtfür grosse Sichtweiten konzipiert. Half-Life basiert auf der uralten Quake 1-Engine, und in diesem Spiel geht es nur um schnelle Schiessereien in engen Gängen, für diese Zwecke also perfekt.

Grosse Aussenlanfschaften sind schwieriger zu meistern, aber wenn man solche Tricks wie grossgescalte Texturen oder die Project Timeless-Mappingmethode mit den 244x244 grossen Brushes benutzt, kann man da einiges an r_speeds sparen.

"Aoccdrnig to rscheearch at an Elingsh uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoetnt tihng is taht the frist and lsat ltteer is at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae we do not raed ervey lteter by it slef but the wrod as a wlohe."

ya
das stimmt natürlich, aber es wär dann ja auch ma abwechslungsreich ne outdoor map zu zocken.
von außen sieht's schmoother aus, als immer die gleichen gänge
ist halt problematischer so
diese 244x244 brush-technik,
baut man bei der einfach alles so dasses auf diese längen u. größen aufgeht bzw die brushes die länge eines vielfaches von 244 haben?
is das nicht ein bisschen aufwendig mit der gridgröße in wc oder wad?
naja, könnt ich ma versuchn
das mit den grosgescalten texturen mach ich auch
bei meinem schiff (http://www.freecfm.com/b/bone/maps/index.html)
muss ich das allerdings noch tun
bringt hoffentlich einiges an r_speeds ein...
wenn ich sie dann ma wieder normal compilen könnte- hmrf :(

cya

-Bone_Collector-

falls du r_speeds verringern willst kannst du auch nicht sichtbare faces mit der skytextur belegen. Z.B. die Rückseite von Schaltern, die Unterseite von Türen oder was es halt für Flächen gibt die man im Spiel nicht sehen kann aber eben berechnet werden.

>baut man bei der einfach alles so dasses auf diese längen u. größen aufgeht bzw die brushes die länge eines vielfaches von 244 haben?

hast du richtig erkannt =)

ya
gut die technik bringt ja vielleicht was, wär ma denn ma sehn...
yepp, die technik mit den skytexturen auf nicht sichtbaren rückseiten von bruhes kenn ich auch
das werd ich jetzt auch immer benutzen
kann man ja auch noch auf bereits angefangen oder fertigen maps anwenden um die r_speeds n bisschen z optimieren..

cya

-Bone_Collector-