.| Autor | Beitrag |
|---|---|
|
000 11.01.2005, 21:11 Dr.Zenz |
Nun hatte ich zum Üben mit der Sourceengine eine kleine DM-1on1-Map angefangen (Remake der Ut2k3Map Serpentine) und bin mit dem Basebrushwork auch soweit fertig. Also light_env und player_dm reingehauen, soweit mit NODRAW und Sy alles abgedichtet und testcompile gestartet. Nun ist es so, dass die Map ganz normal durchläuft, beim 2. VIS Schritt "Portal Flow" friert er dann irgendwann bei etwa 24% ein und rechnet nicht mehr weiter. Wenn man mit -v (verbose) compiled zeigt er einem erst dei einzelnen Portals an, bleibt dann mitten in der Portalberechnung stehen. Laut TaskManager ist die CPU immer noch mit 100% belastet. Es liegt weder an irgendwelchen Statics, noch an zu komplizierten Displacements. Ich hatte schonmol sowohl Statics, als auch Displacements, gelöscht. außerdem bricht er imemr an der selben Stelle ab, was sich beim Compile mit -v sehr gut sehen lässt. Hier das Compilelog: HammerBlade hatte bereits die Theorie, dass es evtl. daran liegen könnte, dass ich nicht sichtbare Faces nicht zu NODRAW gemacht habe, aber eignetlich habe ich das gröbste mit NODRAW gekillt und bin eigentlich der Überzeugung, recht sauber gemappt zu haben. -- |
|
Profil || Suche |
|
001 11.01.2005, 21:13 apoCalYpse |
laß halt mal ne Nacht durchlaufen... -- |
|
|
Profil || Suche |
|
002 11.01.2005, 21:15 brutella |
Bei mir ist das selbe, Ein irisches Sprichwort: --------------- |
|
|
Profil || Suche |
|
003 11.01.2005, 21:33 Dr.Zenz |
Hab cih schon. Es rechnet an dieser Stelle einfach nicht weiter. D.h. die Map ist vermutlich auch nicht zu komplex und deswegen compiled er auch nicht schlicht nur langsam. Er geht wirklich in eine Art Endlosschleife oso. -- |
|
|
Profil || Suche |
|
004 11.01.2005, 22:37 Dr.Zenz |
Custom Source Tools habe cih auch schon versucht, der glecihe Fehler an der gleichen stelle. Wenn cih mir mt glview das betreffende Leaf anschaue, zeigt er mir ein stinknormales Leaf an, dass er eigentlich können muss. Mittlerweile haben auch andere versucht, die Map zu compilen und sind ebenfalls an exact der gleichen Stelle gescheitert. -- |
|
|
Profil || Suche |
|
005 12.01.2005, 00:19 HammerBlade |
Das scheint ein kombiertes Problem aus Maplayout und (vielleicht) schlecht programmiertem Compilier zu sein. Ich hab mal am verbose-Output-Mode von vvis herumprogammiert und ihn erweitert. Dadurch festgestellt, dass vvis durch verschienden Portals zwischen einer handvoll Leafs im Kreis zu portalflowen scheint und nicht voran kommt. Imo ist es möglich dem Complier beizubringen solche Loops zu erkennen und mit einer Warunug abzubrechen, oder von selbst aus einem solchen Loop hinaus zufinden. Um das Problem zu lösen könntest du versuchen die Geometrie so zu verändern, dass der Loop nicht mehr auftritt. Edit: "Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon Dieser Beitrag wurde am 12.01.2005 um 01:42 von HammerBlade bearbeitet. |
|
|
Profil || Suche |
|
006 12.01.2005, 01:14 D3LeGaToR |
ich kenn dm_serpetine und vermute deshalb, dass du recht komplex das labyrinth mit bsp nachgebaut hast (wenn die trims auch noch mit bsp gemacht sind, haste ordentlich details drin). nodraw hilft da schonmal, wobei ich nicht nur das gröbste machen würde, sondern versuchen würde, möglichste alle nicht sichtbaren mit nodraw zu belegen. ich konnte bei einer kleinen tür noch 15 faces sparen, die tür kam ca. 6 mal vor, macht direkt 90 faces! die tür war so klein, dass ich mich eigentlich nicht mehr drum kümmern wollte. also guck nochmal, ob es noch stellen gibt, wo du nodraw benutzen kannst. ansonsten solltest du probieren, so viel func_detail brushes zu verwenden wie möglich. hinzu kommt genaues mappen. überprüf, ob du wirklich überall exakt bist, am besten sogar exakt am 16er grid oder noch größer. achte vorallem auch darauf, dass sich nirgendwo bsp überschneidet. schräge flächen dürftest du bei dm_serpetine kaum haben, trotzdem, pass auf, dass du keine "pseudo"-gekrümmten flächen hast, die können schon durch ganz kleine fehler entstehen, wenn du ein vertex z.B. um 1WE in die falsche richtung verschiebst. all das zusammen dürfte sich positiv auf VVis auswirken, bei mir hat sich dadurch die VVis kompilier zeit von 5h auf 10min verkürzt. Und du kannst das auch ;) -- |
|
|
Profil || Suche |
|
007 12.01.2005, 15:20 Dr.Zenz |
Ich will ja nicht verkürzen, ich will aus dieser Schleife raus. -- |
|
|
Profil || Suche |
|
008 12.01.2005, 18:03 Dr.Zenz |
So, wir (HammerBlade und Xef) haben das Problem fürs erste gelößt: es lag an einer kleinen, unbedeutenden Treppe. Sobald cih diese zu einem func_detail gemacht habe, lief der compiler ohne Probleme durch. Eine handvoll kleiner rohre die wie wild leafs erzeugen, haben ihn dagegen nicht gestört. -- |
|
|
Profil || Suche |
|
009 30.01.2005, 15:01 tommydanger |
Wie schaute den diese Treppe aus? IDF - a HL2 TC |
|
|
Profil || Suche |