[c=800000]w_polys, e_polys, shitegal !?[/c]
----------------------------------------------
Hallo Mappergemeinde

ich muß dieses leidige Thema hier im Forum nun auch mal ansprechen. Das hat folgenden Hintergrund:
Als ich aus Langeweile letzten Samstag (Feiertag, Regenwetter im Süden Deutschlands) mal wieder planlos vor dem Rechner hockte (hab leider oder gottseidank noch keinen privaten Internetanschluß) fielen mir einige ältere HL-Demomaps auf, welche ich vor einiger Zeit als "Newbie" erstellt habe. Das sind hauptsächlich so kleine Design-Studien, wie wohl jeder anfangs so gebastelt hat, Sachen wie "2 Räume verbunden durch eine Tür", "abfließendes Wasser", ec..
Dabei war auch ein kleiner, in sich abgeschlossener Raum mit einer Lichtquelle, ohne Tür, so eine Art "Rumpelkammer" worin ich damals das ein oder andere Prefab erstellt habe. Ich starte also meinen Quark5-Editor und wollte mir die Sachen nochmal ansehen, bevor die Files gelöscht werden. Das meiste habe ich dann auch gelöscht, die Rumpelkammer hat mich aber näher interessiert, zumal ich damals alles mit world_brushes gebaut habe (mitleidiges überhebliches Lächeln). Mein Plan war jetzt, alles nochmal im Original durchrendern zu lassen und anschließend alle world_brushes zu func_walls portieren, unter anderem Namen abzuspeichern und beide Maps anschließend zu testen. Ich hatte ja nichts besseres zu tun und wollte mir dann auch selbst auf die Schultern klopfen nach dem Motto "ich mache jetzt alles besser, freu freu". Gesagt,getan.

Beschreibung der Rumpelkammer
An dieser Stelle wäre es angebracht, Screenshots als .gif Grafiken darzustellen, doch leider weiß ich nicht, wie das geht (schäm), nicht die Screenshots, die hab ich schon gemacht- aber das einbinden. Ich habe zwar in der Hilfe den Befehls-tag dazu gefunden doch wie krieg ich meine Bilder auf den Server?? vielleicht postet das mal ein netter Mensch..
(Fingerknacken) Rumpelkammer: Vier Brushes für die Wände, ein Boden, eine Decke, Betontexturen. Auf dem Boden stehen 2 Fässer (8-eckige Zylinder), ein zusätzliches Faß liegt umgekippt horizontal in der Ecke. An einer Wand steht ein Regal, bestehend aus 4 senkrechten Eckpfosten mit 4 horizontalen Brettern als Regalböden. Im Regal stehen eine Werkzeugkiste, 3 Pappkartons, eine morsche Holzkiste und ganz obenauf 3 Munitionskästen, wobei eine senkrecht steht, eine davon lehnt 45° gekippt an der letzten, die voll auf der Seite liegt. Das Regal ist also vollgepackt, steht auf dem Boden und berührt gleichzeitig die Rückwand. An der angrenzenden Mauer steht ein ähnliches Regal mit ähnlicher Bestückung. Am Boden liegen einige Kleinigkeiten, Crowbar, Kisten usw.. eben eine kleine Kammer und jede Menge Stuff. Die beiden anderen Wände sind leer. Der Spieler kann sich so in den Raum stellen, daß er alle Gegenstände gleichzeitig im Blickfeld hat.
Die meisten Sachen berühren sich irgendwo, die Regale berühren Boden und Wand und die Objekte in den Regalen liegen auf den Brettern auf.

In der ersten Map (Name L1.bsp) habe ich sämtliche Objekte zu func_walls gemacht, und die Compiler voll laufen lassen (Gesamtdauer ca 3 Minuten)

Ergebnisse (r_speed) bei 800x600 opengl:
L1: 37 fps 9ms 198 wpoly 597 epoly

In der zweiten Map (Name L2.bsp) besteht alles aus world_brushes- eine Totsünde- (Compiledauer ca 12 Minuten)

Ergebnisse (r_speed):
L2: 37 fps 9ms 222 wpoly 537 epoly

Das hatte ich nicht erwartet !
[c=800000]In der "schlechten" Map nur lächerliche 24 w_polys mehr, gleiche Framerate, gleiche Bildaufbauzeiten.[/c]

Ich dachte, da müsste doch ein merklicher Unterschied bestehen. Und außerdem: wo kommen die satten 198 W_polys bei L1 überhaupt her, wo doch alles aus entities besteht. Ich gab in der Map L1 den Consolenbefehl

r_drawentities 0

ein und ALLE Einrichtungsgegenstände verschwanden wie erwartet, nur die rohen Mauern waren noch zu sehen. Die r_speeds waren dann 32 w_poly 0 e_poly. Ich hatte also keinen Fehler gemacht (grübel, grübel, lange grübel, zigarette dreh, smoke, rauch in augen, blinzel).

Ich schließe daraus:
a) die Körper von func_n erzeugen entgegen der landläufigen Meinung haufenweise w_polys !

b) das Zerschneiden der Umgebung bei direkter Berührung wirkt sich bei Verwendung üblicher 3d Grafikkarten entweder gar nicht aus und ist ein Relikt des Softwaremodus, oder

c) das Zerschneiden findet statt, wird jedoch sowohl von world_brushes wie auch von func_walls gleichermaßen verursacht.

Egal jetzt wie und warum, alleine das Ergebnis stellt meine bisherigen Mappinggrundsätze zum Teil auf den Kopf.

Fazit:
Da der optische Eindruck des vermeintlich "schlechten" Mappings um einiges besser ist (durch die Schatten und differenzierter Helligkeit der Brushes viel stimmungsvoller) und ich nur in der Kompilierzeit einen Unterschied ausmachte, werde ich meine Treppen und Säulen in Zukunft wieder aus world_brushes erstellen.

Andererseits will ich hier auch keinen Mist verzapfen, aber die Testergebnisse sind für mich eindeutig.

Hat jemand ähnliche Versuche durchgeführt? Mich würden Eure Erfahrungen interessieren, schließlich geht es ja um unsere "10 Gebote".

Also liebe Mapping-Propheten auf "the german first mapping site" (schleim), funner (lebt der noch?), (super)thec, (president)dma147, (gibtsdenüberhaupt)grid, masterstroke, (sir design)term, linga, tinysteini, darthpaul und alle anderen die sich angesprochen fühlen:

klärt mich auf, es reicht ja auch schon ein "Guten Morgen Junge, das sagen wir schon lange, Du hast nur geschlafen.."

so long..

Sig as a brick ┴┬┴┬┴┬┴┬┴┬┴┬┴
WW

wir unterscheiden erstmal w_ und e-polys. w-polys sind alle "festen" bestandteile der map, alles was im map format steht und nicht von externen quellen eingefügt wird. alle functions, blockentitys werden zu w-poly gezählt. einzig eingefügte objekte wie waffen, deco objekte und models werden zum e-poly count hinzugefügt. nehmen wir an du stellst ein 8-eckigen zylinder mit direktem bodenkontakt auf. das resultat wird bei einem normalen brush (nicht func_x) folgendes sein:
der boden wird an stellen der vertex knoten des unteren faces geschnitten. inwiefern dieser zerschnittene boden dann noch die eventuell darauf stehenden wände beeinflusst ist erstmal egal das kann ich ohne test nur vermuten.

Quellcode:8 (die seiten) +1 (oberfläche) + 8 für den zerschnittenen boden + x für die wände die eventuell in direktem kontakt zur bodenfläche stehen berechnet werden, der boden des zylinders wird nicht berechnet.
vorteil: das bodenface des zylinders wird in diesem fall nicht berechnet.

addet man den zylinder zu einer func_wall so wird jedes face des zylinders berechnet 8 (seiten) doch der boden und die restliche umgebung in keinem falle beeinflusst.

Quellcode:8 (seiten) +2 (oben/unten)

macht 10 faces vs. 17 faces. bei diesem beispiel dürfte der vorteil klar auf der hand liegen. man muss immer gut überlegen ob man func`s nutzt, wo und wie denn sie können einem nicht nur in sachen visblocking nachteile verschaffen. func_x sind w-polys sie werden jedoch quasi extern aus der map eingefügt, sind immer sichtbar? <-- vermutung jedenfalls ist dies der fall innerhalb des sichtbereiches (vis distance) was man sehen kann wenn man in den sky fliegt (vermutung). d.h. man sollte nur wenige, gut durchdachte objekte zu functions adden was man auch bei den meisten guten cs maps etc sehen kann.

zum testen ob und wie eine map von den umliegenden objekten oder functions beeinflusst wird empfehle ich den drawflat befehl der dir auch die grösse der patches verrät.

...Guten Morgen Junge, das sagen wir schon lange, Du hast nur geschlafen...

Statt r_drawflat (nur im Software-Mode) geht auch noch gl_wireframe 1 bzw. 2

Und das func_walls keine Schatten werfen kann ich auch langsam nicht mehr hören ... äääh ... lesen. Seit ZHLT 2.2 geht das! Ich versteh zugegebenermaßen nur nicht, warum die entsprechenden Einträge in den aktuell downloadbaren FGD's nicht enthalten sind.

Das einzige was mich ärgert ist, daß der Eintrag so doof und lang zu tippen ist (zhlt_lightflags) und ich mich in meiner Hektik andauernd vertippe und dann doch wieder keinen Schatten habe :(

Bei kleineren Objekten erhöht der Befehl sowieso nur unnötig die Rad-Compilezeit, den Schattenwurf sieht man meist eh nicht. Ich benutze es fast ausschließlich für Türen, besonders wenn man von Outdoor nach Indoor wechselt und den Lichtsaum unter der Tür wegkriegen will.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

Warewolf: Gute Ergebnisse bekommt man eigentlich nur mit einer ausgewogenen Mischung aus Entities und Brushs. Alle Objekte zu Entities zu machen bringt nicht weil bei func_walls immer alle seiten berechnet werden egal ob sichtbar oder nicht. Nur aus Brushs zu bauen führt besonders bei detaillierter Bauweise zu einen extremen Zerschneiden der Faces. Am besten ist es eigentlich die Grundstruktur aus Brushs zu bauen und dann Details aus Entities zu adden.

@Term AND Hessi: Es gibt das Light Flag auch in den neuen FGDs allerdings nur bei Func_illusionary.

mabbb

-=B.L.Ä.N.D.E.R=-

wahrscheinlich gibts den nicht in den fgds weil ZHLT ja keine offiziellen tools sind. oder?

Ein bisher noch nicht berücksichtigter Faktor ist auch noch die Belegung
der Brushes und Entities mit Texturen. Jedesmal wenn die Textur auf der
Brushoberfläche endet und neu beginnt, entsteht ein neues Polygon.
Ich führe Lingas Bleistift mal weiter:
8 (die seiten)mal X Wiederholungen der Textur +1 (oberfläche)mal X Wiederholungen der Textur + 8 für den zerschnittenen boden + x für die wände die eventuell in
direktem kontakt zur bodenfläche stehen berechnet werden, der boden des zylinders wird nicht
berechnet.
Da kommt schnell eine Menge zusammen, die r_speeds steigen ins unendliche :-]
Deshalb immer schön die Texturen scalen.

@linga
so inoffiziell sind die gar net
zoner@gearboxsoftware.com
die machen zwar nix dauerhaft für valve aber es könnten zumindest offizielle op4 tools sein

@McClane: das ist ein weit verbreiteter Irrtum. Check nochmal die r-speeds Artikel, da wird klar, daß die Regel "1 Textur = 1 Poly" nicht stimmt. Hab mich auch lange dagegen gesträubt, es ist aber wirklich so.

[ - Mindmotor.Studios - ]|[ - Poke646 - ]|[ - Spaceman - ]

Um an das 1 Textur = 1 Poly anzuknüpfen: Nein das stimmt nicht, und manchmal verhalten sich die Compiletools total verrückt was die Sache angeht. Ich glaub das Aufsplitten hat mehr was mit den Lightmaps zu tun als mit den Texturen, aber selbst dann kann ich's nicht richtig erklären.

cu,
Prefect

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

@perfect:
kurz bevor du auf die insel bist hatten wir ne disskusion darüber weisst du noch? wir waren stehen geblieben als es so schien das die aufteilung eines raumes in leafs auch etwas mit der splittung der brushes zu tun habe. in quake war 1 textur = 1 brush, halflife software modus nicht, openGL und d3d weiss man nicht glaube ich aber kaum. du hattest ne testmap sind aber nie fertig geworden könnten wir ja mal fortsetzen ist ne sache von 10 minuten...

hilfe!?!?!? ich blick überhaupt gar nix :( Ich bin erst seit 3 Wochen dabei :( ich glaub es gibt noch viel zu lernen für mich...

cya

dummdidumm :)

ALpha, lies einfach die Tutorials unter tut section auf der Hauptseite.
Besser noch:
Lies vorher die Hilfe datei von Worlcraft (wenns geht, die von version 2.1)
DAnn lies noch die Beiträge über r_speeds von Linga und Crid (bei den Quicklinks, wenn du hier bis nach ganz oben scrollst).

SO, DAS GILT FÜR ALLE NEULINGE ! ! !

Olof

Wee - o - wee - o - weeee

Hehehe,

ich beantworte mal die zweite Frage von Warewolf:

Du mußt deine Pix auf einem eigenen Webspace haben, will heißen, daß Du ein eigenes Account bei einem Provider benötigst. Dann muß dieser provider auch die Erlaubnis verteilen, das andere Server von diesem Webspace Dateien, also auch Bilder, runterladen dürfen.

Beim ICQ-Server ging's z.B. nicht, beim Tripod-Server dagegen doch.

Wenn Du deine Bilder auf dem Webspace hast, dann kannst Du sie mit den bekannten Befehlen auf die Seite einbinden.

Soviel dazu und Cú

K:R-I)Z++
"CSS ist cascading style sheets. Und nicht so'n Ranzspiel." - dp
In memory of Voice († 2005/03/30)