naja jedenfalls für die, die mit Zoner Half-Life Tools arbeiten, was wohl die meisten von euch tun.
Leider wird in in den r_speed-artikeln von crid und linga (nix gegen euch, war sicher ne menge arbeit) behauptet das func_walls bzw. alles ausser den Worldbrushes NICHT auf die r_speeds geht. Das ist leider falsch wie ich herausgefunden habe (jedenfalls für ZHLT)!
Also ich werkle an meiner map rum, hier ne vänderung, da n compile vorgang ggg, da stelle ich plötzlich fest, dass meine ansonstn schönen r_speeds total versaut sind, weil ich ein paar Prefabs in die map eingefügt habe (Bücherregale, mehr dazu gleich). Also denke ich mir, erstmal zu func_walls machen, vielleicht kannich sie ja so drinlassen und muss sie nicht löschen.
nächster compile vorgang - erstaunen, die r_speeds haben sich nicht verändert!
Um sicherzugehen habe ich nochmal in wc nachgeschaut obs vielleicht ein fehler war oder ob ich die func_walls nich richtig gemacht habe - negativ!
Da ZHLT in der Lage ist auch func_walls bzw. brushes mit entitys an der beleuchtung teilhaben zu lassen, transformiert es beim compilen diese entity-brushes in eine art ersatz-world-brush um, so das es von der HL-engine wie echte Worldbrushes gesehen wird (komisch das das noch nie jemand gemerkt hat) und somit die r_speeds belastet!
Aber hier beweispics:
einmal der raum ohne regale:

einmal der raum mit den regalen:

das pic wurde von ein und derselben stelle geschossen, wobei ich immer den geiselkopf anvisiert habe um genau die selbe stelle zu treffen!
Und auf der gesamten map gibt es keine veränderungen ausser eben diesen beiden Bücherregalen!
um zu beweisen das es sich hierbei NICHT um worldbrushes handelt, habe ich die regale in diesem Fall zu einem func_illusionary umgewandelt, hier das pic:

in diesem pic stehe ich deutlich zu erkennen IM regal
hier noch 2 pics von gegenständen die ebenfals keine worldbrushes sind, aber dennoch von rad beleuchtet wurden (->also in die r_speeds mit einfliessen)
das erste ein bürostuhl, bei dem man die beleuchtung unten gut erkennen kann:

der stuhl ist übrigens ein func_pushable
und dann noch ein pic von einer metallkiste die an eine func_wall gebunden ist:

axo, um sicherzustellen das die wände nicht möglicherweise "zerschnitten" werden von den gegenständen, habe ich selbstverständlich immer eine unit zwischen wand/boden und gegenstand freigelassen.
Puhh, langer text, hoffe das war nicht umsonst.
Tja dann sagt mal was, also die Artikel müssen auf jeden Fall für ZHLT geupdated werden!

"Kloetengott: Ich finde Leute die sich selbst zitieren echt armseelig!"

muuh
ich bin xtrme müde, aber soweit ich das sehe, hast du nichts herausgefunden, was andere nicht schon wüssten...
im gegenteil, du hast sogar einiges Falsch erklärt bzw gedeutet:
1. func_*** entities wurden schon seit urzeiten von der HL engine als worldbrushes angesehen, und daher auch bei den W_polys angezeigt. das hat mit den ZHLT nichts zu tun.

Zitat:

Da ZHLT in der Lage ist auch func_walls bzw. brushes mit entitys an der beleuchtung teilhaben zu lassen, transformiert es beim compilen diese entity-brushes in eine art ersatz-world-brush um, so das es von der HL-engine wie echte Worldbrushes gesehen wird (komisch das das noch nie jemand gemerkt hat) und somit die r_speeds belastet!

muuuh
also ZHLT ist in der lage funcs an der beleuchtung Teilhaben zu lassen. Aber das geht weißgott nicht automatisch, du musst ein KEY adden (hab ihn jetz leider nich im Kopf).
hmmm
Ersatz-world-brushes... nette These *lol*
sowas gibbets net...
und die HL-engine weiß auch, das es ein func_*** ist.

Zitat:

hier noch 2 pics von gegenständen die ebenfals keine worldbrushes sind, aber dennoch von rad beleuchtet wurden (->also in die r_speeds mit einfliessen)

muuuh
Seit ich denken kann werden func_*** (und auch so ziemlich alle anderen) entities beleuchtet...
Sie können nur keinen Schatten werfen, mehr nicht. Der key in ZHLT bewirkt, das die entities auch schatten werfen können, mehr nicht.
Das kann man einfach beweisen...
Map bauen, Func_wall reinsetzen, ungünstig beleuchten.

Zitat:

axo, um sicherzustellen das die wände nicht möglicherweise "zerschnitten" werden von den gegenständen, habe ich selbstverständlich immer eine unit zwischen wand/boden und gegenstand freigelassen.

Zitat:

Puhh, langer text, hoffe das war nicht umsonst.

Zitat:

Tja dann sagt mal was, also die Artikel müssen auf jeden für ZHLT geupdated werden!

Der Befehl heisst lightflags oder?

Ich bin auch müde, aber ausgerechnet heute muss Scream2 afaik uncut drankommen =)

Damocles

Die Hölle wird von jeder Generation in der Fantasie neu gestaltet. Ihr Gebiet wird nach Absurditäten abgesucht und in frischer Form neu erbaut; ihre Schrecken werden unter die Lupe genommen und, wenn nötig, neu erfunden, um dem jeweiligen neuen Klima der Grausamkeit gerecht zu werden; ihre Architektur wird abgewandelt, damit sie dem Auge der modernen Verdammten etwas zu bieten hat.

grummel, zumindest habbich damit recht das func_walls doch für die engine in bezug auf r_speeds relevant sind, und das steht ja in den Artikeln anders drin.
Also ist das halt für alle die es nicht wussten (und ich wusste es nicht, eben weil ich davon ausgegangen bin, das die aritkel stimmen).
Und das es wahrscheinlich für ZHLT gilt habbich aus dem grund geschrieben weil ich es für die standart-tools nicht genau weiss (und kein bock habe den ganzen mist nochmal mit den standart-tools zu versuchen).
Abba das mit dem befehl für beleuchtete entitys is einfacher als du sagst:
ich hab einfach immer im extra-modus ge"rad"et, damits besser aussieht!
Das entitys nix zerschneiden weiss ich, hab ja auch "um sicherzustellen" geschrieben, um zweifler gleich im keim zu ersticken (doofe wortwahl), die meinen "ähhh dein zeugs zerschneidet bestimmt die räume, deshalb die r_speeds".
Da immer wieder Fragen zu r_speeds kommen, und newbies auf die artikel verwiesen werden, war dieser thread wohl keineswegs umsonst.
muhhh

grrrr werden die pics nun gezeigt oder nicht?
einmal sehe ich sie, einmal nich...

"Kloetengott: Ich finde Leute die sich selbst zitieren echt armseelig!"

was meinst du mit

Zitat:

beleuchtet

(none)

zur Erklärung...
Im R-speeds-Artikel steht das func-walls die R-speeds positv beeinflussen können, das stimmt weil sie nicht in die Leafberechnung mit einbezogen werden und dadurch weniger faces aufgeteilt werden. Es lohnt natürlich nicht eine völlig gerade Wand zu einen Func_wall zu machen, bei komplizierten Strukturen die die Leafaufteilung unnötig komplizieren würden ist es aber besser eine Func_wall zu verwenden...
Der R_speeds artikel ist schon richtig Klötengott

*kopfschüttel*

Vielleicht ändert Crid/linga? den Artikel mal und schreibt ausdrücklich rein das func_walls als w-polys zählen...

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

also ich denke ich habe in meinem artikel (ich gehe von den aktuellen versionen auf meiner page aus, die auf thewall ist afaik nicht aktuell) nicht besonders gut klar gemacht, dass getracete func_#### solids komplett berechnet werden. also es werden nicht sichtbare faces berechnet und zb. wenn 2 aneinanderliegen wird dieser nahtface nicht gekillt. es werden also immer alle faces berechnet was an einigen stellen natürlich weitaus höhere r_speeds schaffen kann als wenn ein normaler w_solid seine nachbarn splittet.
demnächst werden ich so oder so den artikel auf den neusten stand bringen denn auch die aussage solids würden immer im 224x224 grosse patches gesplittet werden bezweifle ich inzwischen denn wie ich rausfand hat auch die aufteilung in leafs eine auswirkung auf die aufteilung in patches. wo jedoch dort der zusammenhang steht weiss ich bisher nicht. ausserdem will ich einen grösseren hint brush teil hinzufügen und insgesammt func_wall als alternative etwas zurücknehmen da man sich damit des öfteren ins bein schiesst.

@mabb: ich denke das habe zumindest ich klar und deutlich gemacht allerdings sollte man wirklich noch hinzufügen, dass auch func_solids "feste bestandteile einer map" sind.

@Klötengott: natürlich sind func_### für die engine relevant! das gegenteil hat niemand behauptet denn func_### sind ja schliesslich auch polygone. func_### haben den vorteil das sie erst im nachhinnein eingefügt werden, sie werden beim normalen compileprozess nicht einbezogen wenn man das so sagen kann. ich vergleiche sie mal mit einem model was durch einen level läuft. ein model splittet auch nicht bei jedem schritt was es tut den untergrund auf dem es steht oa. func_### sind zwar keine externen objekte aber aus verschiedenen gründen können sie nicht in den normalen compileprozess einbezogen werden und daher splitten sie ihre umliegenden solids nicht.

...es kann natürlich sein, daß Klötengott eine veraltete Version von meinem r_speeds-Artikel auf der Festplatte hat. Ich hatte in der Tat damals behauptet, func_walls würden nicht zu den w_polys beitragen, sondern zu den e_polys. Das war natürlich FALSCH! Das habe ich aber schon vor Monaten ausgebessert.

Also nochmal für alle: func_walls zählen zu den w_polys!!

Und nochwas zu Klötengott: Du schreibst, daß Brushes "von rad beleuchtet wurden ->also in die r_speeds mit einfliessen"...

Das ist so nicht richtig. VIS berechnet die Map bezüglich der r_speeds, nicht RAD. OK, im Artikel steht auch, daß RAD die r_speeds beeinflussen würde, aber das ist nicht so ganz geklärt, warum überhaupt. Und wenn RAD die r_speeds überhaupt beeinflußt, dann nur in einer sehr geringen Weise. Aber vielleicht sollte ich diesen Satz aus dem Artikel löschen, damit da keine Mißverständnisse auftreten.

Was den lightflags-key angeht: ich bin mir sicher, daß der ausschließlich von RAD berücksichtigt wird. Und die Aufsplittung/Zerschneidung der Brushes, sowie die Aufteilung der Map in leafs ist nach qbsp/hlbsp bereits abgeschlossen. Die r_speeds der Map stehen dann nach VIS schon fest. Insofern KANN der lightflags-key die r_speeds gar nicht mehr beeinflussen, da RAD ja erst ganz am Ende des Kompiliervorganges läuft.

crid

Könnte nicht immer in den News gepostet werden, wenns ne neue Version gibt, weil bis vor ein paar Monaten hab ich auch noch gesagt und gedacht, funcs würden zu e_polys zählen (nach crids altem Artikel), bis ich dann aus Langeweile mal wieder alle Artikel und Tutorials auf ThW durchgelesen hab, und siehe da, man lernt nie aus =)

Damocles

Die Hölle wird von jeder Generation in der Fantasie neu gestaltet. Ihr Gebiet wird nach Absurditäten abgesucht und in frischer Form neu erbaut; ihre Schrecken werden unter die Lupe genommen und, wenn nötig, neu erfunden, um dem jeweiligen neuen Klima der Grausamkeit gerecht zu werden; ihre Architektur wird abgewandelt, damit sie dem Auge der modernen Verdammten etwas zu bieten hat.

@crid: ich denke RAD beeinflusst die r_speeds einer map indirekt. wie term feststellte hängt die auflösung der lightmap vom scaling der texturen ab. ich weiss nicht wie die lightmap in der hl engine aussieht aber afaik sollte es eine grosse map sein mit einer statischen auflösung sonst bräuchte man ja für jedes patch eine eigene lightmap obwohl zweiteres wohl sogar von seiten der performance her besser ist. wenn die lightmap also von patch zu patch eine andere ist stimmt term aussage denn dann kann man einen klaren unterschied zwischen einer textur die 0.50 und einer tesxtur die 50.0 gescaled ist erkennen (wer macht schnell die testmap? =) also ernsthaft wer das vor hat braucht bloss 2 bodenplatten und einen jeweiligen "schattenspender" darüber (geometrisch nicht zu öde man soll ja klare unterschiede erkennen. also schräge balken oa.), eine trennwand und 2 point_lights. somit wäre dann sicher gestellt das lightmap und das scaling der texturen indirekt verbunden ist und somit kann man nichtmehr ausschliessen, dass auch RAD die r_speeds beeinflusst.

So hab kurz ne Testmap gemacht.
Also auf dem ersten Bild ist die Textur auf 0.2 heruntergescalt und auf dem zweiten ist sie auf 3 hochgescalt( hatte sie erst auf 50 aber dann gabs gar keine richtigen Schatten mehr)
Aber der Unterschied ist auch so schon deutlich genug!
Desweiteren ist mir neulich aufgefallen, dass wenn man 2 nebeneinanderliegende Bodenplatten hat und man auf der einen die Textur ein wenig verschoben hat, dann sieht man das auch an den Schatten

danke für die testmap kingkrauss. bleibt die frage wo nun shadowmap und r_speeds zusammenhängen, warum die r_speeds unter RAD manipuliert werden. nehmen wir an die verschiedenen lightmaps, die auf den patches liegen, sind von der auflösung her alle gleich doch sie werden immer auf die grösse des dazugehöhrigen patchres gescaled. dadurch würden sich die krassen auflösungsunterschiede erklären. doch dann gäbe es keine veränderung der r_speeds. 2. theorie wäre, dass eine lightmap eine max. auflösung hat (so wie patches afaik 244x224) dann würde die lightmap ein zu grosses patch wohl aufteilen wie es eine >244x244 textur auch machen würde. also braucht man wieder eine testmap die mit drawflat getestet wird.
wir bräuchten da mal jemanden der eine simple bsp mit den nötigsten lichtern, solids etc. auslesen könnte den das als mapper zu testen ist weitaus komplizierter. ich weiss ehrlich gesagt ganicht so recht wie man das überhaupt testen soll denn wie sollen wir patches die durch eine texturwiederhohlung entstanden sind (oder den standartwert 244x244) von denen, die von der lightmap entstanden sind unterscheiden? wir können uns afaik im drawflat keine ausmasse anzeigen lassen also müsste man in die map noch eine art lineal in form eines solids einbauen. dies hat dann eine bestimmte länge und demnach muss man die texturen auf x&y anpassen +scalen damit man klar unterscheiden kann was lightmap und was textur ist. kann man eine map durch rad jagen die keine lichtquelle hat? dann bräuchte man eine map ohne lichtquelle die wie folgt aussieht:

die textur auf unserem testpatch muss genau auf x und y passen damit die patches genau passen (die lineale sind dann zum überprüfen in der engine) die umliegenden patches sind zu vernachlässigen.
nun muss man mal raus finden, wenn es denn so ist, was die max. grösse eines lightmap sektors ist und man muss dann den testspatch via. texturscaling grösser machen als die max. x,y grösse eines lightmapsektors. bleibt das patch dann so gross wie die lineale sind also eins (vorgegeben von der textur) sind wir immernoch nicht weiter. ist unser testpatch jedoch entgegen der bestimmungen der darauf liegenden textur gesplittet worden muss ein patch gesplittet werden sobald man die max. grösse eines lightmapsektors erreicht hat und darin liegt dann die lösung.

@gumble: wieso liest keiner richtig??
ich weiss das func_*** keine worldbrushes zerschneiden, habe das mit der unit-abstand nur dazu geschrieben damit ich solche kommentare von leuten die das nicht wissen gleich zuvorkomme!

zu RAD und dem zusammenhang mit den r_speeds: das hat auch keiner richtig gelesen:
"hier noch 2 pics von gegenständen die ebenfals keine worldbrushes sind, aber dennoch von rad beleuchtet wurden (->also in die r_speeds mit einfliessen)"
damit wollte ich verdeutlichen das RAD nur dinge beleuchtet die von vis mitgerechnet wurden. Also wenn irgendetwas beleuchtet werden kann, muss es auchg in die r_speeds mit einfliessen!
hmm vielleicht hätte ich den Thread lassen sollen, schon wird man unwissender verschrien...

"Kloetengott: Ich finde Leute die sich selbst zitieren echt armseelig!"

Also ich hab das jetzt mal getestet. Also wenn man die Textur genau so groß macht wie der Brush dann ist da 1 riesiger Patch.

hm shit dann ist meine 2. theorie erstmal falsch. entweder das max. der lightmap sektoren ist >1500x1500 (so gross war kingkrauss test-solid) oder es gibt garkeins was aber nicht sein kann da die lightmap ja je nach texturscaling unterschiedlich aufgelöst ist. also werden die lightmap sektoren entweder mitgescaled aber das hätte dann keinerlei einfluss auf die r_speeds oder das max liegt oberhalb von 1500x1500.
ich hätte eigendlich erwartet, dass dieses eine patch nun durch den einfluss der lightmap nach dem unbekannten max. wert gesplittet wird. doch das ist ja nicht der fall.

@Klötengott: es geht doch garnichtmehr um deinen post. erstens funzen die bilder nicht und ausserdem ist das doch schon beantwortet oder?

wenn man die url zu den bildern eintippt, sind sie da, und das es bilder sind die angezeigt werden sollen sieht man ja, komisch, versteh ich nich.
Naja wenn ihr die Bilder noch sehen wollt:
http://www.geocities.com/nbl_fileserver/Kloeti/

"Kloetengott: Ich finde Leute die sich selbst zitieren echt armseelig!"

also kingkrauss hat eine 2. map gemacht wobei das scaling des testbrushes nun 3000x3000 beträgt.

nun hier sind 2 triangles (polygone) zu sehen. patches sind jedoch ein zusammenschluss aus jeweils 2 polys also sollte der befehl keine polys zeichnen. wieso dieses patch jetzt plötzlich in die 2 polys getrennt wird ist mir absolut unerklärlich. wie man sieht macht er das bei kleineren flächen nicht und patches sind nunmal so oder so keine polygone. ich weiss erstmal nichtmehr weiter.

tja, wir haben grade schonmal im chat darüber gesprochen, aber ich hab selbiges mit einem 8000x8000 gescalleten brush gemacht.
dort war es merkwürdigerweise wieder ein patch.
[18:55] <microschrott> ewige mysterien der hl engine und ihres compilers
[18:55] <linga> allerdings
.

Noch was komisches...hier hab ich die Texturen auf genau ¼ der Größe des Brushes gescalt, aber die Patches werden ganz anderes gesplitet!

kingkraus, genau das ist mir auch aufgefallen. ich habe die textur auf 1/2 der brushgröße gescalled, und es blieb bei dem einen patch. also genau die selbe aufteilung wie bei gleicher größe.
ps: mehrere lichtquellen haben anscheinend keinen einfluss darauf, auch wenn die textur genau so groß ist wie der brush (oder hatten wir das schon?)
akte X TheWall mysteriöse mappingfälle und spannende aufschlüsselung der hl engine
*nachschlag*
hier ein screenshot, darin schatten eines brushes

wenn ich das richtig sehe, zerteilt der schatten die brushes, nicht aber die lichtquelle selber (auch nicht verschiedene) also scheint schatten einen größeren einfluss auf die r_speeds zu haben

Pfff... echt seltsam.

Ich hab hier zwar die sources von qrad rumfliegen, aber das ist echt kompliziert, da kann man nicht mal so eben nachgucken :-(

Vielleicht kann Prefect weiterhelfen, der weiß schließlich alles. Naja, fast alles ;-) *nachprefectruf* Is der überhaupt da?

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

Also ich hab mir grad die Map, mit der ich oben die Schattenschärfe demonstriert habe mal mit drawflat im Softwaremodus angesehen und da hatten die Schatten überhaupt keinen Einfluss darauf, wie die Patches am Boden zerschnitten wurden

pfff... eigentlich auch viel logischer, den rad läuft ja erst ganz am ende.
aber der screen da oben ist 100% nicht gefaked, warum sollte ich auch.
ich lad mal kurz die .bps hoch, so in 5 min is er da
http://krasser.shit.de/weltkraft/patch.bsp
es ist eindeutig zu sehen das die patches hier vom schatten beeinflusst werden.

Kannst du bitte auch mal die *.map hochladen?