"failed to create vertex buffer"

  • Hallo zusammen,


    leider bekomme ich bei manchen Routen, beim Erstellen eines Szenarios, jedesmal den Fehler "failed to create vertex buffer"


    Meine Hardware:
    Intel DualCore 2,6GHz
    Nvidia GTS250 512MB RAM
    2GB Hauptspeicher


    Ich habe schon alles mögliche versucht:
    -deaktivieren der Pixel Shader
    -verschiedene Pixel Shader Versionen erzwingen
    -niedrigste Settings im Spiel


    Allerdings alles wirkungslos. Den Spezifikationen nach sollte meine Grafikkarte Pixel Shader 4.0 können, sollte also Pixel Shader 2.0 auf jeden Fall packen, daran sollte es also nicht liegen.


    Hat jemand von euch Erfahrungen mit dem Selben Fehler, oder womöglich eine Lösung parat?
    Bin für jeden Hinweis dankbar.


    Viele Grüße,
    Oli716

  • Hi Jim Kirk,


    danke für die Tipps.
    -Grafikkartentreiber aktuell 285.irgendwas
    -DirectX aktuell
    -PhysX aktualisiert, war wohl alt
    -lokale Dateien mit Steam überprüft, wurden auch einige aktualisiert komischerweise


    Aber immer noch derselbe Mist.


    Weiterhin für jede Idee dankbar.

  • Hi Oli,


    steht da in der Fehlermeldung nicht noch mehr?


    Ich hatte glaube ich eine ähnliche Fehlermeldung, bei mir ging es nachdem ich den \Steam\SteamApps\common\railworks\dev Ordner umbenannt habe in z.B. dev_old. Danach habe ich
    die Installationsdateien überprüfen und reparieren lassen(wie unter punkt 1 in Jim Kirks Beitrag). Dort wurde dann der dev Ordner neu geladen. Irgendwie mochte der RW3 die Daten nicht mehr, die ein User hier zu Anfang des RW3´s
    im Dev geändert hatte.

    Ironie, die


    feiner, verdeckter Spott, mit dem jemand etwas dadurch zu treffen sucht, dass er es unter dem augenfälligen Schein der eigenen Billigung lächerlich macht. (Duden Online)

  • Hi Ingvar,


    habe ich direkt ausprobiert, allerdings keine Änderung bekomme immer noch die Meldung:
    ERROR:Failed to create vertex buffer
    FILE:DxCommon\cHcVertexManagerDx.cpp (das Smiley soll nen D sein)
    LINE:1209


    hoffe die Info hilft weiter, ärgert mich gewaltig der Fehler.
    Grüße,
    Oli

  • Bei der Fehlermeldung gibt es leider kein Allheilmittel. Es scheint aber so, als wären fast nur 32bit Systeme betroffen. Bei einigen hat da der 3GB Switch geholfen. Würde bei dir aber nichts bringen, da du nur 2GB RAM hast.
    Generell ist das auch ein bisschen wenig und ich würde dir eine Arbeitsspeichererweiterung empfehlen, unabhängig von Railworks.


    Hast du dich schon an der Support von RSC gewandt?


    Gruß, Jim

  • Hi Oli,


    ich stimme da Jim Kirk zu, wende Dich mal an den Support, die sollten ihre Software am besten kennen.

    Ironie, die


    feiner, verdeckter Spott, mit dem jemand etwas dadurch zu treffen sucht, dass er es unter dem augenfälligen Schein der eigenen Billigung lächerlich macht. (Duden Online)

  • Ich hatte auch teilweise Vertex-Buffer-Probleme.
    Warum schreibe ich in der vergangenheit?
    Nun,... ich bin dahinter gekommen, an was es liegt. Zumindest bei mir.


    Zunächst mal muss ich mich bei Holzlaender entschuldigen.
    Ich hatte nämlich den Verdacht, dass es an seinen Hektometertafeln liegt, weil der vertex-Buffer-Error immer dann auftrat, wenn ich seine Tafeln verschob, weil ich sie z.B. an einen Oberleitungsmast nieten wollte.
    Ich baue oft zu unterschiedlichsten InGame-Tages- und -Jahreszeiten.
    Da kommt es dann bisweilen vor, dass die Sonne im Spiel tief am Himmel steht. Wenn nun die Seite des Masts, an den ich die Tafel festpinnen will, von der Sonne abgewendet ist (Abend: Ostseite des Mastes), dann neige ich dazu, die taschenlampe einschalten zu wollen. Dasselbe gilt auch für das Setzen von Tafeln innerhalb von Tunnelröhren oder unter Brücken, wo es etwas dämmriger ist.
    Und was passiert dann bei eingeschalteter Taschenlampe? "SBH: Cannot create Vertexbuffer"
    Das passiert natürlich nicht immer. Das geht bei 5 Tafeln gut, das geht bei 10 Tafeln gut, aber irgendwann knallts.
    Es scheint, dass die Taschenlampe unsauber programmiert ist und einen Memory-Leak verursacht, der dann dazu führt, dass kein weiterer Vertex-Buffer angefordert werden kann, also dass sie benutzten Grafik-Speicher nicht vernünftig freigibt.
    Ich habe das jetzt lange beobachtet und in meinem Fall ist es jedenfalls die Taschenlampe.
    Die gelegentliche Benutzung der Taschenlampe bei einzelnen Objekten scheint unschädlich, wenn man z.B. einen Brückenpfeiler im Brückenschatten vernünftig ausrichten will. Aber solche Massenausrichtungen wie Hektometertafeln scheinen durch Hochschaukeln den Crash zu verursachen, so dass ich bei eingeschalteter Lampe teilweise nicht in der Lage war, 20 Tafeln am Stück zu setzen ohne dass mir der TS abrauchte.


    Nachdem ich nun die Verwendung dieser Lampe vermeide, kam dieser Fehler nie wieder vor.


    Ich hoffe, dass dies für den einen oder anderen hilfreich ist, der ebenfalls davon geplagt ist.


    Edit:
    Habe übrigens Win7/64Bit mit 16GB Ram

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Bei mir war es so, dass diese Fehler wohl wegen zu geringem Arbeitsspeicher auftraten. Ich bin fast nur in selbsterstellten Free-Roams unterwegs, bei denen ich die jeweils komplette Strecke mit viel bis sehr viel Rollmaterial ausstatte. In städtischen Bereichen, wo sich dann viel Rollmaterial auf kleinem Raum befindet und zudem natürlich auch jede Menge Gebäude stehen, genehmigt sich der TS gerne 3 - 3,2 GB Ram. Wenn ich von dort auf den Desktop zurückgekehrt bin (egal, ob mit Alt-Tab oder Win-Taste) und später wieder zurück ins Spiel wollte, gab es sporadisch dann einen solchen 'Vertex buffer'-Fehler, etwa in 3 von 10 Fällen.
    Seitdem ich den Arbeitsspeicher dezent von 4 auf 6 GB erhöht habe, kam ein solcher Fehler nicht mehr vor. Aus dem Spiel heraus hatte ich allerdings nie mit diesem Fehler zu tun.

  • Meine Beobachtung dieses Fehlers (den ich - wenn ich nicht aufpasse - auf meinem 32-Bit XP auch ständig habe) geht dahin: Der Vertex-Buffer hat (zumindest auf 32-Bit-Systemen) sehr begrenzte Kapazität. Wenn man Objekte platziert, die mit der Track Database (Tracks.bin) zu tun haben (nicht Schienen, sonder alles drumherum: Signale, Hektometertafeln, alles Zeugs, was ans Gleis gelinkt wird) sollte man schon nach einem Objekt auf F2 - speichern - drücken. Dabei wird der Puffer offenbar reinitialisiert. Denn wenn man das macht und in Kauf nimmt, dass bei großen Tracks.bin der Speichervorgang mal gut 8-10 Sekunden dauern kann, tritt der Fehler nicht mehr auf. Die 10 Sekunden nehme ich "gerne", besser alles jedesmal den ganzen Rammel neu starten. Mein nächster Rechner wird daher wohl ziemlich sicher 16GB RAM haben und 64Bit-Windows...


    Viele Grüße
    Jan

  • Hallo, ich habe heute im Editor meine Strecke erweitert und plötzlich ist das Spiel eingefrohren und lief nicht weiter.
    Als ich danndie Windowstaste gedrückt habe hat sich das Spiel minimiert und eine Fehlermeldung erschien: ERROR: Failed to create vertex buffer (E_OUTOFMEMORY) FILE: DxCommon\cHcVertexManagerDx.cpp LINE: 1219
    Und es kommt immer wieder. ?(


    Kann mir jemand bitte bei diesem Problem helfen?
    Danke im Vorraus *=)*

  • Hallo Freekill,


    das ist ein typischer Editor-Fehler. Die Meldung kommt sehr gern und oft, wenn man Objekte mit der Maus bewegt, die einen Streckenbezug haben, wie zum Beispiel Hektometersteine oder die Tafeln für den Prellbock. Da hilft leider nur, alle 3-4 Objekte zu speichern.


    Dirk

    Einmal editiert, zuletzt von Prelli () aus folgendem Grund: Moderator-Edit: Einen Satz gelöscht, weil durch Verschiebung hierher Kontext verloren und nicht mehr zutreffend

  • Genau!
    Exakt meine Beobachtung, vor allem bei Hektometertafeln.
    Bei mir trat das Problem vor allem dann auf, wenn ich dazu noch die Taschenlampe aktiviert hatte. Seither ich die auslasse, hatte ich bislang keinen dieser Vertexbuffer-Fehler mehr. Es mag allerdings Zufall sein, natürlich.



    @Freekill:
    Bitte künftig Suchfunktion bemühen.


    Beiträge 11 bis 13 hierher verschoben, weil ursprünglicher Thread komplett andere Thematik behandelte.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Genau. Und nach meiner Ansicht ist das die Taschenlampe schuld, aber komischerweise nur in Verbindung mit Objekten der Gleisinfrastruktur.
    Wenn das noch jemand bestätigen könnte, hätten wir einen Schuldigen dingfest gemacht und könnten alle diese Kombination meiden.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • Aha?
    Bei den WOP-Hektometersteinen hatte ich das übrigens nie, nur bei Holzlaenders Hektometertafeln.
    Ob nun Sh0- oder Sh2-Tafeln davon betroffen waren, kann ich nicht mehr sagen.
    Ich denke aber mal, dass wegen der erhöhten Anzahl an Hektometertafeln gegenüber Sh0- und Sh2-Tafeln die Wahrscheinlichkeit höher war bei mir, dass es da eher zu 'nem Crash kam.


    Ob das nun wirklich an Holzlaenders Tafeln liegt, kann ich mir eigentlich nicht vorstellen, denn mir scheint, dass "Holzi" schon weiß was er tut.


    Ich werde mal 'nen Monitor mitlaufen lassen, vielleicht bringt der Aufschluss z.B. über den VRam-Verbrauch. Wenn der gegen die Decke läuft, weil benutztes und dann nicht mehr benötigtes VRam nicht mehr freigegeben wird ("MemLeak") ist klar, dass es dann irgendwann knallt.


    Nachwievor habe ich die Taschenlampe stark im Verdacht, aber vielleicht verstärkt sie das Problem ja auch nur.
    Ich halte jedenfalls einen "MemLeak" für den wahrscheinlichsten Grund dieses Fehlers: Alloziert, benutzt, nicht (vollständig) freigegeben ----> VRam voll ----> Fehler: "Kann keinen Vertex-Buffer (mehr) anlegen." ---> PENG

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.

  • naja, bisweilen hilft es nicht, das Problem zu ignorieren.
    Da muss man eban halt mal den Diagnostiker oder Tester in sich aufwecken, sonst wird man ja bekloppt.
    Auf die Art und Weise weiß ich jedenfalls inzwischen ziemlich gut, was ich dem Editor und meiner Kiste zumuten darf, und was nicht und mit der Zeit wurden die Crashs immer weniger, nicht weil ich die Missstände behob (das geht meist garnicht), sondern weil ich durch schmerzliche Erfahrungen lernte, gewisse riskante Tätigkeiten oder riskante Konstellationen zu umschiffen.
    Das ist halt ein Entwicklungsprozess.


    Ich erinnere mich daran, dass ich mal ein ziemlich langes Stück Loft markierte und mit "v" oder "b" heben/senken wollte. Das markieren der zahlreichen Loft-Segmente klappte super, aber als ich sie dann heben/senken wollte, flog der Editor mir rechts und links um die Ohren. Nach bisschen nachdenken war vollkommen logisch, was passierte: Das markierte Loft verließ die Darstellungszone in ca. 1 km. Und als ich dieses Loft, was ja garnicht mehr physisch im Editor präsent war/angezeigt wurde, es dann bewegen wollte, stieg der Editor aus.
    Ich umging das dann, indem ich mich nach dem Markieren in die räumliche Mitte des Lofts begab und das Heben/Senken klappte dann anstandslos. Man hätte das Loft auch teilen können, aber das wollte ich vermeiden.


    Was ich damit sagen will... manchmal (oder meist) braucht es nicht viel, um einen Crash zu vermeiden. Dazu gehört teils das Nachdenken, teils aber auch die Erinnerung, was beim letzten mal für eine Konstellation vorherrschte, als es beim letzten mal knallte. Irgendwann ergibt sich ein Zusammenhang, der zwar nicht lösbar, aber durch Vorsicht oder Improvisation vermieden werden kann.
    Auf diese Art und Weise nagelte ich die Taschenlampe als Schuldige bei mir fest und seither "dreimal-klopf-auf-holz" kam das nicht mehr vor.
    Gute Beobachtungsgabe ist hilfreich. Also nicht nur einfach frustriert neu starten, sondern sich im Moment des Crashs neben Ärgern auch mal besinnen und nachdenken:
    Was war da grad anders als sonst? Welche Konstellation herrschte da vor? Was kann gerade passiert sein?
    Und irgendwann mal.... ganz unvermittelt, macht es klick im Kopf und man weiß ganz genau: Wenn du jetzt (Beispiel) auf das Ding da klickst, dann machts PENG.


    (Oh Gott, was'n Roman)


    Im Grunde ist der Vertex-Buffer "nur" lästig, aber er zerschießt einem wenigstens nicht die Tracks.bin und macht daraus ein unbrauchbares 0-Bytes-File.
    Da gibts nämlich noch ganz andere Bugs, die genau das tun. Und wenn man dann kein backup hat, ist die Strecke verloren: Weg! Kaputt! Unrettbar im Datennirvana abgesoffen.
    Wohl dem, der ein aktuelles Backup hat.

    Egal, wie weit Draußen man die Wahrheit über Bord wirft, irgendwann wird sie irgendwo an Land gespült.