Also, in Lingas Thread bzgl. sinnvollen Thread-Subjects kam mal die Frage auf, ob die Karte bei verschiedenen 3D-Spielen am Anfang leer oder voll ist. Ich bin kein Mapper, aber als Coder habe ich mir die Kompiliertools mal näher angeschaut, und kann von daher vielleicht ein paar interessante Punkte beitragen. Tatsache ist, bei allen Spielen die auf der Quake-Engine basieren (inkl. Half-Life) ist die Karte am Anfang leer. Punkt.

Beim Kompilieren wird das Ganze allerdings etwas durcheinander gebracht. Die Compiler zerlegen die Karte nämlich in Leafs. Alle leeren (nicht vollen!!) Räume der Karte werden dabei zu Leafs, die untereinander durch Portals verbunden sind (wichtig für den VIS-Vorganag). Interessanterweise wird auch der "Außenraum" des Levels als Solid betrachtet, und daher nicht in ein Leaf verwandelt. Dabei entstehen auch gewisse Leaks.
Im BSP-Format liegt die Karte also so vor, als ob sie aus einem (unendlich) großen Block herausgehöhlt wurde (wie z.B. bei UT). Damit gehen auch gewisse Informationen verloren, z.B. die Dicke der Außenwand eines Levels. Um genau zu sein, bleiben die Solids, so wie sie im Editor erzeugt werden, nicht bestehen, sondern nur ihre Surfaces.

Das hat natürlich seine Folgen wenn das Level dekompiliert wird. WinBSP nimmt einfach die minimalen/maximalen Koordinaten des Innenraumes der Karte und erstellt als Ausgangspunkt daraus einen großen Quader, aus dem dann die Leafs herausgehöhlt werden. Logischerweise sehen dekompilierte Karten dann meist total chaotisch aus und überhaupt nicht so, wie sie vom Mapper gemacht wurden.

Ich hoffe, dieses Problem ist damit gelöst.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

perfekt!=), war wohl einigen schon bekannt(denen, die crids r_speed artikel gelesen haben) aber es ist gut, das das mal gesagt wird, ich halte es für eins der wichtigsten sachen überhaupt. wenn man das verstanden hat(den compile vorgang), erst dann kann man wirklich polygonsparend bauen, wenn man weiss, wie vis & co ein level unterteilen, wenn man das weis, kann man auch "verschiedenste" compiler fehler finden und korregieren. wenn du weisst, wie dein level in portale unterteilt wird, dann kanst du es so bauen, das am wenigsten portale berechnet werden/erst ganicht so viele entstehen.

PS: mit geschickter anwendung von hintbrushes kann man verhindern, dass portale berechnet werden, die der spieler zwar nicht sehen kann, aber trotzdem von der engine berechnet werden würden, wenn man das weis, kann man einiges an polygonen sparen. das kann schnell in die 100 gehen...