laut crids artikel werden brushes standartmässig bei 224x224 units geteilt. scalt man die textur grösser als 224x224 wird der brush individuell jenach grösse der gescalen textur gesplittet =>scalt man eine textur auf 400x400 wird der "darunter" liegende brush erst nach 400 units xyz gesplittet.
ich habe mir nen kopp gemacht warum gerade nach 224 units? und bin zum schluss gekommen, dass das eigendlich nicht sein kann.

meine überlegung:
die brushes in hl werden nach JEDER texturwiederhohlung gesplittet. das muss sein, da der software renderer nicht 2 texturen auf einem brush berechnen kann.(das ist fakt) legt man also eine textur mit 10x10 units auf einen grossen brush produziert man massen an polys, da der brush nun in lauter 10x10 units blöcke geteilt wird. in wiefern meine vermutung stimmt müsst ihr rausfinden. kann bitte jemand eine testmap bauen? einfache eine wand und eine sehr kleine textur darauf legen. daneben noch eine wand mit einer anderen textur, welche genau auf 224x224 gescalt ist, damit man den unterschied sieht. danndie map im softwaremodus starten und mit dem befehl /drawflat 1 die brush zerteilung sichtbar machen. davon einen screenshot. vorher muss aud sv_cheats 1 geschaltet werden.
nach meiner vermutung würde man deutlich sehen, einmal das völlig ausgefüllte, einfarbige solid(224x224) und einmal den in lauter bunte würfel unterteilte würfel mit der kleinen textur.

nach crids artikel wären beide brushes völlig gleich, beide würden bei 224x224 gesplittet, also auf der testmap nicht zu sehen (einfarbig)
ps: ich hab im mom keine compiler/wc drauf, desshalb bitte ich einen von euch diese testmap zu erstellen, ist ja kein akt...

@alle testmap bauer, perfect is schon dabei eine zu bauen, ihr müsst keine mehr bauen, danke!

grrrr

http://www.levelediting.de
"Ich weiß nicht, welche Waffen im nächsten Krieg zur Anwendung kommen, wohl aber, welche im übernächsten: Pfeil und Bogen." (Albert Einstein)

Also, ich hab ne Testmap gemacht, hier gibt's jetzt gleich mal ein Screenshot mit r_drawflat 1.

<img src="http://www.valveworld.com/repulse/shots/splittest0000.jpg" border="0">

Der (einzige) Raum dieser Map ist 224x224x224 groß, eine Ecke des Raums ist auf (0,0,0). Die Textur, die ich verwendet habe ist eigentlich 128x128. Auf der rechten Wand ist sie auf 1/4 reduziert (also 32x32), auf der linken Wand ist nur die Y-Achse auf 1/4 reduziert. Auf den anderen Wänden ist die Textur auf 7/4 erhöht, so daß sie also genau 224x224 groß sein sollte.

cu,
Prefect

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

Jetzt kommt bloß ein leicht verrücktes Ergebnis raus: Eigentlich sollte die rechte Wand ja in 7x7 Felder unterteil werden (224 / 32 = 7). Trotzdem sind es nur 4x4!! Das bringt nun wieder gar keinen Sinn, denn d.h. die Wand wird alle 56 Einheiten unterteilt, also alle 7/4 Texturlängen.

Das heißt wohl, das sowohl der Software als auch Hardwarerenderer sehr wohl eine Textur doppelt innerhalb eines Polygons rendern können. Trotzdem teilen die Compiletools seltsamerweise die Wand auf.. d.h. entweder können mehrfache Texturen pro Polygon einfach nicht so gut verarbeitet werden (aber es ist möglich), oder das dient dazu den VISing-Prozess zu optimieren -> mehr Leafs, mehr Möglichkeiten, Polygonteile wegzulassen. Auf der anderen Seite wird dadurch zwar die Anzahl an Pixeln, die gezeichnet werden reduziert (Fillrate muß nicht so hoch sein), andererseits wird aber mehr Rechenzeit benötigt um die Koordinaten von 3D auf 2D umzurechnen. Vielleicht ist das so wie wir's hier finden einfach ein Mittelwert, der sich als besonders gut herausgestellt hat...
Ein weiterer Ansatz könnte die durchschnittliche Leafgröße gewesen sein. Extrem kleine Leafs bringen für die VIS-Berechnung einfach keinen Sinn...

cu,
Prefect

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

man kann mit ZHLT die genauigkeit von vis beeinflussen/die grösse der einzelnen leafs indirekt manipulieren. sagt man ZHLT er soll genauere/kleinere oder auch grössere leafs berechnen, müsste also die wand nicht in 56x56 gesplittet werden sondern individuell nach grösse der leafs?
der command lautet ******kA sorry:) schau in die ZHLT readme

Hmm.. laut Dokumentation gibt's zwei Kommandozeilenoptionen, -subdive und -maxnodesize. Aber irgendwie hatten beide keinen sichtbaren Einfluß auf die Karte, weder bei hohen noch bei niedrigen Werten (außer das -subdivide bei zu großen Werten hlrad zum Absturz bringt...). Trotzdem komisch, weil laut Dokumentation sind diese Werte ja eben dafür da, die Leafgrößen zu kontrollieren. Vielleicht wirkt sich das nur bei größeren/komplexeren Maps aus?

cu,
Prefect

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

nja, ich denke da werden nicht grossartig leafs angeordnet, wozu?
es mus eh immer alles berechnet werden. von daher wäre eine leafunterteilung unsinnig. stell eine einfache säule in die mitte. damit hätten wir gewissheit über die parameter. denn nun müssen 100%tig leafs angeordnet werden.(darf keine function sein. <-zur verständnis anderer leser. an functions werden keine neuen leafs gelegt, da diese vom compiler unbeachtet bleiben.)

Ich komm jetzt leider nicht mehr dazu, das zu machen (zuviel zu tun mit Reisevorbereitungen und so).

Und wenn ich mir so die Postingbeteiligung in diesem Thread anschaue wird mir doch etwas mulmig. Hat denn niemand was dazu beizutragen? Sonst ist der arme linga ganz alleine wenn ich weg bin ;)

cu,
Prefect

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

bisschen arg hoher stoff für mich,
aber um den Linga kümmern ich mich schon. =)
Wo fährst du denn hin Prefect ?

Ich kann mal gucken ob ich das machen kann aber da müsste ich erst ein bisschen was installieren (wie linga)...

Tja ich habe vorerst keine Lust mehr da ich probs bei wc hatte, aber als ich eben prefects map gebaut hatte, wurden bei mir die texturen 4x4 gesplittet, jedoch ein split hatte ein seitenverhältnis von 3 zu 4 was heissen würde das es insgesamt nicht 224x224 sind aber egal ich teste das vielleicht dann nochmal.

Und so sieht das im r_speeds Artikel aus:

>>Texturen vergrößern. Obwohl ich keine logische Erklärung dafür geben kann, warum dies die r_speeds beeinflußt, empfehle ich, auf großen Flächen die Texturen (probeweise) zu vergrößern. Es gibt viele Texturen, die dies ohne große optische Einbußen vertragen, z.B. Felsen- oder Geländetexturen. Auch an Stellen der Map, die der Spieler nie zu Gesicht bekommt, bietet sich diese Methode an (Dachflächen etc.) Man kann Texturen bis auf die 999-fache Originalgröße skalieren. Es gibt keine Garantie dafür, daß man mit dieser Methode Polygone einspart, aber an manchen Stellen kann man doch erstaunliche Resultate erzielen. Bei großen Maps kann man sich dadurch außerdem patches "erkaufen" (vgl. MAX_PATCHES-Error). Dies jedoch nur am Rande.

ich will ja nicht mit den grossen mitreden aber...was solls.

@Linga bist du dir sicher das der software renderer nur 2 Texturen aufs mal rendern kann?? wie soll das denn mit den "{"- Texturen gehn(diese die man auf eine andere Textur draufkleben kann)?? die werden auch nicht auf einen eigenen brush gemacht(hab ich selbst getestet:))!!

gute nacht noch
cu

@phantom, was hat das damit zu tun? die stellen wäre eher:
"1.Schritt:

Zunächst wird jede einzelne Brushoberfläche in Einheiten von 224x224 Units "zerschnitten", ausgehend von der jeweiligen linken oberen Ecke der Fläche. "Links oben" bedeutet bei den waagerechten Flächen in der Draufsicht "Nordwest", bei den senkrechten Bauteilen gilt "Links oben" jeweils bei Blickrichtung nach "Westen" bzw. "Norden"."

und
"3. Schritt:

Nun "versuchen" die Kompiler, wo es geht Einzelflächen wieder zu größeren zusammenhängenden Flächen (max. 224x224) zu verschmelzen. Dies geschieht jedoch in der Regel nur mit rechteckigen Flächen und dann auch nur mit oft zweifelhaftem Erfolg."

wobei das mit dem "(max. 224x224)" eh nicht stimmt, wir haben rausgefunden, dass man durch texturen scalen die splittung beeinflussen kann. darum gehts hier aber weniger

NoFL, doch, für decals werden soweit ich weiss eigene polys erstellt.
auf jeden fall in q3, da hab ichs selbst schon gesehen, bei hl kann man das nur schwer prüfen, da der wichtige befehl drawoder nicht in die engine implentiert wurde.

@ Linga
Es ist so. Wenn man in Worldcraft ein Decal an die Wand 'spritzt', dann sieht man schön, wie eine art entity dort hinkommt (sieht im 3D fenster so aus).

...denn das atombrot wird nicht ruhen bis es den letzten erwischt hat...

@ Linga: Doch, den Befehl gibt's! Allerdings geht der nur im Software Modus. Und er heißt r_draworder 1

Aus der Tatsache, dass eine Art Entity erstellt wird, kann man natürlich schließen, dass ein Decal eine Art func_wall ist. Ist aber nur eine - zugegeben sehr aus der Luft gegriffene - Vermutung.

TheTinySteini
Coder Poke646
"Don't Panic" - Hitchhiker's Guide to the Galaxy