Hallo,
ich bin gerade dabei,meine CS:Source Map zu kompilieren. Bisher hab ich zum Testen die Einstellungen für Vis und Rad auf "Fast" gehabt und das Kompilieren hat ca. 15 - 20 Minuten gedauert. Hab ich nicht mehr so genau im Kopf. Aber jetzt wo ich mMn "fertig" bin hab ich die Einstellungen auf "Normal" gesetzt und das dauert mittlerweile schon seit gestern abend ca. 21:30! Ist das normal? Ich bin mir zwar sicher, dass ich, was mögliche Optimierungen angeht, furchtbar gemappt hab, aber dass das Ganze dann SO lange dauert erscheint mir trotzdem ungewöhnlich.

Die Übersetzer arbeiten bei dir aus pädagogischen Gründen extra langsam. Mappe sauberer. Der einzige, der lange brauchen darf ist Rad auf full oder auch auf normal, wenn die Map eine sehr große Oberfläche hat (so wie das Wasser bei de_port).

Zitat:

Ungewöhnlich? Ja, aber so steht es geschrieben.

... und der große böse Wolf bootete und bootete und bootete ...
Optimiere deine Map, sieh dir alle Compile-Errors an, frage den Hersteller und beschwer dich über nichts!
http://www.mcscore.de.vu
13+3+7=23, 133/7+23=42

Hmmm.
1. Idee:
Brich den Compile ab (Task-Manager->Prozesse beenden) (und dabei feststellen, ob VIS noch läuft. Wenn ja, hast du deine Map ECHT komplex gebaut. Wenn es RAD ist, nicht GANZ so schlimm, aber bei der Dauer solltest du vllt. mal nachdenken, ein paar Lichter weniger zu machen, die Lightmaps zu verkleinern etc.)
2. Idee:
Compile mal nur mit VIS und das auf -fast. Dann steht am Ende des VIS-Eintrags im Log eine Portalzahl. Bitte mal mitteilen (wenn >100.000, dann solltest du dir ERNSTE Sorgen machen).
3. Idee:
Compile mal nur mit BSP und dem Parameter -glview (Expert-Compile). Dann die entstandene .gl-File mit dem Programm GlView (im Ordner sourcesdk/bin) öffnen (ist ein Kommandozeilenprogramm, also über Eingabeaufforderung starten, am besten mit dem Parameter -portal (macht jedes VisLeaf auch im 3d-Raum sichtbar). Dann siehst du schon mal grob, wo nachzubessern ist.

€:

Zitat:

McScore sagte bereits:
Die Übersetzer arbeiten bei dir aus pädagogischen Gründen extra langsam.

-> Heißt im Klartext:

Optimiere deine Map! Benutze Func_Detail exzessiv. Besonders Brushes mit schrägen Kanten und winzige Details sind dafür prädestiniert.

Es gibt 2 Möglichkeiten, eine Kristallkugel zu benutzen:
a) um damit Spekulationen über ein Problem eines Users zu machen und
b) um sie einem besonders unkooperativen User über den Schädel zu ziehen.
- bloggt jetzt auch selbst auf Sclavia.de

Danke für die Tips!
Ich hab den Compile-Prozess erstmal abgebrochen, da er beim Vis schon Stunden gebraucht hat. Ein folgender Compile mit nur VIS auf "Fast" brachte dann folgendes Ergebnis:
Quellcode:** Executing...
** Command: "c:\programme\steam\steamapps\equivocator\sourcesdk\bin\vbsp.exe"
** Parameters: -game "c:\programme\steam\steamapps\equivocator\counter-strike source\cstrike" "C:\Programme\Steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift"

Valve Software - vbsp.exe (Dec 11 2006)
2 threads
materialPath: c:\programme\steam\steamapps\equivocator\counter-strike source\cstrike\materials
Loading C:\Programme\Steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift.vmf
Can't find surfaceprop stone for material DE_TIDES/TIDES_CONCRETEFLOOR, using default
fixing up env_cubemap materials on brush sides...
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (3)
ProcessBlock_Thread: 0...1...2...3...4...5...6...7...8...9...10 (3)
Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (0)
Find Visible Detail Sides...
Merged 502 detail faces...done (0)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (3)
writing C:\Programme\Steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift.prt...done (0)
Creating default cubemaps for env_cubemap using skybox materials:
skybox/sky_day01_09*.vmt
Run buildcubemaps in the engine to get the correct cube maps.

No such variable "$hdrbasetexture" for material "skybox/sky_day01_09rt"
Can't load skybox file skybox/sky_day01_09 to build the default cubemap!
Finding displacement neighbors...
Found a displacement edge abutting multiple other edges.
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (1) (1377566 bytes)
Placing detail props : 0...1...2...3...4...5...6...7...8...9...10
Compacting texture/material tables...
Reduced 6334 texinfos to 3187
Reduced 461 texdatas to 381 (23175 bytes to 19098)
Writing C:\Programme\Steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift.bsp
45 seconds elapsed

** Executing...
** Command: "c:\programme\steam\steamapps\equivocator\sourcesdk\bin\vvis.exe"
** Parameters: -game "c:\programme\steam\steamapps\equivocator\counter-strike source\cstrike" -fast "C:\Programme\Steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift"

Valve Software - vvis.exe (May 22 2006)
fastvis = true
2 threads
reading c:\programme\steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift.bsp
reading c:\programme\steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift.prt
3642 portalclusters
11456 numportals
BasePortalVis:       0...1...2...3...4...5...6...7...8...9...10 (31)
Optimized: 832381 visible clusters (0.00%)
Total clusters visible: 8087095
Average clusters visible: 2220
Building PAS...
Average clusters audible: 3558
visdatasize:2998882  compressed from 3321504
writing c:\programme\steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift.bsp
39 seconds elapsed

** Executing...
** Command: Copy File
** Parameters: "C:\Programme\Steam\steamapps\equivocator\sourcesdk_content\cstrike\mapsrc\cs_nightshift.bsp" "c:\programme\steam\steamapps\equivocator\counter-strike source\cstrike\maps\cs_nightshift.bsp"

Was sagt mir das jetzt?

EDIT:
Es befinden sich laut Hammer 1310 Point Entities in der Map, wobei die verschiedenen Licht-Entities dabei nen ziemlich geringen Anteil ausmachen, aber bis zum Rad bin ich ja nicht gekommen bisher...

EDIT 2:
Werden NoDraw-Brushes eigentlich bei den Vis-Leafs berücksichtigt? D. h. wenn man in einen eckigen Raum einen Brush mit Nodraw-Textur einfügt, wird der Raum dann in mehrere Vis-Leafs zerteilt? Und sollte man solche Brushes dann zu func_details machen? Oder was macht man mit denen am besten?

1310 Point Entities..w00t ?
Copy & Paste ftw.

Music Artist / 2D Artist / Mapper

Also, die Pointentitiezahl ist normal. Standart-Singleplayermaps haben über 2k Pointentities, der Löwenanteil liegt bei den Props.

Was mir an diesem Log die Augen aus dem Kopf schlägt, ist dagegen folgende Zeile:
Quellcode:Total clusters visible: 8087095 8 MILLIONEN VISLEAFS!!!!einhundertelf!!111
Hmmm... Dank VIS-Algorithmus sind das 8.000.000! (<-Fakultät) Berechnungen (
sind 1x2x3x4...x8.000.000)
Wenn man bedenkt, wie lange du auf Papier dafür brauchen würdest, ists kein Wunder, das dein Rechenknecht schlapp macht. Ich empfehle meine Methode 2):

Zitat:

3. Idee:
Compile mal nur mit BSP und dem Parameter -glview (Expert-Compile). Dann die entstandene .gl-File mit dem Programm GlView (im Ordner sourcesdk/bin) öffnen (ist ein Kommandozeilenprogramm, also über Eingabeaufforderung starten, am besten mit dem Parameter -portal (macht jedes VisLeaf auch im 3d-Raum sichtbar). Dann siehst du schon mal grob, wo nachzubessern ist.

"Found a displacement edge abutting multiple other edges." ist auch schon nicht gesund. Irgendwie hast du es geschafft, ein Displacement so zu verzerren, dass es sich selbst überschneidet.

... und der große böse Wolf bootete und bootete und bootete ...
Optimiere deine Map, sieh dir alle Compile-Errors an, frage den Hersteller und beschwer dich über nichts!
http://www.mcscore.de.vu
13+3+7=23, 133/7+23=42

btw... Irgendwas mit Semitransparenten Texturen drauf muss auch immer Func_Detail sein.

Es gibt 2 Möglichkeiten, eine Kristallkugel zu benutzen:
a) um damit Spekulationen über ein Problem eines Users zu machen und
b) um sie einem besonders unkooperativen User über den Schädel zu ziehen.
- bloggt jetzt auch selbst auf Sclavia.de

Ok, wie Agamenon schon festgestellt hat (in meinem Thread im Präsentationsforum), muss ich wohl noch so einiges lernen, was Mapping angeht *g*. Da mir leider die Zeit fehlt (Wintersemester geht bald los, tja...:( ), die Map mit den vorgeschlagenen Methoden zu optimieren, oder darauf zu warten, dass mein Rechner (8*10^6) ! Berechnungen zu Ende bringt :) werd ichs wohl dabei belassen, die Map auf den "Fast" Einstellungen zu kompilieren und es beim nächsten Versuch besser zu machen (hoffentlich). Trotzdem danke für die Tips, ich werd auf jeden Fall dran denken, wenn ich die Zeit find, einen zweiten Versuch zu starten!

Zu Aga:
Jop. Stimmt zwar, aber witzigerweise machts nicht mal Valve selbst...