Hi!

Ich habe mir mal wieder crid's r_speeds-Artikel durchgelesen und auf ein paar kleinere und eine größere gestoßen, die es zu bedenken gilt.

Ich fang mal mit dem unbedeutendsten an: Die Polygone auf Brush-Entitys zählen zu den wpolys und nicht epolys.

Zweitens hat sich das mit den Dreiecken seit Quake geändert, will sagen: World-Polygone können sehr wohl Vierecke & mehr sein. Dafür spricht
1) die Skybox nimmt nur 6wpolys in Anspruch
2) r_drawflat 1
3) gl_log; ich war tatsächlich mal so verrückt die Logfile für den GL-Render erzeugen zu lassen (15MB nach 2 minuten :)) Daraus lies sich herauslesen, das HL durchaus Vierecke und Triangle-Fans (Vielecke) an den Renderer schickt.

3) Vising und Leaf-Creation; ich beziehe mich jetzt voll und ganz auf Abb 9b aus dem r_speeds-Artikel

Angenommen QBSP2 würde auf die Idee kommen, das Level zuerst an der "oberen" Begrenzung des unteren Raumes zu splitten, wäre das Level in folgende Leafs unterteilt:
1) die untere Hälfte des unteren Raumes (bis zum Anfang des Visblocking-Ganges)
2) die obere Hälfte des unteren Raumes + der untere Teil des Visblocking-Ganges
3) der obere Raum
4) der Rest des Visblocking-Ganges

VIS würde jetzt feststellen, das man von 2) in 3) sehen kann => wer in der linken oberen Ecke des unteren Raumes steht, kann den ganzen oberen Raum "sehen".
Das ist der Moment wo Hint-Brushes ins Spiel kommen. Würde man nämlich eine Hintbrush an das untere Ende des Ganges legen, so würde QBSP2 das Level zuerst dort aufsplitten (Hint-Brushes haben nach den Dimensionalcuts (1024x1024x8192) die höchste Priorität vor Brushes entlang den Achsen), und die Leafs wären garantiert so wie in der Abbildung (ok, die Leafs im Gang könnten evtl. anders verteilt werden, aber das macht dann keinen Unterschied mehr).

Ich hoffe ich hab das jetzt einigermaßen verständlich erklärt und zu der Hint-Brush-Theorie etwas hinzufügen können.

cu,
Prefect

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

Hi Prefect,

........wo Du recht hast hast Du recht: die Polygone auf brush-basierenden Entities zählen in der Tat zu den wpolys. Ich hab' das kürzlich auch festgestellt, aber immer noch nicht im Artikel verbessert (Schande über mich).

Dreiecke:
Ich glaube, daß immer noch Dreiecke die Grundlage der ganzen Engine sind. Dafür spricht, daß z.B. quadratische Flächen immer mit mindestens 2 zu den polys beitragen --> wenn die Engine Vielecke verarbeiten kann, wieso dann nicht in einem solchen Fall (man könnte mit einer auf Vierecken basierenden Berechnung die r_speeds mal eben nahezu halbieren, würde aber sehr wahrscheinlich durch Rundungsfehler bei der Koordinatenberechnung für die Vertices dieser Vierecke sehr oft gewölbte Flächen erhalten --> welche 3D-Engine verträgt das?)?
r_drawflat sah in Quake genauso aus, wie jetzt ih HL. Leider hat Valve den gl_showtris-Befehl aus der Quake-Engine nicht in HL belassen, sonst könnte man sich auch jetzt die "wahren" Polygone (Dreiecke) anzeigen lassen (die Farbflächen bei r_drawflat zeigen nur die Texturflächen, jedoch nicht die Polygone, so wie sie die Engine sieht.
Was den sky angeht, so glaube ich, daß der von der Engine als Sonderfall behandelt wird, da hierbei ja keinerlei geometrische Daten (perspektivische Verzerrungen etc.) berechnet werden müssen, sondern lediglich, welche Stellen des Sky's grade verdeckt sind, und welche sichtbar.
Im allgemeinen stelle ich mir vor, daß es einen immensen Programmieraufwand dargestellt hätte, die auf Dreiecken basierende Quake-Engine so umzuschreiben daß auch Vielecke verarbeitet werden können. Da hätte Valve gleich eine komplett neue Engine programmieren können, oder?

Was allerdings das Render-Log angeht, so bin ich dann doch ziemlich erstaunt....vielleicht sollte man mal Zoner mit diesen Fakten konfrontieren. Der könnte dann im Prinzip aus erster Hand Aufklärung leisten.

Zu VIS und LEAF:
schlicht und einfach: Stimmt. =) ...................................aaaaaber..........es könnte ja auch so sein, daß qbsp ausnahmslos von jeder Brush-Fläche aus schneidet, so daß sich nie ein einzelnes LEAF von der linken Wand des unteren Raumes bis in den Gang hinein erstrecken würde, sondern immer an der Gangöffnung zerteilt würde (durch die -im Bild 9b von unten kommende- rechte Seitenwand des Raumes). Ich halte diese Vermutung für relativ realistisch, denn: wie sollte qbsp entscheiden, welche Brush-Flächen es bei der Berechnung der LEAFs verwendet und welche nicht??

.....so, jetzt sackt mir gleich der Kopf auf die Taststur.....nach 3.00Uhr morgens sollte man einfach schon pennen..........gute Nacht allerseits!

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

wow...ein echter hammer post:) aber was soll ich dazu sagen? es stimmt...wenn das die 800newbies, die hier registriert sind mal lesen+verstehen würden, würden sie wohl so einige fragen zu ruckelnden maps nicht stellen....und weniger maps, die viel abrbeit waren in den sand setzen, weil es einfach nur laggt. ich bin zur zeit dabei, mich in eine neue, noch nicht bekannte engine einzuarbeiten. ich darf dazu nichts sagen, es besteht noch kein patent. ich kann nur sagen, es wird NUR berechnet, was man wirklich sieht. wies funzt is geheim. wenn sie nen patent hat, ich infos weitergeben draf, steht alles technische auf meiner hp.

Jojo Linga ich denk du kommst erst im Sommer zu den *peep* :)

hat sich geändert, ich bin jetz fest ins projekt/firma eingeschlossen

Also was jetzt kommt sind zum großen Teil Vermutungen, ich werd's aber trotzdem mal sagen:

Eine BSP-Datei heißt so, weil der Kernteil aus einem BSP-Tree besteht. Ein BSP (Binary Space Partitioning)-Tree stellt ein Level dar, indem er es in Nodes zerteilt. Ein Node wird durch folgende Dinge definiert:
- die Hyperplane (die Ebene an der das Level aufgeteilt wird)
- die Polygone die auf der Hyperplane liegen
- ein Verweise auf den Node der hinter der Hyperplane liegt und einer auf den Node der vor der Hyperplane liegt

Ausgehen von einem Root-Node wird nun das ganze Level so lange in Nodes zerteilt, bis alle Polygone irgendwo auf Hyperplanes liegen. Die Leafs liegen zwischen den Hyperplanes.
Ob das Szenario jetzt aussieht wie ich's zuerst geschildert habe oder obs so aussieht wie im r_speeds-Artikel hängt also davon ab, in welcher Reihenfolge das Level aufgesplittet wird.
Wenn gleich nach der oberen Wand des unteren Raumes die rechte Wand dieses Raumes verwendet wird ist alles Ok. Wird aber zuerst die untere Wand des Ganges verwendet sieht's so aus wie ich's geschildert habe.

Ich hoffe ich konnte mich verständlich ausdrücken :)

Ich hab leider kA wie QBSP2 Planes genau gewichtet, nur in etwa folgendes:
Alle 1024 Einheiten wird in X- und Y-Richtung gesplittet
Hint-Brushes erhalten SEHR HOHE Priorität (ZHLT natürlich nur)
Planes die Parallel zu Achsen verlaufen haben SEHR HOHE Priorität (was in dem Beispiel natürlich keinen Unterschied macht)
Je ausgewogener desto besser, will sagen: die Polygonzahl im Back- und Front-Node wird ungefähr gleich gehalten
Je weniger Polygonsplits desto besser; d.h. QBSP2 versucht, keine Brushes zusätzlich aufzusplitten wenn's nicht sein muß (eine Brush kann ja nicht auf Nodes verteilt werden)

Gut möglich, das nach einem Split in X-Richtung möglichst ein Split in Y-Richtung erfolgen soll, was das Resultat von Abb. 9b wahrscheinlicher macht.

Aber das sind also nur wilde Spekulationen, und man muß das wohl bei jedem Level von neuem ausprobieren.
Nützlich wäre hier ein Tool um Portals & Leafs anzeigen zu lassen... so was müßte es doch eigentlich geben, oder?

cu,
Prefect

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

......so langsam geht's ans Eingemachte....=)
Nachdem's schon wieder fast 3:00 Uhr ist, mußte ich mir den Post doch glatt dreimal durchlesen, bis ich mir alles bildlich vorstellen konnte (@ Prefect: das ist ABSOLUT keine Kritik an der Verständlichkeit Deines Posts).

Wenn ich jetzt alles richtig kapiert habe, dann sind
a)Hyperplanes jene "Glasscheiben", mit denen qbsp -ausgehend von bestehenden Brush-FAces- die player_accessible_area einer Map in einzelne Volumina aufteilt
b)Nodes im Prinzip vergleichbar mit den LEAFs (?). Wenn nein, dann bitte nochmal einen zweiten Erklärungsversuch =).

Soweit ich weiß, erstreckt sich ein Hyperplane ausgehend von einem Brushface so weit, bis es wiederum auf einen Brush auftrifft. Somit hätten wir -was Bild 9b betrifft- beide recht --> es fehlt im Bild mindestens eine blaue Linie: die Verlängerung der unteren Gangwand nach links, quer durch den unteren Raum. Des weiteren wäre im Eck des Ganges ein weiteres (ca. quadratisches) Leaf, außerdem gäbe es im oberen Raum drei Leafs (Verlängerung der beiden senkrechten Gangwände nach oben) --> das stimmt natürlich nur dann, wenn wirklich jede Brush-Fläche zur´Erstellung eines Hyperplanes herangezogen wird und keine "ausgelassen" wird. Meines Erachtens ist das aber anzunehmen, da es ja andernfalls viel seltener bzw. so gut wie nie zu MAX_LEAF_FACES-Errors durch zu detaillierte Brushes kommen dürfte.

zu "Gewichtung von Planes":

-die Hint-Brushes zählen -soweit ich weiß- genauso viel wie normale Brushes --> an ihnen werden Hyperplanes genauso gebrochen, wie an normalen Brushes
-qbsp verwendet, wenn vorhanden, immer zuerst achsparallele Planes für die Hyperplanes, erst danach dann schiefwinklige
-Brushes, die von Clip-Brushes umschlossen sind, werden nicht für die Erstellung der Hyperplanes herangezogen (da der Bereich innerhalb des Clip-Brushes nicht zur player_acessible_area zählt)

In welcher Reihenfolge nun qbsp die Hyperplanes erstellt.....keine Ahnung, jedoch eine unbegründete Vermutung: Brush für Brush, der "Nummerierung" der Brushes folgend... (?).

-So ein Leaf&Portal-Tool wäre ein wahrer Segen!!!

Ich muß ja gestehen, daß bei mir nun auch so langsam die Phase der wilden Vermutungen und des "gesunden Halbwissens" anfängt....... =)

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

aber wie kann ich Reihenfolge in der das Level aufgesplittet wird beeinflussen?
und nochwas, die quake engine zerteilt ja auch grosse plattformen in kleine, jenachdem, wie gross die textur ist, die auf ihm liegt,(max_patch fehler), also wenn eine textur 160x120 units gross ist wird eine grosse (zb. bodenfläche) in 160+120 grosse "teile" unterteilt. das steht ja fest, daher sinken auch die r_speeds, wenn man texturen vergrössert. weil eben weniger polygone aus einer fläche geschnitten werden. Fazit: an jeder textur-wiederhohlung gibts nen neues poly. wenn aber wie zb. in anderen gfx-engines dem nicht so ist(da können sich die texts 1000x wiederhohlen, trotzdem wird die fläche nicht zersplittet.)= viel weniger polygone=bessere r_speeds, das ist wohl die erklärung dafür, warum die r_speeds sinken, wenn man in der q-engine die texturen vergrössert.

ABER: wie ist es, wenn man auf jedes face eines brushes verschiedene (texturen)-grössen legt, also auf die obere seite eine 60x100 und auf die untere eine die 70x28 gross ist, wie werden die brushes dann zersplittet?das wäre ja ein wahnsinniges durcheinander, es würde wahrschenlich jahre dauern, bis die lightmap berechnet wäre usw. wie würd dieses problem gelöst? entweder man teilt den brush in 2 hälften, oben und unten, ok dann hätte man das problem gelöst, aber was ist wenn man jetzt auchnoch die 4 seiten des brushes individuell texturiert? da wäre das dann wieder für den arsch...

PS: in der q-engine werden die flächen bei einer textur nur zersplittet, weil der software modus damit nich klarkommt, in engines die auf 3d-beschleunigung bestehen, ist es so, dass der block egal wie viele textur wiederhohlungen immer nur ein polygon ist.

PS #2
die skytextur in der hl-engine zu´vergrössern bringt so nichts, der skybrush ist ein spezieller brush, der aus max 3, oder mehr, genaue zahl weis ich nicht, polys besteht, egal wie gross er ist.

Ende:
Entschuldigung, wenn ich jetzt was mit ner anderen engine verwechsele, aber es sollte alles so stimmen:)

PS: #3

in der unreal-engine gibt es ja keine skybox=keine leaks, da wird der sky einfach irgentwo hin gebaut, ganz klein, alle informationen wie zb. in der ut map "face" diese asteroiden die da um die map fliegen sind in diesem kleinen kasten enthalten und nehmen so sogut wie garkeine resourcen weg...

ich hoffe, das trägt zum thema bei, ist schon ein ziehmlicher hammer...viele werden sich wohl nicht beteiligen können, das mal auf 100 replys zu bringen wäre mal was =)

ich hätte eigentlich lieber ein paar mehr antworten...ist euch da zu viel zu lesen???

Unverständnis @ Linga: ist doch egal, wieviele rePosts kommen. Qualität statt Quantität!!

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

yeah, ein mann, ein wort=) sag mir aber trotzdem mal, ob das was ich gesagt habe stimmt und gib mir ne antwort auf die "frage" mit den faces-texturen-verschiedene*g*=)

Ich muss Linga da korrigieren: Du hast was von brushes geschrieben, die bei unterschiedlichen texturgrössen an gegenübberliegenden seiten zerschnitten werden müssten, dass stimmt aber nicht da die qake-engine ja komplett mit polygonen rechnet, es ist ja egal ob an der oberen fläche eines würfels 8, an der unteren aber nur 2 polygone sind !!

Ich hoffe ihr versteht was ich meine...

cu

Wo wir gerade beim Thema Engines und so sind: Hat jemand eine leise Ahnung wie die Republic-Engine (Egal wieviele Poly's, keine performance-einbußen) funktionieren soll?

Wo wir gerade beim Thema Engines und so sind: Hat jemand eine leise Ahnung wie die Republic-Engine (Egal wieviele Poly's, keine performance-einbußen) funktionieren soll?

nö, 1. finde ich, das die grafik scheisse aussieht, 2. was soll der übertriebene quatsch? 3. wer soll soviel bauen?????wenn ein hasu 100.000polys hat, viel spass....3. das steigert sich doch immer weiter, jede neue engine kann mehr verarbeiten, ich würde die nicht so hochpreisen, immerhin solls ja noch 2? jahre dauern und wer weis, was es bis dahin alles gibt...

ja genau, ich kann mir allerdings vorstellen dass die entwickler von republik nur etwas übertrieben auf die werbetrommel gehaut haben (alle bisherigen screens waren zb NICHT von der eigentlichen engine gerendert...)

Hmm mal rechnen: wenn ein haus 1.000.000(!) polys haben soll, eine stadt 100 Häuser, dazu nochmal das dreifache an polygonen von irgendwelchen Straßen, -laternen, Telefonzellen... Und jetzt kommts: die verrückten wollen bis zu 30 Städte bauen, das KANN nicht gehen, auch in 10 jahren nicht...und weder eine engine noch die passende hardware wird es in 2 jahren geben...

was meint ihr dazu?

cu

ich wollte noch anmerken: was bringt die supertoll-ultimative hyperaufendigste grafik einem spiel, wenn es keinen spass macht, weil die entwickler alles auf die grafik setzten?? eben....

so und bevor ich noch weiter offtopices zeug schwafele sollte ich lieber offLINE gehen =)=)

cu

Schade das ich übers Wochenende weg war und so was verpaßt habe. Ich hätte eigentlich nur noch für crid eine Sache zu Nodes hinzuzufügen. Verdammt, ist das schwer zu erklären... ich versuch's mal:

Erstens: Nodes sind keine Leafs.

Zweitens: Nodes sind verschachtelt. Jedes Level wird prinzipiell von einem Node aus dargestellt, dem Root-Node. Dieser Root-Node überspannt das gesamte Level. Die Hyperplane dieses Nodes unterteilt das Level in zwei Hälften, die wiederum durch einen Node dargestellt werden.
Jeder dieser Nodes teilt seine Levelhälfte wiederum in zwei Hälften auf, die von je einem Node dargestellt werden usw...

Man könnte natürlich so gesehen die Nodes auch als die Hyperplanes verstehen...
Ich versuch mal ein Beispiel mit ASCII-Art:

<pre>
+--+---------+
| | |
| |
| +------+
| |
| |
+-----+
</pre>

Das soll jetzt mal der Grundriß eines SEHR einfach Level sein. Nach ein paar Splits sieht das Level jetzt wie folgt aus:

<pre>
/- Hyperplane von Node a

i
+--I---------+
|NoI Node2 |
|d1i |
== - - ========= <- Hyperplane von Node A
| I
| I
+-----I
Node3 i Node4

- Hyperplane von Node b
</pre>

So... Die Root-Node (Node A) umfaßt das gesamte Level und sein Hyperplane teilt es in die zwei Subnodes a und b auf. Der BSP-Tree (so wird diese ganze Struktur aus Nodes nämlich genannt) sieht bis jetzt also so aus:

<pre>
A
/ \n a b
/ / \n 1 2 3 4
</pre>

Umm..... nachdem ich hier einen ewig langen Post geschrieben habe:

Vielleicht wärs tatsächlich am Besten, die Nodes mit den Hyperplanes gleichzusetzen, und einfach zu sagen: Die Leafs sind das dazwischen.

cu,
Prefect

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

Achja... zu diesem was-weiß-ich-wieviele-mio-polygone Ding. Die sind einfach verrückt. Oder sie haben zu viel Zeit vor Crays verbracht :)

cu,
Prefect

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

wie solls gehen, das unendlich polys angezeigt werden?eine grenze muss doch da sein, sei es von den vielen koordinaten her oder einfach davon, das keine grafikkarte unendlich schnell sein kann...nur der mensch kann unendlich viel verarbeiten, nur kommt er in seinen durchschnittlich 70 jahren nicht dazu....

Das menschliche Auge funktioniert eigentlich eher wie ein Raytracer. Die sind aber auf Computerbasis noch langsamer...

cu,
Prefect

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

...außerdem nimmt der Mensch nur einen sehr kleinen Teil dessen, was er im Blickfeld hat, detailliert wahr, ansonsten wäre das Gehirn restlos überfordert.

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

@ Linga: wenn eine Brushfläche an Texturkanten gesplittet wird, dann wird nur diese eine Fläche zerschnitten und nicht der komplette Brush, zu dem diese Fläche gehört (die Engine selbst arbeitet ja nicht mit den Blöcken, sondern nur mit den einzelnen Flächen, die die Blöcke "zur Verfügung stellen"). Man kann diese Blöcke auch als eine Art Hilfsmittel für a) den Mapper und b) die Kompiler sehen. Der Mapper tut sich mit "Kisten " leichter als mit Flächen und die Kompiler können anhand der Blöcke die "Gültigkeit" der Geometrie (z.B. ob keine gekrümmten Flächen vorhanden sind) feststellen, obwohl ich mir nicht so ganz sicher bin, ob die Kompiler tatsächlich die Blöcke als solche "registrieren" oder doch nur die einzelnen Seitenflächen (?). Wobei, wenn man sich diesen Ausschnitt eines Kompilings ansieht:

...
CreateBrush:
10..20..30..Fatal: Entity 0, Brush 303, Side 0: plane with no normal
Fatal: Entity 0, Brush 303, Side 4: has a coplanar plane at (480, -19, -96), texture STEEL
Fatal: Entity 0, Brush 303, Side 6: has a coplanar plane at (479, -20, -96), texture STEEL
Fatal: Entity 0, Brush 303, Side 8: has a coplanar plane at (477, -19, -96), texture STEEL
...etc.etc...

....dann ist eindeutig von >Brushes< die Rede ("CreateBrush") und von Brush-Sides.....

@ Prefect:
vielen Dank für die ausführliche Erklärung! Ich glaube, so langsam kapier' ich die Nodes. Allerdings glaube ich -wie Du ja auch schon angedeutet hast-, daß man als "normal sterblicher Mapper" =) diese Feinheiten Leaf/Node nicht so unbedingt wissen/verstehen muß. Zu wissen, was ein Leaf ist, wie und warum es entsteht, dürfte eigentlich für gute r_speeds genügen.
Was mich aber echt noch interessieren würde: in welcher Reihenfolge die Hyperplanes gelegt werden bzw. an welchen Brushes zuerst....wenn Du oder irgendjemand anderes das mal rausfinden sollte, wäre ich an der Info sehr interessiert...

[BSE] crid

Compile-Errors-Artikel (Version 09-01)

http://www.crid.de oder http://www-public.tu-bs.de:8080/~y0009981/

danke crid....is ziehmlich konzenrtations-fordenrt, da ich ja noch mit ner völlig anderen engine zu tun hab....die is nich mit unreal oder quake zu vergleichen, is alles geiler für den mapper:)) spiel dazu gibts in nem jahr vorraussichtlich

aber ich will ja auch bischen mitreden:)

Uff, das ist ein Post nach meinem Geschmack :) Zumindest verstehe ich das MEISTE der Diskussion (werds mir wohl noch ein paar Mal durchlesen müssen)
Meine Theorie zur Republic-Engine: Eine Engine, die ohne Performance-Verlust Millionen von Polygonen anzeigen kann, kannes nicht geben. Entweder arbeitet die Engine mit Nebel-Effekten (z.B. wie Turok) oder sie verlangt die Vernunft des Mappers, nicht zu viele Polygone zu "bauen". Die Entwickler haben für die Engine wahrscheinlich kein Polygon-Limit gesetzt, wie es bei der Quake2-Engine der Fall ist (mit NOCLIP vom Level wegfliegen und ihr wisst, was ich meine). D.h. sie kann dann zwar theoretisch "unendlich" viele Polygone darstellen, aber dann auf Kosten der Framerate.

Boogdoo

------------------------------
© Boogdoo
a.k.a. -=[TFoG|Saddam]=-, ViZiT http://www.tfog-clan.de/