Noch eine letzte Frage und dann lass ich euch erst einmal für eine gaaanz lange Zeit in Ruhe. Es geht um die Level als solches und die Kollisionssysteme.
Es geht erst mal um den Kompiler:
"Build BSP Map" "Build Simple Map" "Create Meshes" "Create PVS".
Da ich die Commercial habe, nehme ich mal stark an, dass "Build BSP Map" und "Create PVS" zwei Optionen sind, die ich mit "nutzlos" abstempeln kann, da die Engine unter Commersial alles mit dem ABT-Tree System rendert, oder liege ich da falsch und die Optionen haben auch unter Commercial einen nutzen?
Wofür ist "Create Meshes" allgemein gut und stimmt es, dass man nur Shader auf Levelblocks anwenden kann, wenn der Level mit "Create Meshes" kompiliert wurde?
Und als zweites die Kollisionssysteme:
Ich kann OBB nur benutzen mit "Create Meshes" compilierten Leveln, richtig?
Ist es möglich, für Level OBB-kollision zu benutzen und zeitgleich Entity gegen Entity AABB-kollisionen?
Aber ich glaube nicht, denn bei "Create Meshes"-compilierten Leveln sind Levelgeometrie und Entities im Prinzip ein und dasselbe, oder...?
Sollte ich von Anfang an "Create Meshes" benutzen (will für Level Ent_decal benutzen und das funktioniert ja nur in Kombination damit). Ich teste gerade OBB und habe das problem, wenn ich gegen ein anderes (unbewegtes) Model laufe, dann zucke "ich" komisch herum, im detail, ich bewege mich ein kleines Stück (schätzungsweise 2 Quants) nach vorne und im nächsten Frame werde ich wieder dieses kleine Stück zurückversetzt. Wenn ich gegen die Levelwand laufe, passiert das nicht. Im AABB-System laufe ich gegen das Modell und bleibe bei gedrückter nach-vorne-Taste einfach an ort und Stelle wie es auch sein sollte (und wie bei den Levelwänden auch).
Ich werde jetzt auf jeden Fall erstmal die MED und WED Tutorial der Contestgewinner durcharbeiten und mich nach dem Lite-C Tutorial durch die AUM ab Ausgabe 67 durcharbeiten. Ich denke mal, dass ich dann Fitter bin. Mann, es hat sich so viel seit 2003 verändert...

"PVS": ja. "Build BSP": Nein, denn:





Ja, stimmt. Create Meshes sollte immer aktiviert sein, ist auch für diverse A7 Sachen notwendig (Kollision, manche traces, Lichter). Die Möglichkeit zur Deaktivierung besteht nur deshalb, um Kompatibilität zu A6 zu gewährleisten. Außerdem kannst du Block-Gruppen als "Single Mesh" (setze dort einen Haken in der Blockgruppe) kompilieren, die somit schneller gerendert werden:



Das bedeutet natürlich, dass wenn du sehr große Blöcke und viele kleine an einer Stelle hast, die nur selten sichtbar ist, und alle als Single Mesh renderst, werden die kleinen immer dann gerendert, wenn ein Teil des Meshes sichtbar ist, also: nicht wahllos alles gruppieren und single-meshen!

Dein Problem bezüglich des Zuckens liegt wahrscheinlich am Code (sprich es lässt sich beheben), die beiden Modi sollten aber simultan verwendet werden können.

Ohne jetzt groß alles gelesen zu haben:
Als richtwert benutze ich generell 35 quants = 100cm.
Damit kann man (find ich) sehr gut arbeiten ohne dass man komplex umrechnen muss. Das ergibt eine genauigkeit von knapp 0,03 mm pro 0.001 quant (1000/35000=1/35~0,03)

Man könnte also den Meter noch kleiner definieren weil selbst 0,5mm pro 0.001 quant sollten nicht zu groß auffallen (Wäre dann 2 quants = 1m) aber bei solchen größen wirds auch anstrengender im Editor zu arbeiten.

mein richtwert ist cube small=2meter. ziemlich ungenau definiert aber solang ich mich auskenne ist ja alles in ordnung XD

das entspricht wieder den 32 quants pro meter. fidne ich den einfachsten richtwert.

um eine frage von vorher zu beantworten:
ja, da hast du recht fogman XD geteilte texturen sind schneller.

generell ists so dass die engine einiges kann wenn man optimierungen drauf hat. ich rate den meisten nach wie vor ihre innenlevel mit blöcken zu bauen. shader hin oder her, für alle die keine shader brauchen oder wollen rendert die engine das einfach wesentlich schneller ist ne tatsache. ich bau auch außenlevels je nachdem was es ist in blöcken. da kann man herrlich die gruppierungsfunktion nutzen (nicht zu extrem) und als single mesh compilieren.

WENN du blöcke verwendest, texturiere NUR die wand, die ffektiv im spiel sichtbar ist. alle andre werden beim compiling automatisch mit der default kompiliert. wenn du also die default textur auf 25*25 scalest und ein rendering flag von NONE setzt, werden die andren wende wegkompiliert. läuft schneller.
außerdem kannst du nach wie vor skyboxen setzen bei block levels. bringt nicht viel aber jeder frame zählt.

selbstverständlich hängen all diese maßnahmen davon ab, wie du dein level buast und wie dein code funktioniert. ein gut optimierter code spart viele frames. verschachtelungen ect. hast du lange korridore oder kurze? baust du viele kurven in die korridore nimm eine niedrige clip range, sieht ja dann keiner und spart irre frames

Das einfachste ist im Endeffekt sich ein Referenzmodell
zu estellen. Da man die meisten Sachen eh visuell im Leveleditor erstellt.

Für Anfänger kann ich raten, einfach den Warlord als Referenz direkt im WED Level zu nutzen.

Ja, ich mache das auch immer so. Dazu habe ich mir ein einfaches Refernz-Model gebastelt (einfach ein quaderförmiges Model, mit einer teilweise transparenten Textur). Ein Bild eines Ritters, und daneben ein 2-Meter-Maßstab.


Diese Models platziere ich dann überall im Level, um zu prüfen, ob die Proportionen passen. Wenn ich ein Model in 3DSMax modelliere, das exakte Maßangaben haben muss, dann modelliere ich es zunächst in meinem gewünschten Maßstab (z.B. cm) in Max, und wenn es fertig ist, skaliere ich es dann auf eine Größe, die meinem Referenz-Model entspricht.

Ich hab jetzt auch ein Referenzmodell. Klappt ganz gut damit.
Im Großen und Ganzen kann es bei mir losgehen.... mehr oder weniger....

Ich habe da nämlich eine seltsame Sache:
Ich hatte irgendwo weiter oben ein Zuckeln und Zappeln meiner Spielfigur erwähnt, wenn ich gegen ein anderes Model oder Sprite laufe.
Das tritt immer nur auf, wenn das Level mit "Create Meshes" compiliert wurde (aktuell A 7.853b)
und "Enable_polycollision" auf 1 bzw 2 eingestellt war. Ich konnte versuchen (auch andere A7 Versionen installieren .854,.852 usw...), was ich wollte, es ließ sich nicht lösen.
Jetzt heute hatte ich die Schnauze voll und hab es compiliert, um es zu posten, ob irgendjemand den Fehler (der, wie ich dachte, bei mir liegen musste) finded und mich korrigiert.
Und jetzt das Seltsame: Ich hab die kompilierte EXE (A 7.853b) ausprobiert, ob auch alles läuft und alles mit in den Publish-ordner reingepackt wurde und der Fehler trat nicht auf.
In kompilierter Form läuft die OBB-Kollision ohne "Zuckeln", gleiten funktioniert an Models und Sprites völlig fehlerfrei.
Sterte ich genau das gleiche über WED, ist der Fehler da.

Ist das vielleicht ein Bug im Bezug auf den WED-Editor?
Denn der Code selbst und die kompilierte Engine scheinen ja völlig reibungslos zu funktionieren.
Wenn es auf WED begrenz wäre, könnte ich mit dem Programmieren loslegen.
Ich wollte nicht sofort im Bug-Forum ein neues Thema aufmachen, denn vielleicht gibt es eine schon bekannte Erklärung dafür,
ansonsten würde ich es dann später nochmal dort Posten.
(nur wie soll ich etwas mitschicken, damit der Support den Fehler reproduzieren kann, wenn es doch mit "Publish" funktioniert...)

Warum nutzt du die Beta Version wenn es eine releasede 7.85.4 gibt?

Benutzen ist das falsche Wort...
Ich hab die releasde 7.854 schon drauf gehabt, und noch als Installer auf der Platte. Ich hatte jetzt nur, aufgrund des herumprobierens und wegen des Bugs mit c_ignore (ein Feature, das gar nicht wichtig für mich ist, wie ich jetzt rausgefunden habe) aktuell nochmal die Beta drauf gehabt. Da es aber auch bei der 7.854 genau das gleiche ist mit diesem seltsamen Fehler, habe ich jetzt wieder die 7.854 installiert.
Aber was ist denn jetzt mit diesem seltsamen Fehler?
Hat das noch jemand? Bug, kein Bug?
Es tritt nur beim von WED aus gestarteten Spiel auf, die kompilierte Exe läuft völlig in Ordnung.