ja, vielen dank @HammerBlade: dein fachchinesisch hat mir sehr geholfen ob mans glaubt oder nicht... ich komme ja auch von der quake3 engine und habe dort ebenfalls mit caulk gearbeitet....
also ist mein einziger vorteil nun, dass der compiler weniger zeit benoetigt, wie ich verstanden habe.. wenigstens etwas :)
aber was ich nun nicht verstehe: erst sagst du, dass meine vorgehensweise sehr aufwendig ist und danach schreibst du, dass du auch immer so vorgegangen bist wie ich. soll/kann ich aus der vergangenheitsform, welche du gewaehlt hast, dass du das jetzt nicht mehr so machst?

Zitat:

Cmd.Keen postete
also ist mein einziger vorteil nun, dass der compiler weniger zeit benoetigt, wie ich verstanden habe.. wenigstens etwas :)

Aber die wichtigste Sache für eine gute Performance ist neben einem vernünfigen Layout (also ein gutes Leaf-Layout mit alle was dazu gehört: HINT/SKIP, Areaportals, ...), dass man vvis auf Normal (full) laufen lässt (damit das gute Leaf-Layout auch zur Geltung kommt). Die nodraw-Textur ist da eher nur das "Tüpfelchen auf dem i" für die Performance einer Map.

Ich scheine wirklich ein Problem zu haben mich verständlich auszudrücken...

Zitat:

HammerBlade postet
Deine Vorgehensweise führt auch zum Zeil, ist aber im Endeffekt wahrscheinlich sehr aufwendig, denn die nodraw-Textur kommt nur bei Faces zum tragen, die nachher wirklich im BSP-Tree auftauchen, d.h. auf alle Faces, die ausserhalb der Map liegen (nicht zum BSP-Tree/Inneren der Map gehören) hat die nodraw-Textur keine Einfluss, da diese Faces im .bsp eh nicht vorhanden sind. Auch Faces die zwischen 2 Brushes liegen, also die beiden Faces an denen sich 2 Brushes berühren tauchen nicht im BSP-Tree auf, auch hier hat die nodraw-Textur keine Auswirkung. Ich bin immer so vorgegangen die Map erst ohne nodraw-Textur (null-Textur) zu bauen und dann immer wieder zu schauen, ob es Faces gibt, die der Spieler nicht sehen kann und diese dann mit nodraw-Textur zu belegen.

Ich habe nicht gesagt, dass ich so vorgegagen bin wie du und das der Satz "Ich bin immer so vorgegangen ..." sich auf die Vergangenheit bezieht ist richtig, denn ich habe für HL2 noch nichts größeres (z.B. eine ganze DM-Map) gemappt, bis jetzt nur Kleinigkeiten, um die Phsyik oder sonstiges zu testen. Wie gesagt, meine Erfahrung beziehe ich aus langjährigem Mappen für HL1 und der Erfahrung, die ich sammle, wenn ich mich mit den Mappingproblemen (-fehlern) andere Leute hier im Forum beschäftige.

Cmd.Keen vs HammerBlade...
Also noch mal zusammengefasst:

Du belegst alle Faces mit nodraw-Textur ausser die, die der Spieler (deiner Meinung nach) ingame wirklich sehen kann. Dadurch machst du dir mehr Arbeit als nötig (meiner Meinung nach, aus eben denn genannten Gründen).

Ich belege nur die Faces mit nodraw-Textur, auf denen sie wirklich Auswirkungen auf Compilezeit (eher nicht so wichtig, weil Einfluss gering) und Performance (schon wichtiger) hat. Also Faces die wirklich im BSP-Tree landen, aber die der Spieler nie zu Gesicht bekommt (z.B. die Oberseite einer hohen Mauer). Das passiert schon während des Mappens und teilweise auch in der Phase in der man sich sein Map intensiv von allen Seiten betrachtet, um zu sehen was man hier und da noch verbessern könnte an Design, (Leaf-) Layout und Performance.

Optimierung:
Zum Thema Optimierung von HL-Maps sollte man auf jeden Fall die beiden r_speeds-Artikel im Wiki und LePrau's HINT/SKIP-Tutorial lesen. Die 3 Sachen sind zwar für HL1 geschrieben worden, gelten aber für HL2 nach wie vor. Im Bezug auf die Optimierung von HL2-Maps gibt es ja noch neue Hilfsmittel, wie Areaportals, Occluder, usw., welche in diesem Worddokument recht gut befandelt werden:

http://www.student.kun.nl/rvanhoorn/Optimization.doc
http://www.student.kun.nl/rvanhoorn/Optimize.zip

(Gefunden von Larry auf http://forum.interlopers.net/viewtopic.php?t=1480&start=0)

Auch wenn Cmd.Keen das technische Hintergrundwissen über den Aufbau und die Funktionsweise einer BSP-Engine für "Fachchinesisch" hält, bin ich doch der Meinung, dass man diese Dinge (zu mindest grundlegend) wissen sollte, weil man sonst Handwerkszeuge, wie die nodraw-Textur, HINT/SKIP, Areaportals, Occluder, usw. nicht wirkungsvoll einsetzten kann, um in Hinsicht auf die Performance eine gute Map zu bauen.

Edit:
Ich hab gerade mal über die caulk-Textur von Quake nachgelesen und bin der Meinung, dass sie äquivalent zur nodraw-Textur (null-Textur) von HL ist.

In einigen Artikeln/Quellen war allerdings die Rede davon, dass man die caulk-Textur auch auf Faces packen sollte - die eigentlich (zumindest bei HL) nicht im BSP-Tree sind, also für die Engine überhaupt nicht existent sind - um die QuakeEngine davon abzuhalten diese Faces unnötigerweise zu rendern. Diese Faces, von denen die Rede ist (wenn ich die Beschreibung richtig verstanden habe), sind deckungsgleich und stellen die Berühfläche zwischen 2 Brushes dar, so dass sie also eigentlich nicht im BSP-Tree auftauchen sollten, also das caulken solcher Faces eigentlich unnötig ist. Vielleicht ist das bei Quake anders, würde mich aber wundern.

Aber vielleicht kann da ja jemand mit Quake-Mapping-Erfahrung etwas zu sagen.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

Ich baue zwar feine Maps, aber die Optimierung ist wirklich schlecht!

Hab teilweise 40-50 Frames auf meiner Map und ich bin mir sich, dass dies nicht sein muss.! ( full details, Geforce 6800 GT)

Aber ich ralle das einfach nicht mit den Hint brushes etc.! ich kann auch englisch, aber wenn englisch und ne Beschreibung dazukommt, dann hakt es bei mir.
ich hab mir schon diverse tuts über Hint etc. durchgelesen, das verstehe ich auch, wie es gemeint ist. wenn ich dann aber wieder meine Map sehe, mit großen, vielen Räumen, dann ist wieder alles weg.

ich würde gerne noch einiges in meine Map hineinbauen ( Displacements), aber wenn ich die nicht optimiere, brauch ich damit gar nicht erst anzufangen.

"Gebt dem FASCHISMUS keine Chance!!!"

Genau das ist das Problem: die Tutorials mit den Hint brushes etc. werden immer unter "Laborbedingungen" erklärt. Unter diesen Umständen ist es nachvollziehbar. In der Praxis an der eigenen Map isses dann wieder Essig. Ich fände ein Praxisbezogenes Beispiel mit VIELEN Bildern besser. Am Besten eine Map mit einem Haus in der Mitte eines Gartens, wobei das Haus zwei Stockwerke hat, in jedem Stockwerk mindestens 2 Fenster und Türen (die ja dann nix blocken) und ein Glasdach. Wo setzt man Hintbrushes an? Ich habe übrigens (rein zufällig) genau so eine Map mit Areaportals an Fenstern und Türen "abzudichten" versucht. Allerdings ist der Fadingeffekt so störend gewesen, dass ich es wieder rausgebaut habe. Jetzt habe ich EINEN fetten Hintbrush (vom Boden bis zur Skytextur, vom rechten zum linken Rand , 8 units dick), der quer ca. in der Mitte der Map und in der Mitte des Hauses durchgeht. Ob das was bringt? Keine Ahnung...

@gaatz:
Die ganzen verschieden Möglichkeiten eine Map zu optimieren unter nicht-"Laborbedingungen" sinnvoll anzuwenden ist nicht trivial, dass stimmt, da muss man Erfahrung sammeln und mit der Zeit kriegt man dann raus wo man was und wie am besten einsetzt.

Vorschlag:
Du mappst mal eine Beispielmap (ohne irgendwas daran zu optimieren) und lässt sie mir dann zukommen. Ich versuche dann soviele Optimierungsmethoden wie möglich an dieser Map zu illustrieren. Dann haben wir da beide was von: du bekommst dein Tutorial unter (eher) "reallife"-Bedingungen und ich beschäfftige mich mal wieder intensiver mit Mapping.

Edit:
Wenn eine Map von vornherein schlecht (für die Performance) gemappt ist, oder man versucht Sachen zu mappen, bei denen man eigentlich schon von vornherein sieht, dass die Performance schlecht sein wird, kann man da so lange daran herum optimieren wie man will, dass wird dann nichts mehr.

Perfomance-Optimierung durch HINT/SKIP, Areaportals, usw. zielt immer darauf ab, dass die Engine möglichst wenig rendern muss. Was man versucht dadurch zu erreichen, dass man mt den genannten Hilfsmitteln die Leaf-/Detail-Aufteilung der Map in diesem Sinne zu verbessern. Aber wenn die Map z.B. nur aus einer grossen Fäche voller Details besteht, kann man da durch Leaf-Layout-Optimierung auch nichts mehr machen, da es der Map einfach an "natürlichen" VisBlocker fehlt. Da hilft es dann auch nichts eine HINT/SKIP-Brush quer durch die Map zu ziehen, um das einzige Leaf in 2 zu spalten, denn es ist ja trotzdem alles für die Engine sichtbar.

Schade, dass es in HL2 r_drawoder 1 nicht mehr gibt, das ist zwar jetzt in mat_wireframe 1 intergiert, aber imo hat man nicht mehr so gut den Eindruck davon was die Engine _wirklich_ von der Map sieht.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

Also ich weiß jetzt, woran es lag:
Es waren die verdammten dynamic lights....
Boah ich Depp, so was einfach und 2 Wochen nicht gefunden!!!

"Gebt dem FASCHISMUS keine Chance!!!"

Ah,dann is mein gefundener Artikel doch noch angekommen irgendwo :) gut!

Was auch immer ich tue,ich tue es rasch,damit ich etwas anderes tun kann.
DL-Tower Map Serie

@blademaster: ohman - ich wollte dich nicht provozieren so viel zu schreiben.. und das mit dem fachchinesisch meinte ich auch eher ironisch.. naja, ihr gewoehnt euch sicherlich noch an meine schreibweisen.... und ein fettes danke fuer deine ausfuehrlichen beschreibungen ! :)

jetyt wo ich all dies gelesen habe moechte ich allerdings gerne wissen, woher du weisst welche faces mit nodraw txturen belegt werden muessen und welche nicht.. ich meine.. ich klebe die ja sowieso ueberall hin.. so wie frueher die caulk textur.. ich bin es gewohnt, dass alles so komisch aussieht und mach das halt echt erst am ende mit den texturen.. naja, ich habs ansonsten so weit verstanden wie der hase in HL2 laeuft und will auch nicht weiter mit diesem problem nerven.. :D

Nach einer Weile bekommt man ein Gefühl dafür wo man überall nodraw draufpacken kann/soll/muss. Das ist so wie mit der "Ich-kann-sehen-welches-Sachen-die-Performance-schlecht-machen"-Fähigkeit, die von verschiedenen Leuten in diesem Thread angeführt wurde.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

ja das merke ich auch.. allerdings sehe ich das meist an der struktur der elemente da ich ja sowieso immer nodrawe :) naja.. das wird schon dank dieser seite :D

Ich muss sagen, dass Worddocument das Hammerblade verlinkt hat, hat mir eine Menge Fragen beantwortet. Bei meiner Map habe ich nämlich auch das Problem, dass ich (da nachgemapptes reales Vorbild) extrem viele Fenster habe und man dadurch grosse Teile der Map sehen kann.
Die wichtigste Erkenntnis, die auch aus dem Dokument oben mit genommen habe, ist dass alle Leaves berechnet werden, die theorethisch von dem Leaf auf dem sich der Spieler befindet, gesehen werden können, d.h. 360° rundherum, egal wohin der Spieler schaut.
Es bleibt mir deshalb kaum was anderes übrig, als am Grundaufbau einige Details zu ändern, da ich mit keiner Optimierungsmöglichkeit aufgrund des Mapaufbaus sonderlich viel herausholen könnte.

Das ist eine sehr wichitige Erkenntniss: Wenn das grundlegeden Layout der Map verantwortlich für die schlechte Performance der Map ist, kann man daran nicht viel mit Optimierung durch HINT/SKIP, Areaportals usw, verbessern. Dann muss man das grundlegende Layout der Map in Hinsicht auf die Performance verbessern.

Man kann mit HINT/SKIP, Areaportals usw. eine Map nur optimieren, wenn das grundlegende Layout vernünftig (in Hinsicht auf die Performance) ist.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

ich hab eigentlich auch keinen blassen schimmer wie man hint und skip texes richtig einsetzt, jedoch weiß ich eine möglichkeit wofür die sich richtig gut eignen (zumindest die hint tex). jeder hat bestimmt schonmal in seiner map ein "leaf portal saw into leaf portal" fehler gehabt (man kann dann ingame aus der map herraus gucken, als ob da ein leak wäre aber doch keins dort ist ^^). an dieser stelle baut man dann in der map einfach ein hint brush hin und beim nächsten kompilen ist alles wieder in butter ;)

da voo

Das ist auch ein Einsatzort von HINT/SKIP.

Ich schreibe deshalb immer HINT/SKIP, weil HINT und SKIP zusammen gehören. Die HINT-Textur zwingt vbsp, an der Face auf der HINT liegt, ein Portal zu erzeugen, also ein Leaf zu splitten. Die SKIP-Textur erzeugt keinen Leafsplitt, sie dient einfach nur dazu, dass man HINT gezielt einsetzen kann, denn ein Brush hat für gewöhlich 6 Faces, meistens braucht man aber nur eine HINT-Face.

Wenn du bei deiner "leaf portal saw into leaf portal"-Fehler-Bekämpfung einen Nur-HINT-Brush benutzt sind 5 der 6 HINT-Faces ünnotig und erzeugen womöglich noch unnötige Leafs. Ich würde nur auf die wirklich nötige Face zur Fehlerbebegung HINT legen und auf alle anderen Faces SKIP.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

und wie erkenne ich die wirklich nötige face ? nur die face die wie ein deckel abschließend wirkt oder wie?
wenn man zb einen würfel hat, der an einer seite offen ist, und an dieser stelle der portal fehler ist, dann packt man dann ein hint/skip brush drauf, wo die hint textur den würfel theoretisch abschließen würde, und die anderen seiten bekommen ne skip textur oder wie?

da voo

Genau so ist es.

"Mit C++ (noch besser mit C) kann man sich _sehr_ leicht in den Fuss schiessen." - theDon
Auspack und freu! - Auszug aus einer, aus dem japanischen übersetzten, Bedienugsanleitung für ein Spielzeugaquarium.
--
Photon Audio Player | Majestic42.net | How To Ask Questions The Smart Way

nur leider ist es damit nicht getan (wie ja auch schon im entsprechenden Tutorial steht). Denn solange die SKIP faces mit allen Kanten auf einer Linie liegen, provozieren sie trotzdem noch einen Split. Uum sicherzugehen, dass keine unnötigen Leafs produziert werden, sollte man also nochmal mit dem vertex tool ran.