Ich glaube zwar nicht das das stimmt, aber:

Nehmen wir mal an man spielt jetzt in 800*600. Für das AUge sind das, egal wie detailliert 800*600 Pixel. Dabei ist es egal ob das ein riesen Poly ist oder eine fette 2D-studio Min Szene ist. Wenn man jetzt 1024 untis von einem grossen polygon entfernt ist ist es nur noch sehr klein. Da läge es doch auf der hand nur diesen kleinen bereich (villeicht 30*20) berechnen zu lassen. Zwar kann ich mir das von technischer seite her nicht vorstellen, aber irgendwie scheint es logisch. So würde immer die gleiche menge berechent (800*600), egal wie viele polys. Ist natürlich alles nur >>>_*THEORIE*_<<< ...
einen schönen tag noch

das könnte so leider nicht funktionieren (auch wenn es auf den ersten blick logisch erscheint), da ja immer noch mit polygonen gerechnet werden muss, und da ist es ja egal ob ein polygon aus 6 oder aus 60.000 pixeln besteht, es hat so oder so nur drei berechnete Eckpunkte !!

aber wer weiss, was nicht doch alles möglich ist......eine _komplett_ mit pixeln rechnende engine??

cu

=voxelengine oder?*g*

also, wenn ein baum 10 meter hoch is, jetz aber 100meter von dir weg-steht isser immernoch 10m hoch....klar¿...

@kap: habe ja gesagt das ich mir's nicht so recht vorstellen kann =)

@Linga: Ja, die Baumgrösse ändert sich nicht, aber wie jede 3D Engine Täuscht auch die Q/HL nur eine 3D umgebung vor (ich weiss das hast du gewusst). Und wenn sie den eindruck machen soll das du rückwärts vom baum wegläufst, und der baum dir nicht folgt *g* sondern stehenbleibt muss er verkleinert werden...

@Prefect: Soll also in etwa heißen, über die Nodes kann man auf die einzelnen Leafs zugreifen, ja? Werden dann die Nodes nur soweit fortgeführt, bis alle Leafs eingeschlossen sind? Dann müsste also (wenn wir das jetzt mal weiterspinnen) von einem Endnode ein Pointer auf eine Leaf-Struktur erfolgen, die dann die Koordinaten der einzelnen Polygone enthält, oder?
Interessant finde ich auch, wie es funktioniert, dass der Renderer auch wirklich nur die nötigen Teile berechnet (okay, es ist immer mehr als nötig, aber zumindest berechnet er nicht alles). Die Kompilierprogramme berechnen das ja, von welchem Leaf man in welches sehen kann. Dies wird dann wohl auch in einem ähnlichen Baum gespeichert bzw. als eine große Reihe von Pointern realisiert. Berechnet werden ja wohl (so zumindest meine Erfahrungen) immer alle Polygone, die zu einem Leaf gehören, das man (wenn auch nur theoretisch) sehen kann. Was ist eigentlich dann, wenn man z.B. eine Handgranate oder ähnliches in ein Leaf wirft, das nicht berechnet wird? Wird dieses dann für die Effektberechnung mit eingebunden oder werden die Effekte bzw. die Auswirkungen (etwa Decals) nur gespeichert, für den Fall, das der Spieler später in Sichtweite kommt? Und noch etwas: Gerendert wird nur, was der Spieler sieht. Aber was ist mit den Stellen, die von Monstern betreten werden? Die brauchen zwar keine Texturen, aber zumindest ein Drahtgittermodel von der Umgebung, damit sie nicht "durch den Boden fallen".
Fragen über Fragen, aber ich hab mich mit der Materie auch noch nicht so sehr beschäftigt... (obwohl ich zugeben muss, dass sie sehr interessant ist - im PC-Magazin gab's mal eine Grundlagenbeschreibung von 3D-Engines, aber da ich mit Matrixrechnung und Vektoren noch nicht so viel anfangen kann, hab ich das erstmal beseite gelegt...)

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

@crid: Nachdem sich dieser Thread so weit entwickelt hat, überlege ich mir ernsthaft den Quellcode von QBSP2 näher anzuschauen. Vielleicht kann ich dann mit mehr Infos kommen...

@TheTinySteini: Generell gilt das gleiche wie für crid =) Was ich aber sicher sagen kann: Spezialeffekte (wie Explosion von einer Handgranate) werden per tempentity erzeugt. Wenn du eine Tempentity erzeugst, gibst du an, an welche Spieler sie geschickt werden soll (erster Parameter). Da gibt's dann z.B. MSG_ALL (alle Spieler), MSG_ONE (ein bestimmter Spieler), MSG_PVS (alle Spieler im Potentially Visible Set des angegebenen Punktes, dritter Parameter), MSG_PAS (alle Spieler im Potentially Audible Set des angegebenen Punktes). Explosionen verwenden MSG_PAS, damit man auch garantiert den Sound zu hören bekommt.

Zur Republic-Engine: Es macht keinen wahnsinnig großen Unterschied wie weit die Polygone entfernt sind; die Eckpunkte müssen immer transformiert (aka 3D -> 2D berechnet) werden. Was allerdings eine Option wäre, ist MRM (Mesh Reduction Method?) die z.B. bei TF2 verwendet werden wird, um detailiertere Models zu unterstützen. MRM ermöglicht onthefly "überschüssige" Polygone wegzurechnen. Die Figur wird dann natürlich kantiger, geht aber schneller zu berechnen. Und auf die Ferne wirkt sich das dann auch nicht mehr so wahnsinnig aus.
Bei TF2 wird MRM nur für Models verwendet, nicht für Brushes (World & Entities), aber wenn die Republic-Engine nicht gerade mit BSP-Trees arbeitet könnte das die Lösung des Problems sein...

cu,
Prefect

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

wow, sehr gute fragen, vorallem das mit der handgranate würde mich interresieren, aber aus erfahrung nehme ich doch schwer an, das das portal, in das die granate fällt berechnet wird...
das mit den monstern weis ich nicht, aber e-polys werden doch auch nicht von überall berechnet...tests zu folge nicht(sieht man ja, wenn man nur die r_speeds misst), aber wenn man im noclip mode in den sky-brush fliegt, sieht man alle entitys/functions, e-polys eben...also werden alle irgentwie doch berücksichtigt?nein....naja, warten wirs ab, was die anderen sagen...die monster treten ja erst in aktion, wenn sie getriggert werden, was die vorher machen, kA, stehen doof rum, warten auf ihr script, aber warum sie durch den, bisher "noch ganicht" existierenden boden fallen...kA

@perfect: MRM nutzt auch q3 richtig? aber wie isn das bei q3 wenn man auf ein entferntes modell ranzoomt? bisher gibts nur nen kleinen zoom, aber wenns die "sniper-mods" gibt, da haben die ja was zu coden....

@Linga: Ich schätze mal, dass das Snipern nicht so das Problem darstellen wird. Die Engine wird sicher die sichtbare Größe des Models bestimmen (die ja von der Entfernung abhängt, - sehr wahrscheinlich machen die das mit nem Winkel, einmal TraceLine zum Kopf, einmal zu den Füßen, und aus dem daraus resultierenden Winkel wird die Größe bestimmt) und danach die Polygonzahl richten. Wenn man nun ranzoomt, wird das Model auch automatisch größer, und damit berechnet die Engine wieder mehr Polys. Vorrausgesetzt natürlich, diese völlig geratene Vermutung stimmt...

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

Achso, und Prefect: Wieso war denn deine gl-Logdatei so klein? Meine war nach wenigen Sekunden (etwa 25) schon 47 MB...

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

Nagel mich bitte nicht wegen der gl.log-Größe fest - ich hab die Daten nicht mehr im Kopf.

@Linga: Jetzt weiß ich's wieder... in HL wird das FOV auch berücksichtigt: wenn du dich in HL ranzoomst werden die wpolys & epolys weniger (bezieht sich auf icq). Und was die Models & MRM angeht, da kann ich TinySteini bloß zustimmen. Alles andere wäre auch völliger Quatsch.

Was die Monster angeht: Die PVS-Berechnung hat NUR auf den Rendervorgang für den Spieler Einfluß. D.h. fürs Clipping / Physics-Berechnung usw... hat das gar keine Auswirkung.
Das die Monster am Anfang dumm rumstehen ist im Code + Keyvalues verankert. Da gibt's ja so ne Keyvalue Trigger condition oder so, die man auf verschiedene Werte wie Trigger, Script, 50% Health, See Player usw... setzen kann. Im Fall See Player wartet der Code so lange bis FIND_CLIENT_IN_PVS() eine Entity zurückgibt, oder anders ausgedrückt: Das Monster sich im PVS eines Spielers (clients) befindet. Das hat übrigens zur Folge das die Monster schon einiges früher loslegen wenn VIS nicht verwendet wurde - in dem Fall ist der Spieler ja immer im PVS der Monster und umgekehrt.

cu,
Prefect

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

Mit der Log-Datei ist ja auch egal....
Aber wie bekommt jetzt eigentlich der Renderer die Infos, wo welche Monster stehen, wenn er die betreffenden Stellen nicht berechnet (zumindest nicht für den Spieler). Es müsste also praktisch immer zumindest ein Drahtgittermodell der Map verfügbar sein, anhand der die Monster bewegt werden. Sonst wüsste ja keiner, wo die langgehen sollen (oder - soweit sie sich noch gar nicht bewegen - wo überhaupt ihre Postition ist). Oder wird das einfach über die bereits in WC gesetzten Entitys gemacht? Sprich, ein Monster wird einfach auf dem Entity erstellt, bleibt dort so lange, wie es sich nicht im gerenderten Bereich (und damit nicht im Bereich eines Spielers) aufhält, wird aktiv, sobald ein Spieler in die Nähe kommt, damit wird auch der Bereich um das Monster herum berechnet, das Monster startet seine Aktivitäten, und sobald der Spieler nicht mehr in der Nähe ist, wird einfach nur die Position des Monsters gespeichert und das Monster bewegt sich nicht mehr (ohohoh, Bandwurmsatz...). Und weil es sich nicht bewegt, braucht es natürlich auch nicht zu wissen, wo der Boden, die Wände etc sind. Ich schätze auch mal, dass die Monster - solange sie außer Sichtweite sind - auch nur mit den wichtigsten Variablen (Position, Blickrichtung, Health...) abgespeichert werden. Erst dann, wenn ein Spieler in die Nähe kommt, wird eine neue Monster-Class mit den entsprechenden Werten erstellt. Oder ist das Murks, was ich hier erzähle?

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

jo, das stimmt; sonst gäbe es extreme e-poly's... und das spiel wäre unspielbar...weil in den hl/svencoop level wimmelt es nur von monstern/monstermakern!

Source SDK

Nenene. Das ganze ist so:

Was Physics & Spielcode angeht (d.h. Monsterbewegungen usw.) werden die ganzen VIS-Berechnungen VÖLLIG ignoriert. Was den dll-Code angeht kannst du das Ganze PVS-Zeugs eigentlich vergessen.
NUR: Damit nicht alle "interessanten" Dinge in einer Karte passieren bevor der Spieler überhaupt hinkommt hat Valve in den Monstercode eine dementsprechende Sperre eingebaut.

Auch wenn eine Szene gerendert wird, geht die Engine eigentlich durch ALLE Leafs durch, ABER: letztendlich werden nur die Leafs tatsächlich auch gerendert, die im PVS sind - alle anderen werden in der Schleife einfach übergangen. Natürlich werden dann auch die Monster in dem Leaf beim Rendern übergangen.

cu,
Prefect

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