jup, moment.
http://krasser.shit.de/weltkraft/patch.map
etwas anders noch: von dieser patchaufteilung scheint irgendwie nur der schatten durch 1 licht merkbar zu sein, die beiden anderen die daneben liegen müssten auf der anderen seite durch ihren schattenwurf eigentlich ebenfalls brushs zerteilen, was sie aber nicht tun. aber warum sollte ein 256 units über dem boden liegender brush den darunterliegenden zerschneiden? vielleicht sollte man echt mal zoner fragen.
*edit*
wir sollten vielleicht mal nen plan aufstellen, ne todo liste und ein ziel.
so suchen wir nach etwas das wir nicht wissen und kommen nie zu einem ergebniss.

Ich war über Ostern leider gezwungenermaßen dem Computer fern, da ich intelligenterweise gerade am Samstag Wasser über meine Tastatur geschüttet habe... nunja. Ich werde mir später mal die schönen Quellcodes von HLRAD anschauen, aber vorher noch ein paar Sachen vorneweg:
- RAD dürfte die r_speeds selbst eigentlich nicht beeinflussen. Aus mehreren Gesichtspunkten wäre das Quatsch, da dabei Faces nicht verschoben werden dürften, höchstens noch weiter zersplittet, und das kann keinen Sinn geben, da minimale Vorteile durch Patchverteilung sofort wieder durch die größere Anzahl wpolys aufgehoben werden würde. Faces/Facetrennungen zu verschieben oder zusammenzuführen ist unmöglich, da dadurch die Ergebnisse des VIS-Vorgangs gefälscht werden würden.
- Es ist anscheinend tatsächlich so, dass eine nicht geRADete Map in der Engine langsamer läuft als eine geRADete. Warum das so ist wird allerdings, fürchte ich, ein Geheimnis bleiben bis wir irgendwann einmal einen Blick auf die Innereien der HL-Engine werfen können. Dafür gibt es eigentlich keine logische Erklärung außer der, dass der Renderingvorgang mit Multitexturing (Lightmaps) besser optimiert ist als ohne...

Ok.. wieder ein bißchen schlauer, allerdings ist der HLRAD-Code der absolute Hammer, um sicher zu gehen müßte ich den komplett verstehen und das ist mir im Moment zu komplex. Auf jeden Fall sieht es nun so aus, als würden Faces nicht gesplittet werden, Patches aber schon. Diese Funktion kann mit der Kommandozeilenoption -nosubdivide deaktiviert werden, ob das ne gute Idee ist weiß ich nicht.
Um zu bestimmen, ob ein Patch subdivided werden soll, berechnet HLRAD zunächst die Min/Max-Koordinaten des Patches im Raum, so daß praktisch der kleinste achsenparallele Quader entsteht, der den Patch komplett erhält. Dann wird die Länge dessen Diagonale berechnet. Ist dieser Wert größer als der -chop oder -texchop-Wert (wann welcher genommen wird hab ich nicht ganz verstanden), dann wird der Patch weiter unterteilt, es sei denn seine Fläche ist kleiner eine Quadratunit (dann gibt's außerdem ne Meldung in die Developerlevel-Logs).
Gesplittet wird der Patch dann an Hand der Texturachsen, für die Chopabschnitte (als die Größe der resultierenden Patches) wird der -chop bzw. -texchop-Wert mit der Scalevalue der Textur multipliziert.

Es ist etwas seltsam - ich bin mir zwar ziemlich sicher, dass Faces nicht mehr gesplittet werden, aber Patches schon, was ja eigentlich in der Engine zum Schluß aufs selbe rausgehen würde. Kann vielleicht jemand beim Kompiliervorgang einer größeren Karte die Statistik über den Inhalt der BSP-Datei hier reinpasten für den Vergleich FACES vs. PATCHES?

cu,
Prefect

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

ich hab den thread erst jetzt grad gesehen...

unabhängig davon hatte ich vorhin in der zhlt rumgestöbert, aus lange weile und habe dann mal mit -chop rumgespielt. im doc heisst es zunächst.

Zitat:

Set radiosity patch size for normal textures
Each face in the world has a grid projected onto it, and chopped up into a rather coarse set of sample points. These points are patches, and are what hlrad uses to do the bounced lighting calculations. A higher chop sacrifices quality for both speed and memory consumption of hlrad. A lower chop increases the quality at the expense of speed and memory usage.

daraufhin hab ich mal eine kleine testfläche kompiliert , mit chop 16 was zu einer vismatrix von > 90 mb geführt hat (ich hab dann auch abgebrochen weil er bei BuildVisLeafs dann nicht mehr weitergekommen ist und die ganze zeit geswapt hat (128mb)). aber alleine wegen dem relativ kleinen raum und der langen berechnungszeit (habs dann mit -chop 32 nochmal laufen lassen, > 15min) sollte man darüber mal nachdenken. man achte auf das verhältnis patches/faces:

Zitat:

325 faces
Create Patches : 39540 base patches
0 opaque faces
67072 square feet [9658368.00 square inches]
1 direct lights

BuildFacelights:
(109.36 seconds)
visibility matrix : 93.2 megs
BuildVisLeafs: (hier hab ich gecancelt)

ich muss dazu sagen das ich jetzt den thread nicht komplett gelesen hab, aber ich wollt das mal eben ,,einwerfen" weil ich vorhin das mit dem chop getestet hab.

was ich grad noch im doc gefunden hab:

Zitat:

-notexscale # Do not scale radiosity patches with texture scale
By default, hlrad will take the texture scale and apply it to the chopping grid which is projected onto it. This option turns that off, and almost always increases the number of patches in a map as most maps have many walls scaled up to 2 and 3.

vielleicht kann einer mal kingkraus' map mit der einstellung compilen?

*schwapp*
mein herlichen dank das du dich darum gekümmert hast prefect.
jetzt weis ich wenigstens das rad zugriff auf die patches hat.
für mich ist die frage immer noch in dem sinn dieser splittung, was hat es für einen sinn wenn lichtqellen patches splitten?
das mit der karte werd ich ausprobieren, ich hab grade ne etwas komplexere da. allerdings weis ich nicht ob es da einen unterschied zwischen lights und texlights gibt, könntest du das nochmal nachschauen?
nungut...map getestet, chop = 8

8952 faces
Create Patches : Error: Exceeded MAX_PATCHES
*no comment*

chop = 128 (krasser unterschied ich weis)

8952 faces
Create Patches : 17181 base patches
87 opaque faces
249707 square feet [35957820.00 square inches]

nundenn, mit normalem chopwert, also ohne ne angabe sind es 31309 patches.

das gibt wieder zum nachdenken auf.

Also ich glaube nicht, dass lichtquellen patches splitten !!!
Da in hlvis (hoffe ich irre mich nicht) doch die portals und leafs festgelgt werden und wenn dann beim lightning nochmal ein patch zerschnitten wird, dann stimmt doch die portal und leaf Berechnung nicht mehr !?

Aber ich habe mal gehört, dass die Zooner Tools die Map beim compilen von oben sehen und einige Erfahrungen haben das schon bestätigt !!
Bei deinem Schatten-Pic, microschrott, würde ich sagen, dass die patch und leaf-bildung so abgelaufen ist, dass eben der Bereich unter dem Schattenspender ein neues leaf ist, wodurch der Boden zerschnitten ist !

Aber versuche doch mal für den Schattenspender ein func_wall mit light_flags einzusetzen, dann müsste es auch einen Schatten geben und du kannst gucken, ob sich der Boden wieder gesplittet hat !

Das was ich hier verzapft habe, entspricht den Sachen, die ich gelesen und durch Tests gelernt habe ! Ich hoffe mal ein Teil davon stimmt, weil alles eben nur Vermutung ist !!!