Wie der Titel schon sagt, interessiere ich mich für die (negativen) Folgen unsauberen Mappens.

Seit meiner ersten Map achte ich darauf, dass meine Brushes immer perfekt an den Kanten anderer abschließen. Da ich das auch bei aufwändigerem Brushwork (zB. Felsen, allg. Terrain, alles was nicht 90 Grad ist...)
beibehalte, muss ich jede Menge Clippen, Vertexen bzw. neue Brushes erstellen.

Mache ich mir nun die ganze Zeit umsonst so eine Arbeit oder profitiere ich irgendwie davon?/Was sind die Nachteile von unsauberem Mappen?

Der einzige mir bisher bekannte Nachteil zeigt sich Ingame, wenn sich 2 Faces überlager (Flimmer/konstanter Texturwechsel), sollten viele von euch kennen...

Ich habe hier nichts gelesen was direkt dagegen gesprochen hat, jedoch hatte ich den Eindruck sauberes Mappen sei besser - nur warum?

Hilfestellung nach dem Vorbild TheWall: "Lies die Tutorials, Kacknoob wolololo" -Agamemnon-Hellmapper

bei unsauberem mappen können mikoleaks entstehen, außerdem können burshs beim kompilieren aufs grid gezogen werden, wodurch ecken und kanten entstehen, die nicht nur die spieler behindern, sondern auch scheiße aussehen

Nur die, welche sich für ganz stark und extra erwachsen halten trinken Kaffee ohne Milch. Das sind meist auch die Leute, welche rassistisch und homophob sind. Da Rassismus von Minderwertigkeitsgefühlen und Homophobie von latenter Homosexualität stammt, trinken also nur ängstliche Schwule Kaffee ohne Milch. Das wurde wissenschaftlich durch Galileo auf Pro7 bewiesen.

Hmm stimmt schon. Ich versuche auch immer drauf zu achten, dass alles sauber ist. Allerdings glaube ich, dass in HL in den Außenlevels die Felsen teilweise auch sehr grob ineinander gesteckt wurden. Also ich sage mal wenn ingame alles stimmt, braucht man sich für unsaubere Felsen nicht schämen.

Spielen: Prison, Ispatel 4: Classic, Heart of evil
Anschauen: Spirit of Half-Life: Legion

The Trap ist mit abstand die fantastischste Mod die ich seit langem gespielt habe!

Nicht das ihr mich jetzt falsch versteht. Mir geht es nicht um Verticles, die nicht auf dem Grid liegen, sonder um ineinander hängende Brushes, zB. bei einem simplen Busch mit transparenten Texturen wie hier:

http://forum.myrabbits.de/downloads/de_tuscan_TEv.jpg

Das Brushwork ist ein Kreuz aus 1 Unit dicken Brushs und die Frage ist nun ob diese sich denn besser überkreuzen sollen oder eben nicht...

Hilfestellung nach dem Vorbild TheWall: "Lies die Tutorials, Kacknoob wolololo" -Agamemnon-Hellmapper

r_speed Artikel/Tuts schon gelesen?

die Funktionsweise der HL Engine verstanden?

Was deine Frage zu dem Bild angeht:

1. Verstehe ich nicht zu 100%, was du meinst

2. Wenn du ein solid mit einem anderen solid schneidest, entstehen neue faces bzw. die vorhandenen faces werden nochmal geteilt, in eine teilweise, für die Engine höchst umständliche Anzahl neuer Faces: Da werden auf 4 wpolys dann schon mal 20. Das summiert sich dann auf Dauer, wenn z.B. jede von 3 Lampen an einer Wand diese "zerschneidet"...

Entities werden von der Engine nicht als solids behandelt und haben für die Berechnung der Faces keine Bedeutung (Unterscheidung: wpoly/epoly).

Wenn du jetzt, wie ich vermute, in Tuscan die Busch-brushes auf dem Boden meinst --> die zerschneiden dir den Boden nicht, da sie entities sind. Solids würden das tun und bei deinem Beispiel Bild aus dem Boden mal eben ein Mosaik an Faces machen. Genau so ist es wahrscheinlich mit den Markisen, die da überall hängen: Werden alle entities sein und somit keine solids schneiden.

edith meint: Das betrifft nicht nur das richtige "Zerschneiden" von solids durch andere solids, sondern jedesmal, wenn ein face auf einem anderen liegt/anliegt... Wie gesagt: r_speeds artikel lesen klärt hier auf.

Kann aber auch sein, dass ich totalen Mumitz erzähle, is schon n Weilchen her, dass ich mich mit goldsrc beschäftigt hab :) Lasse mich gern berichtigen.

Und ja, manche Maps sind unsauber gemapt, was in vielen Fällen kein Problem mehr darstellen dürfte: Viele Rechner vertragen auch heutzutage 1,5-2k wpolys. Als ich zu mappen angefangen hab, warens noch max 800 :)
Manchmal krieg ich Gänsehaut, wenn ich so manche map-file gesendet krieg zum angucken ^^ Und trotzdem laufen die Maps auch bei 32 Spielern wunderbar...
Nur irgendwann stößt auch goldsrc an seine Grenzen und dann gehts los mit dem Geruckel :)

*doppelpost* :(

Damit der Doppelpost auch genutzt ist:

http://www.thewall.de/content/half-life:tutorials:r_speeds

Absatz 2 dürfte deine Frage beantworten.

Das gleiche passiert auch, wenn du mit solids andere solids zerschneidest.

Deshalb gibt es die Möglichkeit, z.B. aus der Säule ein func_wall zu machen oder nen clip-brush drum zu setzen (wie auch im artikel beschrieben), um wpoly zu sparen.

Nur zuviele dürfen es natürlich auch nicht werden, sont geht dein epoly count hoch und irgendwann schmiert der server ab (epoly sind alle entities, models, auch spieler, ihre waffen uswusf. die ein client zu einer bestimmt Zeit sehen kann und berechnen muss).
Aber bei Natural Selection hat man teilweise bis zu 28000 epoly und da Game kackt trotzdem nicht ab, also hat man mit epoly etwas mehr freiraum als bei den wpolys :)

Zitat:

Wiedehopf postete
r_speed Artikel/Tuts schon gelesen?

die Funktionsweise der HL Engine verstanden?

Was deine Frage zu dem Bild angeht:

1. Verstehe ich nicht zu 100%, was du meinst

2. Wenn du ein solid mit einem anderen solid schneidest, entstehen neue faces bzw. die vorhandenen faces werden nochmal geteilt, in eine teilweise, für die Engine höchst umständliche Anzahl neuer Faces: Da werden auf 4 wpolys dann schon mal 20. Das summiert sich dann auf Dauer, wenn z.B. jede von 3 Lampen an einer Wand diese "zerschneidet"...

Entities werden von der Engine nicht als solids behandelt und haben für die Berechnung der Faces keine Bedeutung (Unterscheidung: wpoly/epoly).

Wenn du jetzt, wie ich vermute, in Tuscan die Busch-brushes auf dem Boden meinst --> die zerschneiden dir den Boden nicht, da sie entities sind. Solids würden das tun und bei deinem Beispiel Bild aus dem Boden mal eben ein Mosaik an Faces machen. Genau so ist es wahrscheinlich mit den Markisen, die da überall hängen: Werden alle entities sein und somit keine solids schneiden.

edith meint: Das betrifft nicht nur das richtige "Zerschneiden" von solids durch andere solids, sondern jedesmal, wenn ein face auf einem anderen liegt/anliegt... Wie gesagt: r_speeds artikel lesen klärt hier auf.

Kann aber auch sein, dass ich totalen Mumitz erzähle, is schon n Weilchen her, dass ich mich mit goldsrc beschäftigt hab :) Lasse mich gern berichtigen.

Und ja, manche Maps sind unsauber gemapt, was in vielen Fällen kein Problem mehr darstellen dürfte: Viele Rechner vertragen auch heutzutage 1,5-2k wpolys. Als ich zu mappen angefangen hab, warens noch max 800 :)
Manchmal krieg ich Gänsehaut, wenn ich so manche map-file gesendet krieg zum angucken ^^ Und trotzdem laufen die Maps auch bei 32 Spielern wunderbar...
Nur irgendwann stößt auch goldsrc an seine Grenzen und dann gehts los mit dem Geruckel :)

*doppelpost* :(

Damit der Doppelpost auch genutzt ist:

http://www.thewall.de/content/half-life:tutorials:r_speeds

Absatz 2 dürfte deine Frage beantworten.

Das gleiche passiert auch, wenn du mit solids andere solids zerschneidest.

Deshalb gibt es die Möglichkeit, z.B. aus der Säule ein func_wall zu machen oder nen clip-brush drum zu setzen (wie auch im artikel beschrieben), um wpoly zu sparen.

Nur zuviele dürfen es natürlich auch nicht werden, sont geht dein epoly count hoch und irgendwann schmiert der server ab (epoly sind alle entities, models, auch spieler, ihre waffen uswusf. die ein client zu einer bestimmt Zeit sehen kann und berechnen muss).
Aber bei Natural Selection hat man teilweise bis zu 28000 epoly und da Game kackt trotzdem nicht ab, also hat man mit epoly etwas mehr freiraum als bei den wpolys :)

Anscheinend hat mein Post nur für mich Sinn ergeben, da du mich wahrscheinlich falsch verstanden hast...

Mir geht es nicht um aneinander liegende Solids (->Zerschneiden, wie von dir beschrieben) sondern um ineinander liegende/hängende.

Der einzige mir bisher bekannte Nachteil zeigt sich Ingame, wenn sich 2 Faces überlager (Flimmer/konstanter Texturwechsel).

Reicht es also wenn alles, was Ingame dargestellt wird in Ordnung ist (auf dem Grid,keine überlagernden Texturen, Beachtung der Zerschneidung durch anliegende Faces)?
Denn Ingame werden nur die "inneren" Faces dargestellt, ist somit der "Rest"(dem Void zugewandt) irrelevant?

Ich weiß, das ist alles schwer zu verstehen, ist aber auch nicht leicht zu erklären xD...

Hilfestellung nach dem Vorbild TheWall: "Lies die Tutorials, Kacknoob wolololo" -Agamemnon-Hellmapper

Wenn ich das richtig im Kopf habe, ist es für die Engine irrelevant, ob das solid jetz nur "anliegt" oder es den anderen brush zerschneidet. Dürfte im Endeffekt die selbe Berechnung sein, was w_polys angeht, da ja nur berechnet wird, was sichtbar und nicht dem Void zu gewandt ist (und der void beginnt ja trotz brushing direkt hinter dem sichtbaren face --> sieht man ja bei den 1unit wänden beim decompilen; alles was hinter dem berechneten face ist, ist quasi nicht vorhanden).

Du zerschneidest dir halt alles damit und hast irgendwann zu viele faces...
Und es wäre doch nicht schön, nen max_patches ERROR zu kriegen, nur weil man nicht sauber gebrusht/mit entities gearbeitet hat, um extra-faces zu vermeiden und deshalb immer mal wieder irgend welche extra Patches hat, die nicht nötig wären.

Genau so das Überlagern von Texturen: Doppelter Aufwand für die Engine bei einem schlechteren (blöd aussehendem) Ergebnis.

Ich weiß nicht, wie fortgeschritten du mapst, aber ich komm regelmäßig bei CS-Maps an die Limits und ich muss um jedes Face geiern, dass ich einsparen kann.

Und eins sag ich dir: Wenn ich in Nuke hinten runter geh, um von hinten auf den unteren Spot zu kommen, dann seh ich als mapper ganz genau, dass die Rohre da unten unsauber gemapt sind ;)

Ich schätze er meint die Pflanzen am Boden, die zerschneiden sich. Aber da sie keine Solids darstellen, ist dies auch kein Problem.

Ich denke, was funtex meint ist folgende Situation:
Möglichkeit A)

Möglichkeit B)

Ist es jetzt "besser" wenn der Brush wie in Möglichkeit B genau am anderen anliegt oder kann man auch Möglichkeit A mit in einander steckenden Brushes verwenden, ohne dass es die Engine negativ beeinträchtigt.

Bei den Pflanzen am Boden ist auf jeden Fall die bessere Möglichkeit, wenn die 2 Brushes aus denen sie bestehen sich überschneiden und beide einzeln zu entities gemacht werden und ihre kanten (also alles außer vorder- und rückseite) mit NULL-textur belegt sind.

Der Grund ist folgender:
1) Machst du die pflanzen z.b. aus 3 Brushes hast du mindestens 6 Faces. 2 für vorder- und rückseite des langen brushes, 4 für die vorder und rückseiten, die (geteilt durch des ersten langen brushes) dann dden ersten brush kreuzen.

2) Machst du überschneidende Brushes und zu einem entity, passiert genau das gleich wie mit worldbrushes die sich berühren. Die Faces werden zerschnitten. Das passiert aber nur innerhalb eines Entities. Hier kommt es compilertechnisch also automatisch zum gleichen ergebnis wie 1) mit 6 Faces.

3) machst du 2 kreuzende Brushes zu jeweils seperaten Entities passiert das nicht. Entities splitten sich die Faces nicht gegenseitig. Du hast also nur 4 Faces, nämlich jeweils 2 für vorder- und rückseite des kreuzes.

Dazu kommt noch, dass 3) am besten aussieht, weil bei den anderen beiden möglichkeiten scheinen teile des entities zu "verschwinden" wenn man es anguckt. Man kann nämlich niemals durch ein Face eines Entity ein anderes Face des selben Entity sehen. Für dich erscheint zwar das 255-Blau ingame durchsichtig, die Engine blockt aber jede weitere sicht auf andere Faces des gleichen entities die dahinter liegen. Du kannst also durch transparente Faces nur andere Entities oder Worldfaces sehen.

Zitat:

manionsen postete
Ich denke, was funtex meint ist folgende Situation:
Möglichkeit A)
http://bildupload.sro.at/a/thumbs/16-1.jpg

Möglichkeit B)
http://bildupload.sro.at/a/thumbs/41-2.jpg

Ist es jetzt "besser" wenn der Brush wie in Möglichkeit B genau am anderen anliegt oder kann man auch Möglichkeit A mit in einander steckenden Brushes verwenden, ohne dass es die Engine negativ beeinträchtigt.

Jetzt fehlt mir nur noch eine Antwort ;)

Hilfestellung nach dem Vorbild TheWall: "Lies die Tutorials, Kacknoob wolololo" -Agamemnon-Hellmapper

Also ganz irrelevant scheint es nicht zu sein, denn man kann CSG dazu veranlassen zu überprüfen, ob es solche Stellen in der Map gibt, an der sich Brushes zu mehr als xx% überlappen. Es ist also möglich, dass wenn Brushes sich überlappen Fehler wahrscheinlicher auftreten können.

Probiere doch anhand eines Raumes selbst aus, ob du irgendwas merkst. Machst zwei Maps mit einer schrägen Wand und einmal geht ein Block exakt an diese ran und einmal aus der Map raus. Dann vergleichst du die Statistiken der Compilerlogs (Fehler(?), Compilezeit, usw), r_speeds bzw. w_polies und überprüfst deine beiden Räume nach unsichtbaren Blöcken sowie mit gl_wireframe (Opengl) oder r_drawflat (Software).

Es würden sich vermutlich einige über Info's darüber freuen.

wenn im origen bsp die schräge einen winkel hat den die engine nicht mag können dort sehr kuriose sachen entstehen, die jenseits von jeglicher erklärung liegen
wenn du normale steigungswinkel hast zb 1/4 oda 2 o.ä. dann passiert da aber nichts
fidne es einfach ästetischer genau zu mappen
bei "komischen" schrägen ist es aber manchmal hilfreich durchzuziehen weil sonst microleaks oda andere komische sachen apssieren können

Nachdem jetz geklärt ist, was gemeint war, mal meine Theorie :D

Grade bei der Schräge und dem anliegenden Brush ist es, denk ich sehr wichtig, dass die Eckpunkte der Berührungsfläche auf dem Grid liegen.

Wenn sie das tun, solltest du keine Probleme kriegen bei dem oben genannten Beispiel.

Ist die Schräge ein Entity, könntest du Probleme kriegen. Imho mag die Engine das nicht und es entstehen ganz komische Clipnodes bei zu komplexen Strukturen.

Aber wie gesagt: Solang die Solids auf dm Grid liegen, dürfte das keine Probleme geben.

Ob du jetzt, wie beim 1. Beispiel durch das Face mappst (unsauber) oder nicht, ist, wenn ich das richtig verstanden habe, eigentlich egal. denn berechnet wird ja nur alles zum Void hin. Ich denke, die Schräge zerschneidet den reinragenden solid dann an den Berührungslinien in Faces, eigentlich dürften keine extra faces entstehen.
Wie gesagt, nur ne Vermutung.