hi.

habe ne ziemlich große map (800 square feet), mein problem:

wenn ich die 4 großen bodenplatten als world-solid habe, kompiliert er nicht richtig, heißt: portal flow 1...2.... usw. (compilezeit ca. 4 std.).

wenn ich sie als func_detail mache compiled er richtig (ohne portal flow ca. 3 minuten), ich habe aber leaks, weil sie ja funcs sind und an den seiten(abstand zur skybox freie flächen sind) somit dachte ich mir, ich mache einen weiteren boden als 3dskybox und jetzt compiled er wieder nicht richtig, ich nehme an weil es ihm nun wieder too much ist.

was kann ich tun?

4 Stunden Kompilezeit sind durchaus normal...
Das hängt exponentiell vom Volumen der Map (und einigen anderen Dingen) ab.

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

ich habe hier schon oft solche dinge gelesen, aber ich kann mir beim besten willen nicht vorstellen, dass 4 std normal sind. ich merke ja den unterschied: vorher hatte ich gar keine func_details drin, da würde ich auf 4 std kommen, allerdings wird der punkt portal flow aufgerufen.

mit func_details wird der punkt portal flow nur ganz kurz aufgerufen, compilezeit 3 minuten und die map läuft.

ich denke "saubere" mapper können bestätigen, dass ihre maps eine compilezeit von wenigen minuten haben, da ich denke dass der punkt portal flow nur aufgerufen wird wenn der compiler nicht mit den solids zurechtkommt, z.B. überschneidungen, übertrieben große skys etc.

zurück zu meinem anliegen... weiß jemand rat?

So ne Menge gequirlten Bockmist hab ich schon lang nimmer gelesen...

Portalflow ist kein Error, sondern ein Essentieller Aufruf des Vising, der Sichtbarkeitsberechnung der Maps.
Nur wenn es nicht aufgerufen wird oder nur kurz läuft hast du ein Problem, was klar ist, wenn du den Boden zu Func_Detail machst, hast du schließlich ein LEAK und die Map wird nicht richtig kompiliert.

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

das portalflow kein error ist, ist mir schon klar.
allerdings: meine maps fuktionieren einwandfrei wenn portalflow nur KURZ aufgerufen wird.

wenn ich zu WENIG func_details habe wird die map ca. 4 std compiled.

ich weiß dass der boden kein func_detail sein darf, da er aber der größte
"verbraucher" in der map ist, suche ich, (um zum ursprung meines anliegens zurückzukommen...), eine möglichkeit die map zu verschließen, aber eben nicht mit riesigen bodenplatten.

Du solltest dir mal klar machen, dass das, was du da versuchst zu erreichen erstens völlig beknackt ist und zweitens auch keine Aussicht auf Erfolg haben wird.

Es gibt nur 2 Möglichkeiten.
a) Deine Map hat ein LEAK, PortalFlow wird garnicht aufgerufen, das Licht funktioniert nicht, man kann sie zwar noch spielen, aber sie ist hässlich und hat schlechte Frameraten. Dafür kompiliert sie in 3 Minuten.
Zusammenfassung: LEAK = Böhse.
b) Deine Map hat kein LEAK, PortalFlow läuft zwar 4 Stunden, weil deine Map einfach groß ist, weil du andere komplizierte Non-Entity Brushes drin hast oder was auch immer. Aber dafür ist die Map abgeschlossen, Licht funktioniert etcpp.
Zusammenfassung: Kein LEAK = Gut.

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

Ich bin zwar kein Experte im Sache Compile-Prozess. Aber so weit ich weiss, dient ja der Portal-Flow dazu, die Sichtbarkeit in einer Map zu definieren, von wo aus also der Spieler was sieht. Wenn die Map also ein LEAK hat, macht dieser Prozess nicht sehr viel Sinn, weil der Spieler ja sowieso ins Void sehen könnte, deshalb läuft er gar nicht resp. nur KURZ an.

Wenn die Map also kein LEAK hat, braucht dieser Prozess logischerweise aufgrund der komplexität der Map bzw. der Worldbrushes in der Map länger.
Eine Bodenplatte als func_detail zu machen macht ausserdem sowieso wenig Sinn, da Worldbrushes zu func_details gemacht werden sollten, wenn diese die Sichtbarkeitsberechnung im Spiel sowieso nur minim beeinflussen würden, z.B. Säulen, Geländer, Lampen, Treppen, etc.

Richman's Hazardous Course - Status: 100% !!!
www.richmans-maps.ch.vu - wieder online!

Zitat:

Richman posteteEine Bodenplatte als func_detail zu machen macht ausserdem sowieso wenig Sinn, da Worldbrushes zu func_details gemacht werden sollten, wenn diese die Sichtbarkeitsberechnung im Spiel sowieso nur minim beeinflussen würden, z.B. Säulen, Geländer, Lampen, Treppen, etc.

Bei großen Brushes, wie Deinen Bodenplatten, hast Du entsprechend viele Leafsplits und die verlängern die VIS-Zeit. Ist also völlig normal und plausibel.

Hier sind auch noch ein paar gute Tips: tutorials:map-optimierungen

gut vielleicht etwas genauer:

alles was ihr geschrieben habt ist richtig.

ich habe zwei böden: der erste boden auf dem der spieler läuft ergibt sich aus zusammengeschnippelten brushes: hecken, wege, zäune. da diese aber transformiert wurden ergeben sich leaks.

somit habe ich jetzt mehrere größere bodenplatten als zweiten(untersten boden)
gelegt, da mit nichts nach draußen kann und die map geschlossen ist.

jetzt ergibt sich jedoch das problem dass diese größere bodenplatten normale brushes sein müssen, damit sie abschließen. es ist also klar dass es keine func_details sein dürfen, damit sie auch abschließen, obwohl es logisch wäre(da sie nicht sichtbar sind) sie als func_details zu machen.
geht aber nicht, weil wenn sie worldbrushes sind, compiled er 4 std.

dann habe ich probiert sie als sky zu machen, funktioniert aber auch nicht, da ich jetzt zwar keine leaks mehr habe, aber die compileeit wieder 4 std dauert.

Versuch mal die Textur auf den "nicht sichtbaren" Bodenbrushes sehr groß zu scalen, also so Faktor 1000. Das hat afaik Auswirkungen auf das Leafsplitting und sollte so die VIS-Zeit wieder 'runter bringen. - Man möge mich korrigieren, falls ich mich irre... bin @ work und kann's nicht überprüfen.

Finde dich damit ab. Maps dauern nunmal lange zu kompilieren. Und für dein Problem gibt es keine vernünftige Lösung.

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

Zitat:

dibe postete
ich habe zwei böden: der erste boden auf dem der spieler läuft ergibt sich aus zusammengeschnippelten brushes: hecken, wege, zäune. da diese aber transformiert wurden ergeben sich leaks.

Zitat:

dibe postete
... obwohl es logisch wäre(da sie nicht sichtbar sind) sie als func_details zu machen.

Richman's Hazardous Course - Status: 100% !!!
www.richmans-maps.ch.vu - wieder online!

tja, langsam denke ich wirklich dass es zig stunden dauern wird die map zu kompilieren.

danke an thorn für den tip.

und auch an die anderen!

Das ist normal... Meine Map braucht jetzt in dem Endstadium 19 Stunden zum Compilieren, wobei 14 Stunden PortalFlow ist... und die is schon ziemlich groß und verzweigt meine Map.

Hm, da bin ich ja noch gut dran. Mein Damm für IDF kompiliert auch 3 1/2 Stunden am PortalFlow rum. Aber die Map geht immerhin fast über das gesamte Editorvolumen.

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

Zitat:

Agamemnon-Hellmapper postete
4 Stunden Kompilezeit sind durchaus normal...
Das hängt exponentiell vom Volumen der Map (und einigen anderen Dingen) ab.

Zitat:

ggggg postete
Hab zwar nich viel Ahnung aber bei mir gehts 15min wenn ich fast denn ganzen Raster mit meinem Map gefühlt habe

Muh sag ich da!
----------------------
All das ist thewall: 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 |

Zitat:

ggggg postete

Zitat:

Agamemnon-Hellmapper postete
4 Stunden Kompilezeit sind durchaus normal...
Das hängt exponentiell vom Volumen der Map (und einigen anderen Dingen) ab.

4 Stunden? Hab zwar nich viel Ahnung aber bei mir gehts 15min wenn ich fast denn ganzen Raster mit meinem Map gefühlt habe! Wird woll darin liegen wie du gebaut hast

Zitat:

ggggg postete

Zitat:

ggggg postete

Zitat:

Agamemnon-Hellmapper postete
4 Stunden Kompilezeit sind durchaus normal...
Das hängt exponentiell vom Volumen der Map (und einigen anderen Dingen) ab.

4 Stunden? Hab zwar nich viel Ahnung aber bei mir gehts 15min wenn ich fast denn ganzen Raster mit meinem Map gefühlt habe! Wird woll darin liegen wie du gebaut hast

Zitat:

wenn das Raster wirklich komplett sinnig genutzt

Um uns jetzt vom Gegenteil zu überzeugen, musst Du wohl Screenshots von Deiner fertig compilierten Map zeigen ;)

@Topic/dibe:
Du solltest noch einmal an Deiner Grundstruktur arbeiten: Am besten machst Du eine Grundplatte mit der noDraw Textur. Über diese ziehst Du dann einzelne Displacements oder Detail brushes. Falls die Details/Displacements Deine NoDraw Platte nicht überdecken, sollte an den Stellen eine Brush-Platte ohne NoDraw hin. Fertig.

Zitat:

ich habe zwei böden: der erste boden auf dem der spieler läuft ergibt sich aus zusammengeschnippelten brushes: hecken, wege, zäune. da diese aber transformiert wurden ergeben sich leaks.

Damit sollte das Thema abgeschlossen sein :)

Vor der Umstellung als Alatron bekannt

bin bei portal flow punkt 9...

jetzige dauer 44 STUNDEN !

liegts an der map???

2 threads
reading d:\spiele\steam\steamapps\xxx
reading d:\spiele\steam\steamapps\xxx
1272 portalclusters
4461 numportals
0...1...2...3...4...5...6...7...8...9...100...1

materialPath: d:\spiele\steam\xxx
Loading D:\Spiele\Steam\SteamApps\xxx
Can't find surfaceprop stone for material STONE/INFWLLJ, using default
fixing up env_cubemap materials on brush sides...
0...1...2...3...4...5...6...7...8...9...100...1...2...3...4...5...6...7...8...9...10Processing areas...done (0)
Building Faces...done (0)
Chop Details...done (1)
Find Visible Detail Sides...
Merged 226 detail faces...done (1)
Merging details...done (0)
FixTjuncs...
PruneNodes...
WriteBSP...
done (0)
writing D:\Spiele\Steam\SteamApps\xxx (0)
Creating default cubemaps for env_cubemap using skybox materials:
skybox/cx*.vmt
Run buildcubemaps in the engine to get the correct cube maps.

No such variable "$hdrbasetexture" for material "skybox/cxrt"
Can't load skybox file skybox/cx to build the default cubemap!
Finding displacement neighbors...
Finding lightmap sample positions...
Displacement Alpha : 0...1...2...3...4...5...6...7...8...9...10
Building Physics collision data...
done (1) (314990 bytes)
Emitting linux collision data (use -nolinuxdata to disable).
Building Physics collision data...
done (0) (314990 bytes)
Placing detail props : 0...1...2...3...4...5...6...7.Material NATURE/BLENDDIRTGRASS008A uses unknown detail object type coastline_redgrass01!
Material NATURE/BLENDDIRTGRASS008A uses unknown detail object type coastline_redgrass01!
Material NATURE/BLENDDIRTGRASS008A uses unknown detail object type coastline_redgrass01!
Material NATURE/BLENDDIRTGRASS008A uses unknown detail object type coastline_redgrass01!
Material NATURE/BLENDDIRTGRASS008A uses unknown detail object type coastline_redgrass01!
Material NATURE/BLENDDIRTGRASS008A uses unknown detail object type coastline_redgrass01!
..8...9...10
Compacting texture/material tables...
Reduced 2024 texinfos to 1740
Reduced 79 texdatas to 75 (1948 bytes to 1677)
Writing D:\Spiele\Steam\SteamApps\xxx
23 seconds elapsed

2 threads
reading d:\spiele\steam\steamapps\xxx
reading d:\spiele\steam\steamapps\xxx
1263 portalclusters
4467 numportals
0...1...2...3...4...5...6...7...8...9...100...1...2...3..

An was solls sonst liegen...
Es sei denn du kompilierst mit einem C64...

Wahrscheinlich hast du zuwenige Details zu Func_Detail gemacht...

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

Wahrscheinlich hast du zuwenige Details zu Func_Detail gemacht...
-eigentlich nicht.

was sagt ihr dazu?

Reduced 2024 texinfos to 1740
1263 portalclusters
4467 numportals
Merged 226 detail faces...done (1)
Building Physics collision data...
done (1) (314990 bytes)

Mach doch mal ein paar Screenshots der Map im Hammer, dann können wir uns das etwas besser vorstellen, ob Du zu viel oder zu wenig gemacht hast...

Vor der Umstellung als Alatron bekannt

Interessant wäre bestimmt auch eine Flat Ansicht des 3D Fenster, womit sich leicht erkennen lässt, was welches Entity ist.

Richman's Hazardous Course - Status: 100% !!!
www.richmans-maps.ch.vu - wieder online!