loadworld() noch ein Bug?

[Zaphod]

octree ist das typische visibility determination für terrains. man kanns zwar auch für indoor zwecke zurechthäckseln (wie das zb qube macht) das wird aber vermutlich nur fürs terrain gemacht. der indoor renderer war bisher zumindest ein bsp algorithmus (bsp visibility ist nicht das selbe wie das id bsp levelformat - das heißt nur so weil die auch mit dem bsp algorithmus arbeiten).

ogre benutzt aber nur backface culling für meshes, richtige visibility funktionen gibt es für meshes aber nicht, denn dafür müßten die meshes schon speziell vorbereitet sein. nutzt mal also meshes als levelformat, dann werden immer alle polygone gerendert, auch wenn sie nicht sichtbar sind (painters alogrithm). das ist für größere levels nicht schnell genug.

wenn man sich also entschließt ein eigenes levelformat zu schaffen, dann brauch man auch eigene darstellungsroutinen und wenn man nicht mindestens einen schwachen mechanismus wie portal visibility umsetzt, dann kann man sich die arbeit auch gleich ganz sparen.

[Sebe]

Verflixt, das wusste ich nicht. Das führt tatsächlich jegliche Arbeit an einem eigenen Levelformat ad absurdum. Ich weiss nur, dass z.B. Irrlicht Octree durchaus für alle Meshes verwendet. Da OGRE immer so überlegen dargestellt wird habe ich einfach angenommen, dass OGRE das auch macht. Insofern kann wohl wirklich nur Fred darüber Aufschluss geben, was denn nun mit der OGRE Library los ist

[Zaphod]

die irrlicht engine benutzt octree allerhöchstens um festzustellen, ob ein mesh innerhalb eines terrains grade sichbar ist oder nicht. keine engine kann octree visibility für die darstellung eines dafür nicht vorbereiteten meshes benutzen, denn auch da müssen die daten speziell abgelegt sein (es würde auch keinen sinn machen, denn octree visibility ist dafür nicht gedacht und würde nicht sehr optimale ergebnisse erzielen - das ist einer der gründe, warum man in einer engine zwischen meshes und leveldaten unterscheidet).

ogre ist generell flexibler als irrlicht, deswegen ist ogre wahrscheinlich schon die bessere wahl. auch kann fred die ogre implementierung ziemlich beliebig erweitern, denn es soll recht einfach sein neue scene manegement funktionen in ogre einzuführen. da das aber ziemlich viel arbeit sein dürfte, bezweifle ich dass das in absehbarer zeit passieren wird.

generell ist das also eine zwiespältige entscheidung: das id format zwingt einem zu streng nichtkommerzieller verwendung. es nicht anzubieten macht vorerst aber einen indoor shooter umzusetzen zu einer ziemlich schweren angelegenheit, zumindest wenn man keine großen einschränkungen des levelaufbaus in kauf nehmen will.

[Sebe]

Ich habe mich mal etwas umgelesen. Scheint so, als wäre nicht BSP selbst von den Lizenzbestimmungen betroffen, sondern nur die Tool von id. Ein Freewaretool sollte diesen Einschränkungen also nicht unterliegen. Evtl. erstelle ich mal einen Thread im englischen Forum um herauszufinden, ob die Funktion in absehbarer Zeit wieder implementiert wird. Glücklicherweise bin ich erstmal nicht darauf angewiesen, da mein derzeitiges Projekt kein Indoor Shooter ist. Generell macht es aber wirklich wenig Sinn eine Funktion aus der Library zu entfernen, die eigentlich funktionert/funktionieren sollte.

[Zaphod]

der letzte stand der mir bekannt ist, besagte nach einer stellungnahme von id, dass auch das format eingeschränkt ist, denn afaik gibt es schon einen offenen bsp compiler sowie ein freien leveleditor (gtk-radiant).

[Jake]

February 17th 11:25:27 AM 2006 - Updated by [ TTimo ]

Following last summer's release of Quake III Arena source code and tools under the GPL license, id is now placing GtkRadiant and q3map2 under GPL license. We are also providing in this release a number of Quake II tools that never made it under GPL when we packaged Quake II source code

[hardfalcon]

Äh, irgendwie versteh ich dich nicht ganz, Zaphod. Der LEvel soll ja nicht aus einem einzigen Mesh bestehen, sondern aus mehreren Meshes. Anstelle eines "Block-Objektes" bei BSP würden wir ein einzelnes Mesh benutzen. Selbstverständlich kann man nicht einen gesamten Level aus einem einzigen Mesh machen, sonst bräuchten wir ja gar kein eigenes Levelformat...

[Sebe]

Das ist schon richtig hardfalcon. Was Zaphod meint ist, dass trotzdem alle Objekte berechnet werden müssen, was einen Haufen Performance kostet. Es sei denn wir schaffen es irgendwie, eine Art PVS einzubauen. Müsste man mal überlegen, wie man sowas direkt in PureBasic integrieren könnte.

[Zaphod]

ich bezog mich ursprünglich darauf:

zitat von Sebe:

Lade dein Level halt einfach als Mesh, Kollisions- und Physikfunktionen gibt es bereits.

Bei einer BSP map sind die einzelnen Polygone der Map in einem Binärem Suchbaum gespeichert. Deswegen dauert das "BSP - kompilieren" bei einer Quakemap auch so lange.

Dadurch läßt sich extrem schnell feststellen, welche Polygone gezeichnet werden müssen, weil das schlimmsten falls n schritte durch den bsp-baum sind bei einer baumtiefe von n.

das heißt auch, dass mesh wahrscheinlich keine sehr günstige datenstruktur ist, um einen level mit visibility determination zu zeichnen, je nachdem wie ogre dessen daten handhabt. die einzig praktikable methode die ich da sehe wäre wohl, für jedes frame ein mesh zu erzeugen, dass nur die polygone enthält, dass das visibility als möglicherweise sichtbar erachtet.
ob das sinnvoll ist, hängt dann davon ab, wieviel overhead beim erzeugen sehr großer meshes von ogre her mitkommt.
nach meinen spielereien mit einer der sehr früheren ogre versionen würde ich aber mal vermuten, dass es schneller und sogar einfacher ist dann lieber gleich opengl zu benutzen.

[dllfreak2001]

Ich weiss nicht was die Leute hier gegen das BSP-Format haben.
Auch wenn es veraltet ist, es ist immer noch möglich recht Spektakuläre Dinge damit zu machen, man muß nur wissen wie.
Es muss doch den meisten hier klar sein das mit PB-Ogre sowieso kein D3/Q4 machbar wäre. Von daher ist das Q3-BSP-Format bereits optimal für PB.

Achja, trotzdem wäre es absurd Befehle für eine Funktion zu entwickeln,
die später garnicht existieren wird.