sehr schlechte engine

Um mal mehr in JCLs Art zu antworten:

Im Moment wird der Render Kernel komplett überarbeitet. Es wir ein Screenmanager implementiert, der grob gesagt dafür sorgt dass überflüssige Zeichenoperationen wegfallen. Auch werden die in WED erstellten Blöcke in Zukunft als Meshes gerendert, was zu folge hätte dass Blöcke genau so schnell gerendert werden.

Forecast:

New Rendering Kernel (in development / in beta test)
Ein Schalter für den Map-Compiler, um BSP Tree Culling zu aktivieren und deaktivieren. Implementation eines adaptiven binären Tree für Szene-Management ohne BSP Tree. Direkter Geometrie-Import von 3D-Editoren wie MAX oder MAYA. Neue, schnellere Render-Kernels für Entities und Level-Geometrie.

cool. Wuste ich gar ned.
Da freuch ich mich ja schon auf die nächsten updates

danke für die antworten, ich hab auch gemerkt das was in der entwicklung passiert,

aber a6 hat trotzdem noch geschwindigkeits probleme. ich habe mal einen screenshot gemacht. das sind nur blöcke hinter denen ist nichts mehr und die ampeln sind auch low poly. ich hatte schon viele probs, wenn ich eine stadt bauen wollte.

darf ich raten: du hast die fenster mit csg-substract in den häuserblock geschnitten...

Ja, genau das ist Dein Problem: Du nutzt Blöcke.

Blöcke sind in A6 langsam, egal wie schnell Deine Grafikkarte ist, denn dort werden teilweise einzelne Polygone an die Grafikkarte gesendet und nicht ganze Objekte. Mit Shadern würde das sogar in 1-stelligen FPS Bereich rendern.

Nutze also am Besten Blöcke nur für die Kollisionserkennung, baue Häuser aus Modellen oder warte auf die nächsten Updates. Das neue System wird intern die Blöcke in Modelle umwandeln und somit sehr schnell rendern. Neue Tests haben in einigen Leveln die 4-fache Geschwindigkeit erreicht.

Also: Design-Stil ändern oder abwarten.

Nochwas zu Deinem Screenshot: Die Farben sind unnatürlich. Das Licht kommt von einem blau grauen Himmel, trifft auf die gelbe Häuserwand und wird reflektiert. Jetzt hat das resultierende Licht kein perfektes Gelb mehr, sondern nimmt ein wenig von dem blau grau des Himmels an.

Schau Dir mal einen regnerischen Tag als Extrem an. Dort ist alles etwas grau (nicht nur der Himmel), die Blätter der Bäume sind grün-grau, die roten Autos wirken rot-grau usw.
Perfekte Farben sind unnatürlich und wirken immer wie eine Kinderzeichnung mit Buntstiften

hmm nein die sind reingeschoben

ich habe dafür den bug gefunden, denk ich ^^

schaut mal hier:

hmm zu meiner stadt: die sonne ist nur test, sie kommt weg, denn ich habe dynamisches wetter. den himmel den ihr seht ist klares wetter. Ich werde hoffentlich bald eine demo bieten können, in der ihr mein dynamisches wetter testen und selber einbauen könnt.

vielen dank für eure hilfe. wie man sieht sind wmbs nicht so geeignet

Eine aktuelle Version wäre schneller. Du scheinst mit einer älteren zu arbeiten, das sieht man am Debug Panel.
6.40.5 ist schneller als 6.31 ist schneller als 6.22 ist schneller als 6.11

bestimmt die A6.22 pro aber nur weil sie DirectX 8 hat oder sonst was *kein plan was es andauernd für ausreden gibt* 8D

Der Hund muß im Level begraben liegen. Ich hab mit detaillierteren Block Levels auf nem Rechner von 2001/2002 Frameraten mit 60+ bei viel Action bekommen.

@zSteam:
Was für eine Version verwendest du?

old_bill

Ich kann dir nur raten nimm Models wenn du eine Stadt machst.
Hier hab ich mit etwa 25 Häusern, jedes Haus hat etwa 4000 Polygone, eine Framerate von 100 fps.

is ja geil neues update, ich sollte mal öffters gucken. ich hab noch die 6.31.4

hmm aber bei model habe ich immer schwierigkeiten mit der texturierung, oder gibts da schöne programme ? jedenfalls sieht die beleuchtung auf den model häuser sehr heiß aus

also thx für eure hilfe

PS.: ach ja hinter den screenshots sind schon ein paar häuser und modelle, die verbrauchen ja auch schon graka speicher. naja mal schauen obs mit dem update schneller geht

Das sollte igendlich kein zu grosses Problem bei diesem kleinen Level darstellen. Sind die Texturen hoch aufgelöst? Das frisst nehmlich auch resources. Am besten 256 x 256 pixel.
Aber ich kann es echt ned begreifen wie so ein kleines Level so ne Framrate haben kann.

Vielleicht hat er einfach irgend eine Anwendung nebenbei laufen, die ihm so viel Resourcen frisst.
Heute erst hat es mich gewundert, warum mein Level so langsam läuft. Dann schließe ich den IExplorer und siehe da 10 FPS mehr.

MFG Dark_Samurai

fast alle texturen haben eine auflösung von 512x512, sonst würde es mir zu unscharf sein. meine programme im hintergrund sind es auch nicht.


jo und so klein ist mein level garnicht, hier ein paar screens:

wie man sieht´, baue ich texturen sparend (unsichtbare flächen)

Der Shot von oben erklärt einiges. Splitte diese riesigen Blöcke in mehrere kleine auf, das sollte ein wenig helfen.

ähhm LOL ROFL ?!? was soll das denn bringen?? dadurch entstehen mehr polygone was hat das denn für einen sinn

wenn bei der teilung mehr polygone entstehen, dann wird es auch ruckliger (meiner logik nach)

Besteht der Zaun aus Blöcken? Solche Dinge musst Du aus Modellen erstellen, das erhöht die Portalanzahl nur sinnlos und frisst enorm viele fps.

MFG,
Punker.

die zäune sind natürlich aus modellen -.- und außerdem haben alle modelle mipmaps und sind lowpoly

Wenn Blöcke ineinander sind, dann hat das den selben effekt wie "csg Substract" d.h. es entstehen viele unnötige einzelblöcke (Wie man ja auf deinem Screenshot sieht). Deshalb solltest du selbst mehr Blöcke verwenden und dafür dan aber aufpassen, das es keine Überschneidungen zwischen Blöcken gibt.

8000 Portale sind auch viel zuviel für dieses Level. Wenn Du den BSP-Tree nicht sehr gut nutzt, sind mehr als 1000 Portale schon gefährlich.

Scaliere mal dein gesamtes Level zu testzwecken runter. Weiß zwar nicht wieso, aber das spart auch FPS ein.

MFG Dark_Samurai

Moin,
haste auch vllt mal daran gedacht alle Seiten eines Blockes (bis auf die der Spieler sieht) auf den Flag "NONE" zusetzen? Damit kannste auch ein wenig deine FPS erhöhen. Und noch was zum Editor:

Ich selbst benutze den Editor auch nicht da ich von Counter-Strike Mapping zur Spieleentwicklung gekommen bin. Ich nutze schon seit mehr als 3 Jahren den " Valves Hammer Editor" (Keine Werbung xD). Von daher kannste auch auf andere Editoren zurückgreifen wenn du mit dem von GS nicht klar kommst. Nachteil anderer Editoren wie z.B. Valves Hammer Editor , du hast keine Prefabs wie z.B. Trapeze, Pyramiden etc. das musste dann schon selber mitm Vertex Tool machen aber ich denke mal das dies das kleinste Problem werden wird...

cYa Angel

lad doch mal dein Level hoch, dann können die anderen
genauere Tips geben.

also: die ganzen grauen blocke werden noch bearbeitet. ich habe sie nicht ausgeschnitten oder so, sondern ich habe immer neue blöcke reingesetzt, um die stadt ersteinmal zu schließen. dann wie man echt deutlich sieht, habe ich die flächen, die man nicht sieht auf "none" gesetzt. ja und kann mir mal bitte einer erklären, wie sich die fps verbessern soll, wenn ich meine blöcke (wo einer 8 polygone hat) in 16 oder 32 polygone aufsplitte - verbessern soll?? also ich meine damit "Firoball"

hochladen dauert mir zu lange, weil ich modem habe und ich müsste da 40mb hochladen.

mfg zSteam

Wenn du unsere Hilfe brauchst, ist es ein denkbar ungünstiger Zeitpunkt dein Ego raushängen zu lassen! Firoball hat recht, außerdem würde ich mir mal die Level Design Tipps im Manual durchlesen (Map Design in Suche eingeben und gleichnamiges öffnen). Da steht in groben Zügen drinnen, wie der Mapcompiler arbeitet.

MFG Dark_Samurai

Weil sich ungünstige Schnittstellen auf größere Blöcke viel extremer auswirken als auf kleine Blöcke.
Es wird nicht nur die Darstellung langsamer, sondern es dauert auch erheblich länger, daß das Level gebuidlet wird - ohne Vorteil!
Die Blöcke werden sowieso nochmal unterteilt - abhängig von der Texturskalierung.
Deswegen zeigt auch eine Skalierung von 0.5 deutliche Einwirkungen auf die Framerate im Gegensatz zu ner Skalierung von 1.

Die Anzahl der Polygone allein ist nicht das Ausschlaggebende. Da gibt es so einige Sachen, die mitspielen.

Aber das wußtest du, der nach Hilfe frägt, diese aber nicht annimmt sicher sowieso schon.
Was mach ich mir überhaupt die Mühe, um dann nur angepöbelt zu werden..?

wenn dein level schon gezipt und unkompiliert 40MB verbraucht
(warscheinlich die Texturen)
dann solltest Du mal schauen on deine texturen nicht ein wenig zu groß sind.

mach es so das alles was Ingame nicht gesehen wird unsichtbar. Also setze bei dem Texture Flag stat shadert none. Das macht einiges aus. das wird in jedem Gute spiel wie Half Life 2 oder CS Source auch gemacht.

Nicolas_B: wie ich schon gesagt habe und wie man auf den fertigen gebäuden sieht, habe ich nicht sichtbare flächen auf "none" gesetzt.


Hmm ok, ich wusste nicht, dass der compiler anders arbeitet als meine logik => entschuldigung für meine beleidigungen.

ich werde mir die manual anschauen und mein level warscheinlich umbauen. falls ihr noch bau-tips habt, die nicht im manual stehen, wäre ich für jeden tip dankbar.

ach und warum gehen die fps runter, wenn ich lowpoly modelle auf weite entfernung sehe? ich habe doch mipmaps drin

hmm also ich bin nicht viel schlauer geworden und meiner meinung nach habe ich auch so gebaut wie es da steht: ", und arbeiten Sie mit möglichst dicken Blocks", "Wenn Sie eine große Map brauchen, z. B. für eine ganze Stadt, benutzen Sie Blocks für grobe Strukturen wie Gebäude, und Entities oder Detail-Blocks für Details wie z. B. Laternenpfähle."

ich habe meine blöcke immer ein ganz kleines stückchen ineinandergeschoben, damit keine löcher entstehen.

ich weis nicht was ich falsch mache

Hi,

"ich habe meine blöcke immer ein ganz kleines stückchen ineinandergeschoben, damit keine löcher entstehen."

oMg willst uns jetzt verarschen oder? Es wurde doch gesagt das bei "Überlappenden" Blöcken oder bei Blöcken die mit "CSG Subtract" wurden, Portals enstehen!!!!!
Wenn du ICQ hast add mich mal dann brauchte net immer in dieses Forum zuposten wenn es nicht allzuwichtig ist!

cYa Angel

Bitte nicht ausfällig werden.

Stell´ den Snap im WED niemals kleiner als auf "8" - sonst gibt´s Probleme. Am besten benutzt Du dann "Face Move" (rechts neben "Move, Rotate, Scale") um die Blöcke nahtlos aneinander zu setzen.

Outdoor Level baut man aber nunmal am besten aus Modellen, da der BSP - Tree hier nichts bringt.

hi
bei welchem Update ist diese automatische Umwandlung von Blöcken in Modell geplant ?

THX

na dann werde ich mal mein ganzes level umbauen

wenn ich meine blöcke als modelle mache, dann bekomme ich die texturen aber nicht so schön hin wie im wed oder kennt da jemand ein super einfaches programm ?

mfg zsteam

In der aktuellsten Beta (6.51) wird die Textur mit übernommen - ich habe es ausprobiert. Im nächsten Update wird diese Möglichkeit also vorhanden sein.

Wow, da war Conitec aber schnell! Das wurde doch erst vor kurzem vorgeschlagen.
Oder meinst du jetzt den WED Export?

MFG Dark_Samurai

Man kann von WED nach MDL7 exportieren. Wenn man die MDL Datei dann mit MED öffnet befinden sich die Texturen auf dem Modell und das Mapping wurde übernommen.
Umgekehrt kann man auch MDL nach WMB importieren. Das habe ich aber noch nicht getestet.
Und wir werden etwas OT...

hi
eine Frage: Ich habe das so verstanden das fertige Level mit WMP/WMB Blöcken beim compilieren in Models umgewandelt werden, um die Gescheindigkeit zu erhöhen.

Wie meint ihr das mit dem Import in MED? Den Block in MED laden und als Model abspeichern ?????
Dann müsste ich ja bei einer ganzen Burg das gesamte Level in MED laden.

Geht das auch autom. wie ich es oben beschrieben habe, oder muss ich jeden Block slebst umwandeln ?

Thx

Das geht jetzt offiziell noch gar nicht. Es ist ein Feature welches gerade getestet wird.

Man könnte dann z.B. ein ganzes Level oder eine Map Entity als Modell aus dem WED exportieren. Der neue MED unterstützt sogenannte Gruppen. Jede Gruppe hat ihr eigenes UV-Mapping und ihre eigene Textur, die auch ausgelagert sein kann.

Das Flag im Compiler ist etwas anderes: Hiermit wandelt der Compiler die Blöcke in Modelle um - in der wmp Datei und im WED sind es natürlich nach wie vor Blöcke.

Im DevMaster.net wird das Gamestudio in der 3D Engine Database unter den kommerziellen Engine in den Top10 auf Platz 3 gelistet. Platz 2 für Truevision
und Platz 1 für Torque.
Ich persönlich bin mit der Gamestudio-Engine sehr zufrieden...verwende aber auch nur Modelle.

Der Link zum DevMaster.net www.devmaster.net

Mit dem neuen Renderkernel, Scenemanagement, automatische LOD-Berechnung, GameEdit!!!,... Sollte A6 bald in der Lage sein, seine Position zu verbessern.
Ich sehe A6 schon bald neben der Unreal Engine...
Ich persönlich finde A6 einfach nur geil und sonst nichts, also weiter so!

MFG Dark_Samurai

Ist denn die Automatische LOD Berechnung schon in der Beta?
und wenn, wie ist die Qualität?

Sie ist schon in der Beta. Die Qualität ist, was organische Modelle betrifft, recht gut. Zuviel will ich aber nicht verraten.

Ja, die neuen Features sind vielversprechend. Das Umwandeln der Blöcke in Modelle erhöht die Geschwindigkeit und ermöglicht dann auch Arbeiten mit Shadern. Wollen wir nur hoffen, dass der tolle Schattenkompiler dann ebenso gut arbeiten und auf alle statischen Maps angewendet werden kann. Conitec hat das jedenfalls geplant.

Zum Thema: Ein Outdoor-Level würde ich auch nie aus Blöcken aufbauen, jedenfalls nicht mit der aktuellen Version. Wie es später mit dem adaptiven Binärtree ist, weiß ich nicht, der könnte evtl. sogar Outdoors beschleunigen. Aber BSP bringt nur was, wenn Du geschlossene Räume hast. Wenn Du also bestimmte Stadtviertel in einem eigenen Raum baust und durch einen Tunnel zum nächsten Viertel fährst, könnte sogar BSP was bringen.

Modelle mit Mipmaps haben immer noch die gleiche Anzahl an Polygonen und haben sogar mehrere Texturen gleichzeitig im Arbeitsspeicher. Der Vorteil der Mipmap ist halt nur, dass der Speicher der Grafikkarte geschont wird (nicht der Arbeitsspeicher des PC) und dass es besser aussieht (keine verrauschte Textur).

Frank

jo noch ein kommentar zu mipmaps: graka muss nicht mehr so große texturen auf die entfernung darstellen

was mein level betrifft: ich habe die 8000 portale auf 2226 bekommen und die fps auf 38 von der selben position - dank eurer hilfe.

jetzt muss nurnoch die neue technologie von conitec rauskommen, und alles läuft hoffentlich "fludschi" ^^. aber mit der behauptung, dass 3dgs langsam ist, habe ich trotzdem recht. an sich ist sie ja garnicht so langsam, aber wenn man die a6 gegen die source engine antreten lässt, dann sieht man wie langsam sie wirklich ist. ich nehme die source engine, weil die a6 fast die gleichen funktionen hat wie die source engine.

Wäre die a6 für schnellere pc's optimiert, dann würde auch die a6 viel besser sein. ich sag nur: "P3-500, 128 MB RAM, CD-ROM, Joystick, 3D Video Karte (16+ MB)," - ja das sind die systemanforderungen von 3dgs - wer mit soeinem teil noch "rumgurckt", der hat bei 3d-spieleprogrammierung nichts zu suchen.

Wenn man ein Fahrrad für 99,- gegen eine Rennmaschine für 9999,- antreten läßt, erweist sich das Fahrrad auch als langsamer...
Warte mal den überarbeiteten A6 Renderer ab...

Es ist durchaus moeglich, mit A6.31.4 effektiv mit BSP Geometrie zu arbeiten, wenn man diese richtig einsetzt.

Ich moechte dir im folgenden Ausschnitte aus einem reinen WMB Outdoor-Level zeigen.
Ich habe _kein_ Terrain verwendet und alle insgesamt 12 Gebaeude sind begehbar!
Das Level hat insgesam - 2500 - Portale, WMB Groesse ~19 MB.

Ein Test, die Flache Kollisionsgeometrie druch ein Modell aufpeppen:


Wie zu sehen ist, Gebaeude und Landschaft komplett WMB, Dekoration aus Modellen:


Deutlich sichtbar, die Landschaft ist eher simpel (so sollte WMB eignesetzt werden), dann kann man auch noch zusaetzliche Effekte bedenkenlos einsetzen:


Hier der WMB-Schatten nochmal gut zu sehen:


Zaeune, Tische, Pflanzen ect. aus Modellen:


Wenn man bedacht vorgeht, kann man auch durchaus komplexere Strukturen bauen wie diese Holztraeger:


Landschaftshintergrund einsetzen damit alles nicht so kahl abgeschnitten wirkt (der Fluss endet in einem Wasserfall):


Von einer kleinen Hochebene, recht oben im Eck kann man noch das Dorfzentrum sehen, das Design liegt im Detail, die paar Graeser wirken sehr viel verglichen mit einem platten rein-Textur-Boden:



Allerdings bevorzuge ich in der A6.31.4 eine noch performance-staerkere Kombination.
Unter anderem unter dem Gesichtspunkt, dass WMB bauen sehr angenehm ist.

Wie in folgendem Bild zu sehen, beschraenkt sich die WMB Geometrie auf das Gebaeude so wie unsichtbare Kollisionsbloecke, Terrain, Dekoration oder Holzplanken, alles schnell rendernde Modelle.

In diesem Screen habe ich mit meinem alten Athlon 2.200+ und Radeon 9600 noch gute 50 FPS. Gerendert wurden knapp 7000 Modell-Polygone und nur ~150 WMB Polygone, man bedenke dass hier noch der Programmcode fuer ein ziehmlich weit entwickeltes Spiel im Hintergrund laeuft.


Die Begehbarkeit von Gebaeuden wird ueber extra-Levels fuer das Gebaeude innere Geregelt und spart damit noch weitere Performance:



Alle screens unter A6.31.4 oder weniger!

das sieht echt sehr gut aus, aber kannst du noch die fps zeigen, wenn du von einem ende des level zum anderen schaust?

ps.: mit der gleichen sichtweite wie auf den screenshots bitte

Ueber das ganze Level?

Ich gestehe damals war ich noch nicht so erfahren, man konnte zu viel sehen, eigentlich muss man, wie schone rwaehnt, dafuer sorgen, dass nicht zu viel zu sehen ist.
Aber das kann ich so nicht sagen, es ist sicher 3 Jahre her, dass ich das gebaut habe, inzwischen kann ich das nichtmehr testen weil ich versehentlich mal eine wdl gegrillt habe.
Ausserdem kann man unsere beiden Rechner nicht vergleichen, zumal ich damals eine noch schlechtere Graka hatte.

Wesentlich ist aber, dass es ein Komplettes Dorf mit Gebaeuden und Landschaft ist und 2500 Portale braucht, wohingegen du bei grob einem Haus und etwas blockfoermiger Umgebung bereits bei 8000 warst.

Das Level sollte dir in erster Linie zeigen, wie man Levelgeometrie einsetzen sollte, daher auch der vergleich zum besseren aufbau in den letzten beiden Screens.

Wenn du weisst, wie Protale entstehen und wie du sparsam bauen kannst, dann kannst du Levelgeometrie gezielt einsetzen.

Wichtig ist beobachten von professionellen Spielen, wenn man die genau beobachtet sieht man naehmlich wie eben erwaehnt, dass man eigentlich nichts sieht.
Die Sichtweite ist immer sehr begrenzt und wenn man ganz genau schaut erkennt man wo und wie LOD zum tragen kommt oder wie wenige Polygone/ was fuer kleine Texturen eingesetzt werden an Stellen/ Entfernungen worauf man normal eben nicht achtet.

Es ist zugegeben eine Gratwanderung fuer die man einiges an Erfahrung sammeln muss.
Ich habe die einfachste Loesung gewaehlt, naehmlich die Isometrik.
Ich lasse in den WMBs keine Visibility Berechnung machen und schalte von Hand alles NONE was sowieso nie sichtbar wird.
Das kann man bei Isometrik machen, denn zwischen Kamera und Spielermodell wird sowieso nichts groesseres sein was ausgeblendet werden koennte/ muesste.

Ansonsten hilft nur Nebel und Clipping sowie verschachtelter Aufbau der den Blick schnell blockiert zusammen mit der Visibility Berechnung, weswegen sich der BSP Tree egientlich hervorragend fuer Indoor Bereiche eignet.

Ganz wichtig wie erwaehnt sind letzlich auch die Scripte.
Ein Beispiel, je mehr Objekte sich im Level befinden, je mehr geometrie darin ist, desto laenger braucht jede einzelne Trace oder Move Anweisung.

Sprich ab gewissen Levelgroessen reicht auch LOD nicht aus sondern Objekte muessen wirklich dynamisch geladen und entfernt werden.

Das hat in der Karte bei den letzten beiden Screens 10 bis 40 FPS gebracht, obwohl die geleoschten Objekte alle weit ausserhalb des fuer die Kamera sichtbare Bereiches waren.


Nachtrag:
Setz' in ein beliebiges Level einen breiten Block mit NONE Flag rundherum und lass es mit Visibility Calculation durchrechnen.
Wenn du um den Block herum gehst, wirst du sehen (da er durch NONE ja durchsichtig ist) wie dahinter liegende Levelbereiche verschwinden.

Noch was zu Levelblocks:

Blöcke, die nur dazu dienen, die Szenerie zu verfeinern und für die Kolission nicht relevant sind, können als Detail Blocks ins Level gebaut werden.

- in meiner stadt sind ja jetzt nur noch knapp 2000 portale

- ich würde aber trotzdem gerne erfahren, was der fps durchschnitt ist. bitte poste ihn

- ach meine version ist die 6.4 commercial

Stimmt, besonders beim steigenden aufkommen der LCDs die eh nur 60 Herz darstellen, da is jede hoehere Framerate fuer'n A****.

Ich kann keine "Durchschnittliche Framerate" angeben aus diversen Gruenden.

1. Das Script zum Level is verheizt -> laeuft nichtmehr
2. Durchschnittliche Framerate? Was solld as sein? Das waehre im Grunde von jeder einzelnen position in jedem Winkel (Pan/ Tilt) schauen und die Framerate notieren und am Ende eine Durchschnittswert bilden.

Klar hat es eine scheiss Framereate wenn man vom einen ende zum andere schaut.

Aber wieso?

WEIL MAN ES KANN!! (BSP-Tree sinnlos)

-> Schlechter Levelaufbau trotz sparsamem Portaleinsatz.

Zudem kein LOD o_O

Und wenn man fuer den Boden ein Terrain, fuer die Gebaeude Modelle, fuer die Gebaeudekollsition enifache "NONE" WMBs mit normalem ent_move verwendet hat man eine endgeile Framerate, gerantiert!

Kann ich nur bestätigen. In Dexon Knight habe ich Outdoor Levels erstellt, die recht groß wurden und hunderte von Pflanzen, Gräsern, Häusern, Characteren und Sprites nutzen, da ist Multitexturing für das Terrain und eine Menge Skripte. Das alles läuft sogar auf meinem alten Test-Rechner mit GeForce2MX (die kann nicht mal Shader 1.x).

Selbst Höhlenlevel baue ich aus Modellen, die wie ein Baukastensatz zusammen gesteckt werden, die per Clipping und Nebel in der Ferne ausgeblendet werden und damit keinerlei Blöcke brauchen.

Blöcke sind bisher so langsam, dass selbst diese auf None gesetzten Blöcke für die Kollision das System verlangsamen und zu zeilenweisen Verzerrungen der Bilddarstellung führen.

Aber das wird sich ja bald ändern, wenn der neue adaptive binary tree kommt.

Wann soll der "Adaptive Binary Tree" denn kommen? im nächsten Update? Und das Importieren der Map-Entitys + Texturen auch vllt im nächsten Update?

cYa Angel

Soweit ich weiß, funktioniert es (teilweise) jetzt schon, aber wann es öffentlich kommt, weiß niemand. Hängt davon ab, wie gut die Lösung mit den Schatten wird, ob es viele Fehler gibt, was der Beta-Test bringt. Könnte ja mit 6.6 kommen oder dann erst mit A7.

Abwarten und Modelle bauen

hat da wer... "schatten" gesagt? *sabber*

Die Shadow Map wird natürlich übernommen, wenn man die Blöcke zu Static Meshes compiliert.
Die Framerate stieg in einem Testlevel auf meinem Rechner von 28 auf 45 fps... (AMD 1300+, 64MB Grafik, 256 MB Ram)

Noch ist das ganze aber ein Beta Feature, wir werden sehen, was davon ins nächste Update kommt.

Ach ja, schon gesehen....? ---> http://www.conitec.net/beta/path_spline.htm
Conitec an die Weltmacht!

ahhhhhhhhh fett! gr8!