Beiträge von Sleepy

Zitat von GameMakerXtreme

EDIT: Ich probiere mal 1.) aus: Eine riesige Plane auf die anderen Collisions zu legen und dann drüber zu rollen.

EDIT: Springt trotzdem.

Wie? Du nutzt die große Plane und es springt trotzdem ? Wie kann dass den Sein ? Dann gibt es ja im Prinzip nichts was die Kugel springen lassen kann.

Bist dir den Sicher, das dass springen überhaupt von den Cubes kommt? Wäre es vielleicht möglich, dass der Sprung durch die Rotation der Kugel zustande kommt ? Wie ein Rad was auf einer Seite eine Ecke und und alle 360grad springt das Rad in die Luft.

Ich finde musst das noch mehr eingrenzen ob das Problem an der Physik, an den Cubes oder an etwas anderes Liegt.

Solange das nicht klar ist, finde ich, brauchst du dir über Möglichkeiten keine Gedanken machen.

Du musst erstmal die Ursache rausbekommen und dass kannst nur du in dem du verschiedene dinge testest.

Zitat von Tomarr

Mir ist irgendwie aufgefallen, dass die Kugel nicht bei jedem Übergang springt, kann das sein?

Ich glaube, das liegt daran, dass es darauf ankommt, wie die Kugel auf den Quader auftrifft. Hier gibt es meiner Meinung nach nur zwei Möglichkeiten:

1. Oben (So sollte es ja auch sein)
2. An der Seite (Dort sollte die Kugel nicht aufprallen)

Ich glaube, wenn die Kugel oben auftrifft, läuft alles, wie es soll, und es findet kein Sprung statt. Wenn die Kugel vorne auftrifft, findet eigentlich auch kein Sprung, sondern ein Abprallen statt. Dieses Abprallen ist jedoch eine Vorwärtsbewegung, da deine Kugel Schwung hat.

Überprüfe doch einmal Folgendes: Deine Kugel hat eine Geschwindigkeit. Lass dir diese einmal als Print Ausgabe anzeigen. Überprüfe, ob sie während der Sprünge langsamer wird, denn das möchtest du sicherlich auch nicht.

Ich glaube weiterhin, das Problem liegt im Übergang von Cube zu Cube. Deshalb wäre es sinnvoll, zunächst einige Tests durchzuführen, um sicherzustellen, dass das Problem nicht woanders liegt.

1.Erstelle erstmal eine riesige Plane und lege sie direkt auf die Oberseite deiner Cubes. Ich weiß jetzt kann deine Kugel nicht mehr runter fallen. Aber Interessant wäre ob sie so immer noch springt. Falls das Problem noch auftritt, nimm mal die Collider von den Cubes runter.

Wenn deine Kugel auf diesem Collider normal und ohne Sprünge rollt, dann liegt es doch definitiv an den Cube Kolliders

2.jetzt machst du alle Collider von allen Cubes und Ground Objekten auf denen sich die Kugel bewegt runter.

Du erstellt einen kleinen Collider der so groß ist wie deine Cube Oberseite.

Du machst mehre davon aneinander und rollt auf denen einmal lang. Ich möchte wissen ob das Problem auch auftritt wenn sich um eine Plane statt einem Würfel handelt. (Stell dir vor du hättest keine Cubes sondern Planes)

Ich glaube dann tritt das Problem nicht auf weil eine Plane keine Vorderseite hat hat der der Würfel abprallen kann. Eine Plane hat nur eine Oberseite.

3.Wenns immer noch Probleme gibt, prüfe was passiert wenn du zwischen den Überfängen einen Collider plazierst. So quasi wie eine Brücke von Cube zu Cube.

Ich denke bekommst du mehr Kenntnisse darüber wie das Problem entsteht. Versuche auch mal, die Planes etwas höher als die Würfelfläche zu legen. quasi einen mm über dem Würfel.

Je nach Ergebnis hast du nun mehre Möglichkeiten:

1.Du könntest aus all deinen Objekten auf der die Kugel rollt die Oberen Fläche von einem Mesh lösen und daraus ein Collider machen. Du hättest dann nur noch einen Planaren Y Collider.

2.Du baust ein komplexes System:

Deine Kugel bekommt eine Triggerbox die sich mitbewegt und die mindestens eine Cubegröße größer ist als deine Cubes. (Unsichtbar für den Player)

Alle deine Cubes bekommen ebenfalls eine Triggerbox.

Du machst du eine Abfrage: Wenn die Kugeltriggerbox mit einer Cube Triggerbox Kollidiert, spawnst du über dem Cube einen Collider.

Im Grunde: Wenn sich deine Kugel einem Cube nährt, bekommt dieser Cube einen Collider. Somit bauen sich die Collider vor der Kugel auf und verschwinden wieder wenn du über den Cube gerollt bist.

Ich könnte mir auch vorstellen, den Collider etwas größer als den Würfel zu machen. Somit hast beim überrollen von Cube zu Cube wieder die Brücke. Den Collider Killst du dann, wenn die Kugel die Mitte des Würfels erreicht hat.

Somit hast du einen Übergang von Cube zu Cube und deine Kugel fällt runter wenn sie über den Rand rollt.

3. Du könntest auch den umgekehrten Weg gehen: mach dir deinen Riesen Collider der über deine gesamte Fläche geht. Du machst an den Seiten wo die Kugel runterfallen soll eine Triggerbox hin. Berührt die Kugel diese Triggerbox, wird der Collider deaktiviert und die Kugel fällt runter. So definierst du nicht über die Collider wann die Kugel fallen soll, sondern durch Triggerboxen.

Das ist 3 Varianten die mir einfallen.

Ist der Text mal wieder lang geworden sorry

Engel

Ich hab übriges dein Interview mit Valle gesehen.

Was ich persönlich seltsam finde, dass dein Projekt mit EA verglichen wird. Alleine schon der Titel des Videos: "Er dachte er kann es besser als EA"

Alleine das "Er dachte" was ja irgend bedeutet er hat es geglaubt aber es war nicht so.

Was ist den die Messlatte ? Dass dein Projekt so sein sollte wie EA ? Ich finde es sollte umgekehrt sein:

EA sollte sich an Beispiel an dir nehmen was ein Mann alles hinbekommen kann. Da frägt man sich schon wie ein riesen Studio mit Zig Entwickler ein Spiel derartig in den Sandsetzen kann und was die Entwickler den ganzen Tag machen.

Möglicherweise zu viele Meetings und zu wenig gearbeitet ?

Ich finde dass was du geleistet hast und auch wie du dich als One-Man-Show zeigst absolut Klasse.

Lass dir bitte bitte nicht einreden, du müsstest so sein wie EA sondern mach einfach so weiter und sei du selbst.

Was ich übrigens auch interessant fände, wären Entwickler Einblicke.

Vielleicht wie die ersten Protypen ausgesehen haben welche lustigen Bugs aufgetreten sind. Wo die Probleme lagen usw.

Oben hattest ja bereits geschrieben dass Virtual Texture und HISM eine große Hilfe war.

Da ich gerne die Roadmaps von verschiedenen spiele verfolge, fände solche Einblicke sehr interessant.
Aber ja dass ist mit Arbeit verbunden.

Der Clou dabei ist ja, dass entweder das eine oder andere Mesh bei einer Kollision triffst.

Grundsätzlich sind Kollisionen eine sehr rechenintensive Berechnung. Ob derartige Konstrukte zielführend sind, mag ich zu bezweifeln.

Bei Wirtschaftspielen werden Straßen über Splines gesetzt das geht nicht über Collision.

Collisions sind ja auch keine Meshes die man einfach mergen kann. Collisions sind im grunde nichts anderes als: Haben sich sich Meshes berührt. (Ja oder nein)

Oder zumindest: Wenn ja dann passiert...

Warum machst du nicht einfach ne Plane 1mm höher wie deine Cubes, diese Plane ist ein reiner Collider auf der deine Kugel rollt. Dann wäre die Sache doch erledigt.

Ich weiß halt auch nicht was du final vorhast.

Vielleicht postet du mal ein paar Screenshots

Ich glaube Tomarr könnte auch recht haben.

Deine Kugel ist auf jedenfall nicht perfekt rund und somit ist der Collider der Kugel nicht perfekt rund.

Wenn deine Kugel von einem Würfel auf einen anderen übergeht, gibt es entweder eine Kollision mit der Oberen Fläche des Würfelns oder mit der Seite des Würfels. Das dürfte davon abhängen wie deine Kugel auf den anderen Würfel aufschlägt.

Deine Kugel könnte durch die seitliche Kollision abprallen aber du hast aber ne Vorwärtsbewegung was dazu führt dass deine Kugel nach oben fliegt aber auch die Bewegung nach vorne weiter führt.

Das würde Problem mit dem Übergang der Cubes bestätigen. Wenn du statt Würfels eine Plane als Boden Kollision verwendest, sollte das Problem nicht mehr auftreten.

Ich vermute, dass liegt an der Interpolation der Kollisionserkennung. Selbst wenn deine Würfel sehr nahe beieinanderliegen, kann es zu Ungenauigkeiten (Rundungsfehlern) kommen.

1. Ich glaube nicht, dass sich das Problem durch den "Step Height" beheben lässt, da der "Step Height" eine ganz andere Berechnung betrifft und dein Problem offensichtlich mit der Physik zu tun hat und nicht mit dem Überwinden von Hindernissen.
2. Eine wichtige Rolle spielt möglicherweise das Damping (Reibung). Das Damping ist quasi der Reibungswiderstand deiner Kugel. Keine Ahnung, wie du das Damping gelöst hast, aber wenn dieser Wert bremst und du die Kugel gleichzeitig durch Drücken einer Taste beschleunigst, könnte es unter Umständen zu solchen Problemen kommen. (Das ist nur eine Vermutung.) Ich halte das jedoch eher für unwahrscheinlich.
3. Suche nach der "Collision Detection Tolerance" (Kollisionserkennungstoleranz). Damit wird die Kollision bei höherer Geschwindigkeit genauer. Ich glaube, du findest sie in den Projekteinstellungen unter "Physics" oder "Collision". Ich bin mir nicht mehr ganz sicher.
4. Auch das Substepping wäre eine Möglichkeit. Damit wird die Kollisionserkennung in kleinere Schritte unterteilt, wodurch die Kollision genauer wird. Du müsstest diese Einstellung ebenfalls in den Projekteinstellungen finden.
5. Ich weiß nicht, welchen Collider du für deine Murmel verwendest. Du könntest hierbei ein Mesh als Collider verwenden, das nicht deinem 3D-Mesh entspricht. Die Topologie könnte anders oder besser oder einfacher sein. Ich glaube, es wäre auf jeden Fall einen Test wert, einen anderen Collider zu verwenden. Vielleicht kannst du auch testen, den Collider etwas größer als das Mesh zu machen und beobachten, ob das Problem dadurch besser wird?
6. Hat es einen Grund, warum du als Boden Cubes verwendest? Vielleicht aus ästhetischen Gründen? Warum verwendest du nicht als Boden Collider einen unsichtbaren Collider, auf dem die Kugel rollt? Dann hättest du eine flache Oberfläche. Als riesige Plane oder du könntest auch eine Collider-Plane unter der Kugel spawnen, die für den Spieler unsichtbar ist und auf der die Kugel rollt. Dieser Collider bewegt sich immer mit der Kugel mit. Wie eine Regenwolke die dem Charakter folgt

Wie Tomaar bereits erwähnte, änderst du den Pivot am BESTEN in einem 3D-Programm.

Im Marketplace gibt es auch einige Tools, mit denen du Pivots ausrichten kannst.

Zum Beispiel hier: https://www.unrealengine.com/m…/en-US/product/pivot-tool

Allerdings möchtest du den Pivot nicht immer nur in der Mitte oder unten haben. Bei einer Tür sollte der Pivot beispielsweise am Scharnierdrehpunkt liegen.

Es gibt eine wichtige Sache, die du über Pivots wissen solltest:

Ein Mesh hat einen Pivotpunkt, der normalerweise unten und in der Mitte liegen sollte. Ein Mesh kann jedoch auch in einer Gruppe sein. In Blender werden diese als "Locator" bezeichnet, soweit ich weiß. Diese Locator haben ebenfalls Pivot-Positionen.

Du kannst also überlegen, ob du den Pivot des Meshes ändern möchtest (was ich normalerweise nicht tue), oder ob du das Mesh in eine Gruppe packst und den Pivot der Gruppe änderst.

Mit der Gruppe kannst du mehrere Objekte in diese Gruppe packen und dann die gesamte Gruppe drehen, anstatt jedes Mesh einzeln zu bewegen.

In deinem Fall könntest du es so machen:

1. Du setzt den Pivot deines Meshs auf den Mittelpunkt.
2. Du packst das Mesh in eine Gruppe.
3. Der Pivot der Gruppe wird auf Mitte und unten gesetzt. Somit befindet sich der Pivot am Boden des Grids.

Dann bewegst du nicht das Mesh selbst, sondern die Gruppe.

Hier ist ein Beispiel:

Unser Sonnensystem heißt "SOL". In ihm befinden sich die Sonne, der Mond, die Erde, der Mars usw.

Jeder Planet und die Sonne befinden sich in einer Gruppe. Wenn du die Erde drehen möchtest, drehst du die Gruppe "Erde" (nicht das Mesh).

Wenn du das gesamte System drehen möchtest, dann drehst du die Gruppe "Sol".

Wenn du möchtest, dass sich der Mond um die Erde dreht, sollte der Pivot des Mondes im Mittelpunkt der Erde liegen.

Durch die Verwendung von Gruppen und Meshes entsteht eine Abhängigkeit zwischen ihnen.

Glückwunsch zum einjährigen und weiterhin viel Erfolg ist echt super geworden.

Zitat von hellobomm

Ein Rechendurchgang (also ein tick) ist dann ein Frame.

Nein genau das ist ein Tick eben nicht. Ein Tick ist nicht ein Frame sondern ein Tick ist eine Zeitspanne die innerhalb eines Frames passiert

Ich mach mal ein paar Beispiele damit du die Unterschiede verstehst.

1.Nehmen wir mal an du hättest einen Timer: Ein Timer Zählt einfach nur die Zeit. Einem Time ist die Framerate völlig egal. Er tut beispielsweise etwas alle 10 Sekunden

2. Nehmen wir an du würdest ein Propeller jeden Tick einmal um 1 grad drehen. Das würde bedeuten das sich dein Ventilator einmal Pro Frame um 1 Grad dreht. (Wichtig ein Frame nicht aber nicht nur jede Sekunde gezeichnet sondern mindestens 60 mal pro Sekunde. Wohl eher noch öfter)

Mal angenommen deine Grafikkarte zeichnet 360 Frames pro Sekunde, dann würde sich ein Propeller pro Sekunde um 360 Grad drehen.

Jetzt aufgepasst:

Mal angenommen du hast nur eine Grafikkarte die NUR 180 Frames pro Sekunde schafft, dann würde sich dein Ventilator auch nur um 180 grad pro Sekunde drehen.

Mal angenommen du hast ne bessere Grafikkarte die 720 Frames pro Sekunde schafft, dann dreht sich ein Ventilator um 720 grad pro Sekunde drehen.

oder du bekommst pro Tick einen Euro, dann würde der Spieler der die beste Grafikkarte hat am meisten Geld bekommen.

Ein Delay durch einen Tick wirkt sich deswegen auf jedem Rechner anderst aus.

Zitat von hellobomm

. Die Grafikkarte schickt dann das Bild 600 mal pro Sekunde an den Bildschirm.

Wie gesagt wenn dein Rechner lagt und der Lag 5 Sekunden dauert wird jeder Frame nur alle 5 Sekunden gezeichnet, das bedeutet deine GPU schickt alle 5 Sekunden 600 Bilder an eine GPU womit du deine GPU ziemlich bombadierst.

Außerdem sind das unnötige Drawcalls. Du schickst ununterbrochen Befehle an deine CPU bzw GPU.

Die Unreal entschiedet ja auch selbst wer Jobs abarbeiten darf. Soll es schnell gehen, macht das die GPU muss es nicht so schnell gehen, macht das die CPU. Wenn du aber GPU lastige Prozesse hast, dann kann es vorkommen dass dein GPU auf Vollgas läuft und sich deine CPU langweilt.

Hoffe du verstehst was ich meine.

Hi, bist du sicher dass das so eine gute Idee ist ?

Ein Tick ist nicht dasselbe wie ein Frame, und theoretisch kann ein Tick sogar öfter als ein Frame ausgeführt werden.

Wenn dein Spiel lagt (aus welchem Grund auch immer), wird in dieser Zeit auch kein Tick ausgeführt.

Ticks werden nur ausgeführt, wenn Frames gezeichnet werden.

Ich weiß nicht, was du vorhast; unter Umständen ist das genau so gewollt.

Ich frage mich, ob du das, was du umsetzen möchtest, auch ohne Ticks erreichen kannst?

Durch die Tick-Lösung hängst du auf jeden Fall stark von Frames ab.

Auf einem Rechner mit schlechterer Grafikkarte, würden dann auch weniger Ticks ausgeführt werden da die GPU weniger FPS zeichnet.
Das kann zu ziemlichen Performance einbrüchen führen.

Zitat von Macy

Was meinst du. Würdest du auch mit Chaos Vehicle arbeiten?

Wenn du eine ehrliche Antwort von mir möchtest: Ich bin jemand, der lieber alles selbst macht. Mit dem Modellieren, Riggen und Animieren von Fahrzeugen kenne ich mich nicht aus, das ist nicht mein Spezialgebiet.

Ich verstehe, dass Entwickler oder auch Unternehmen nicht immer das Rad neu erfinden müssen und lieber auf bereits vorhandene Tools zurückgreifen. Immer wenn ich private Projekte in Unreal umsetze, mache ich das aus Spaß, und es ist mir wichtig, dass ich es selbst mache.

Wenn man einen Strandurlaub in Italien macht, kauft man ja auch niemandem die Sandburg ab.

Es geht mir nicht darum, am Ende ein perfektes Asset zu haben, sondern es geht mir um den Weg, wie ich dorthin komme, und um die Fähigkeiten, die ich dafür benötige.

Ich hab da eine andere Einstellung als jemand der unbedingt sein Zeil erreichen will und ein gutes Ergebnis haben möchte und sich lieber Assets kauft.

Alles zusammenkaufen und in eine Szene werfen, kann irgend wie jeder.

Wenn ich dir ein Ratschlag geben darf:

Als ich vor 10 - 15 jahren mit der Spieleentwicklung angefangen hab, habe ich den selben Ratschlag von anderen Leuten gehört. Ich hab damals nicht auf die Leute gehört sondern mein ding durchgezogen. So machen es wahrscheinlich auch 99,9% die diesen Ratschlag hören.

Du hast vermutlich eine tolle Spieleidee du hast aber nicht die Skills dass ohne Hilfe umzusetzen ?

Mein Ratschlag: Erstmal kleine Brötchen baken und sich mit dem Fundament statt mit dem Dach zu beschäftigen. Klar gibts tools die ganz easy Aufgaben für dich übernehmen. Aber früher oder später wirst du auf Probleme stoßen, die du nicht lösen kannst ohne das nötige Knowhow zu haben.

Wir hatte hier schon so oft riesige Entwicklerteams mit tollen Idee. Wenn man solche Projekte umsetzen will, dann benötigt man auch das Grundwissen dazu.

Du kannst dir auch ne Boing 747 kaufen aber ohne Flugerfahrung wirst du vermutlich nicht weit kommen.

Ich hab damals auch gemeint ich bin schlauer als alle anderen Es hat jahre dauert bis ich gecheckt hab wie wenig ich eigentlich über die Materie weiß und seit dem versuche ich alles mögliche zu lernen.

So gibt es auch Fachgebiete die sind eigene Wissenschaft für sich: Für mich: Rigging, Animieren von Charakter, Cars, Sculpting uvm.

Das sind riesige Universen in den man sich besten auskennen muss um in ihnen zu entwickeln.

Das Hauptproblem: Man muss sich regelmäßig in diesen bereichen aufhalten und gut in ihnen zu sein. Ich hab einfach nicht die Zeit mich mit allem zu beschäftigen.

Wenn du 100€ für Tool ausgibst dann bist du voll motiviert bis Probleme auftreten. Dann geht deine Motivation in den Keller und du verlierst die Lust.

Damit du die Lust aber nicht verlierst, brauchst du Vorschritte und die hast du am besten in dem du dich mit leichten dingen beschäftigst statt gleich mit der Königsdisziplin anzufangen.

Ich würde an deiner Stelle mal ein Fahrzeug selber bauen. Selbst wenn erstmal nur ein Würfel ist bei dem sich die Reifen drehen und dann machst du einfach immer mehr. Wenn du Gefühl hast alles verstanden zu haben, dann vergisst du alles was gelernt hast und fängst nochmal von vorne an. Versuchst andere Workflows, andere Herangehensweisen.

Wenn du viel ausprobiert hast und du weißt was für dich gut und was für dich schlecht funktioniert, dann kannst du behaupten dass du Ahnung hast.

Ich mache das wie gesagt schon seit jahren und es gibt Bereiche in denen ich mich gut auskenne, und Bereiche in denen ich mich überhaupt nicht auskenne.

Also, wenn du solche Simulationen in Blender erstellst, kannst du sie nicht direkt in Unreal Engine exportieren.

Du musst dich entscheiden, ob du die Simulation in Blender oder in Unreal Engine durchführen möchtest.

In Unreal Engine würden die Berechnungen in Echtzeit stattfinden und könnten jederzeit geändert werden. Wenn du die Animation in Blender erstellst, erhältst du im Grunde einen vorgerenderten Film, den du in Unreal Engine importieren kannst. Die Berechnungen wären dann jedoch nicht in Echtzeit.

Falls du die Simulation in Unreal Engine durchführen möchtest, musst du auch das gesamte Physik-Setup dort erstellen. Aus Blender käme dann praktisch nur das 3D-Modell.

Was das Plugin angeht: Ich hab keine Ahnung was du vom Entwickler bekommst. Bekommst du eine Blenderdatei ? Die könntest du vermutlich in Blender bearbeiten und in die Unreal importieren. (Easy)

Wenn du aber nur die FBX bekommst, dann glaube ich, dass Anpassungen schwierig sind. Zwar dürfte das Rigg der FBX vorhanden sein aber dass als FBX zu bearbeiten, ist deutlich schwieriger als dies in der Blenddatei anzupassen.

Sollte das ein reines Unreal Projekt sein, kannst du das Fahrzeug wahrscheinlich AUCH NUR als FBX aus Unreal in Blender exportieren.

Das ist zumindest mal meine Einschätzung bei der ich mir nicht zu 100% sicher bin.

Hier ist ja jedenfalls eine Beschreibung wie man die Assets aus Blender in Unreal einbindet:

Das Vehicle Quick Setup finde mit 7 min etwas mager:

Was wohl gut funktioniert ist der Support die Leute die Fragen gestellt haben, haben schnell eine Antwort erhalten.

Nach meinem Kenntnisstand ist das verändern der Reihenfolge derzeit nicht mehr möglich. Ich weiß auch nicht ob es geplant ist dies naher Zukunft wieder einzubauen. Die Variablen müssen derzeit in der richtigen Reihenfolge erstellt werden.

Zitat von Barni

Das PersistentLevel (in dem sich wie ich verstanden habe auch kein Landscape oder ähnliches, also wirklich nichts befindet) ist im Prinzip auch nicht in seiner Größe beschränkt. Landscape kommt erst mit einem Sublevel (genauso wie Häuser oder Bäume mit anderen SL etc.).

Ne das PersistentLevel ist so wie das Weltall Unendlich. Die Idee ist eben die Sublevels in PersistentLevel zu laden.

Stell dir die PersitentLevel wie eine Bühne vor bei der ein Stück gezeigt wird.
Auf diese Bühne werden immer andere Szenarien geschoben . Karibik, Wald, Stadt usw.

Jedes dieser Szenarien ist ein Sublevel. Es gibt nur eine Bühne und das ist das PersistentLevel.

Du könntest auch Meshes in das Persientlevel machen und Sublevels dazu laden. Das könnte unter bestimmten umständen auch Sinn ergeben.

zb alle Straßen könnten sich im Persitentlevel befinden und die Häuser werden als Sublevel dazu geladen.

Das schöne ist auch, du kannst Sublevels ausblenden oder nur ein bestimmtes Sublevel einblenden.

Vergleichbar im Protoshop Layer.

Zitat von Barni

In wieweit sind diese Sublevel beeinflussbar/manipulierbar, bevor sie tatsächlich in das PersistentLevel geladen und angezeigt werden. Kann beispielsweise das Landscape durch Parameter verformt werden? Kann die Position des Landscape verändert werden?

Das ist eine gute Frage weiß ich ehrlich gesagt nicht.

Wie oben berichtet, werden die Sublevels ja geladen aber nicht angezeigt. Ich könnte mir vorstellen, dass du darauf zugreifen kannst und sie verändern kannst sobald sie geladen sind.

Ich kenne dein Gedanke nicht aber wäre nicht auch möglich das Level zu laden, anzuzeigen und dann direkt zu Manipulieren ?

Im Normalfall startest du ja nicht in einem leeren Raum und lädst dann die Sublevels und siehst dass sich dinge am Level verändern.

Nur das Terrain könnte auch auf einem Sublevel liegen.

Ja und Nein.

Man muss, glaube ich, darauf achten, dass man keine falschen Vorstellungen bekommt.

Beim Levelstreaming geht es um die Verwaltung von Levels oder Sublevels und dem persistenten Level.

Ich gebe dir zwei Beispiele, damit du es besser verstehst. Vergiss jedoch für einen Moment, was du unter einem Level verstehst.

Beispiel 1:

1. Das Persistent Level ist sozusagen ein leerer Raum, in dem sich nichts befindet. (Ein leeres Hauptlevel)
2. In dieses Hauptlevel kannst du nun Sublevels laden.
3. Ein Sublevel könnte beispielsweise ein Level sein, in dem sich NUR Häuser befinden. Ein weiteres Sublevel könnten nur Bäume sein.
4. Du könntest auch verschiedene Stadteile einer Stadt als separate Levels erstellen.
5. Bei Sublevels gibt es quasi 4 Stufen:

Stufe 1: Das Level wird geladen, aber nicht angezeigt. Das gesamte Level wird im Speicher vorab geladen. Es wird jedoch nicht angezeigt. Das Sublevel wird im Hintergrund geladen, ohne dass du etwas davon mitbekommst.

Stufe 2: Das Level wird angezeigt, sobald es geladen ist. Du lädst das Sublevel, bevor du es benötigst, um es dann auf einmal anzuzeigen. (Dieses anzeigen geschieht sofern das Level vorgeladen ist SOFORT und ohne Ladezeit)

Stufe 3: Wenn du dich aus dem Bereich entfernst, wird das Sublevel wieder ausgeblendet. Es befindet sich jedoch noch im Speicher und steht bereit, wenn es erneut benötigt wird.

Stufe 4: Das Sublevel wird komplett aus dem Speicher entfernt. (Dann muss es erneut geladen werden, bevor es angezeigt wird.) Dies könnte zum Beispiel geschehen, wenn du die Stadt verlässt und eine gewisse Entfernung von ihr erreicht hast. (Der Speicher wird hierdurch wieder frei)

Beispiel 2:

Beispiel 2 anhand eines Sidescrollers:

1. Du lädst das leere Level (Persistent Level).
2. Direkt danach lädst du das Menü in das Persistent Level. (Visuell sieht es so aus, als ob NUR das Menü geladen wurde.)
3. Während du dich im Menü-Sublevel befindest, wird im Hintergrund bereits Level 1 des Sidescrollers geladen.
4. Kurz bevor du das Ende des Sidescrollers Level1 erreichst, beginnt der PC bereits, Level 2 zu laden.
5. Wenn du das Ende erreichst, wird Level 1 ausgeblendet und das vorab geladene Level 2 eingeblendet.

Dies geschieht ohne Ladezeiten und fließend.

Diese beiden Möglichkeiten können beim Levelstreaming verwendet werden. Gelegentlich werden bestimmte Sublevels bestimmten Entwicklern zugeordnet. So arbeitet beispielsweise der Entwickler, der für die Gebäude zuständig ist, nur am Gebäude-Sublevel.

Neu bei UE5 sind nun die World Partitions. Hierbei handelt es sich um eine tatsächliche Aufteilung eines Unreal-Projekts in viele kleine Projekte. Dadurch kann jeder Entwickler in seiner eigenen Umgebung arbeiten, ohne sich gegenseitig zu beeinträchtigen. Das nur am Rande erwähnt.

Nun aber zurück zum eigentlichen Thema. Meine Idee war es, die wichtigsten Blueprints, die man immer benötigt, in einem Sublevel zu platzieren und dieses Sublevel in das Persistent Level zu laden. Alles andere lädst du ebenfalls als Sublevel in das Persistent Level. Der Unterschied besteht darin, dass diese Sublevels auch wieder entfernt werden können. Dadurch wären deine Blueprint-Sublevels (sozusagen omnipräsent) immer verfügbar und in allen anderen Sublevels präsent. Das war mein Gedanke in Bezug auf die Sublevels.

2 Dinge fallen mir ein:

1.Benutzt du Levelstreaming ?

Wenn ja, prüfe ob die Steaming Einstellungen korrekt sind. Machst du vielleicht so dinge wie Texturen beim Start zu Initialisieren, du wechselt das Level und dort sind die nicht Initialisiert ?

2.Sind deine Textur Pfade im Blueprint korrekt ?

Geb dir doch über einen Print die Texturpfade aus die geladen werden um sicher zu gehen dass die Pfade stimmen.

Es könnte sein das die Texturpfade warum auch immer beim Laden eines anderen Levels nicht mehr korrekt sind. Wichtig wäre rauszufinden auf welche Pfade Unreal zugreifen möchte.

3.Der Fehler könnte genau so gut irgend ein Fehler in einem Blueprint sein.

Es ist schwer dir zu helfen ohne genau zu wissen welchen Weg du gegangen bist.

Wie wäre zb mit Screenshots einer Blueprints und vielleicht einer kurzen Erklärung wie dein Blueprint funktionieren soll.

Zitat von leviavan

Use Seamless Travel aktiviere

Im Internet steht, das man Use Seamless Travel auch konfigurieren kann oder muss.

Hey, ich sehe mehrere Möglichkeiten:

1. Du könntest Gameinstanzen verwenden.

Eine Gameinstanz ist eine globale Instanz, die während der gesamten Spieldauer besteht und abhängig vom geladenen Level erhalten bleibt.

Du kannst Variablen und Funktionen in einem Gameinstanz-Blueprint erstellen und von verschiedenen Leveln darauf zugreifen.

(Video-Link: https://www.youtube.com/watch?v=HpLeyIszAUU)

1. Eltern-Blueprints und Vererbung:

Du könntest einen Eltern-Blueprint erstellen, der deine gesamte Logik enthält. Mit einem Kind-Blueprint kannst du dann auf den Eltern-Blueprint zugreifen und die benötigten Informationen verwenden.

(Hier ist ein Link dazu: https://couchlearn.com/parent-…rints-in-unreal-engine-4/)

1. Level-Streaming

In den meisten Fällen würde Level-Streaming bedeuten, dass du zum Beispiel ein leeres Hauptlevel lädst. Beim Spielstart wird in dieses Hauptlevel das Menü geladen. Danach wird das Menü aus dem Hauptlevel entfernt, und das eigentliche Level (z. B. Level 1) wird ins Hauptlevel geladen. Wenn Level 1 abgeschlossen ist, wird wieder ins Hauptlevel geladen. Dies geschieht ohne größere Ladezeiten, da du Level 2 bereits im Hintergrund vorladen kannst, während du dich noch in Level 1 befindest.

Level-Streaming bedeutet also nicht das klassische "Ich spiele Level 1, dann wechsle ich zu Level 2 und dann zu Level 3." Es geht vielmehr darum, viele Levels in ein einziges Hauptlevel einzubetten. Dies beinhaltet das Laden, Entladen, Anzeigen und Nicht-Anzeigen von Levels.

Du könntest Sublevels laden, die als Blueprints dienen, die niemals aus dem Hauptlevel entfernt werden und somit immer vorhanden sind. Der Rest könnte im Prinzip ausgetauscht werden.

Hier ein Link zum einem Video wo es um das Levelstreaming geht.

So wie ich das meine, wird dort nicht erklärt aber wenn du Levelstreaming verstanden hast, geht dir vermutlich ein Lich aus.

Alles Möglichkeiten haben vor und Nachteile und keine Möglichkeit ist besser wie die andere. Es kommt darauf an was du vorhast und wie sich dein Spiel zukünftig entwickelt.

Zitat von sold4t

6) Sleepy, du bist einfach toll, ich mag deine Ideen ungemein :-)... Meinst du das an einem Terminal oder ähnlich, oder direkt als Robo eine bestimmte Pose einnehmen, "Keyboard" am unterarm bedienen , oder so..?

Ein Terminal könnte sicherlich als Option dienen und gut ins Konzept passen. Eventuell ließen sich dort auch andere Aktionen, wie das Hacken von Kameras oder Bewegungssensoren, einbinden. Jedoch hätte ich Bedenken, den Roboter-Hack am Terminal auszuführen, da dies meiner Meinung nach schlecht für das Gameplay wäre. Als Spieler möchtest du wahrscheinlich, dass der Hack deines Gegners direkt vor deinen Augen stattfindet der Roboter vor deinen Augen zusammenbricht oder was auch immer und nicht an einem Terminal, wo du den eigentlichen Hackprozess nicht mitbekommst.

Hier ist meine Idee:

Der Hackvorgang erfolgt in zwei Schritten.

1. Du musst den Gegner zuerst analysieren.
2. Dann verwendest du eine Art Teaser, um den Hack in den Gegner einzuschleussen

Der Ablauf könnte folgendermaßen aussehen:

1. Du visierst den Gegner mit deiner Hacking-Pistole an und triffst ihn. Sobald du dies schaffst, wird unten in der UI der Waffe eine ID generiert. Diese ID ist rein visuell und hat keine reale Bedeutung. Sie dient lediglich als eine Art IP Adresse.
2. Ich könnte mir vorstellen das nachdem du die ID hast, in einem Radialmenü einen Hack auswählen kannst.
3. Sobald du die ID dem Hack zugewiesen hast, schießt du mit dem Teaser auf den Roboter, um den Hack zu aktivieren.

Dieser Ansatz bietet einige Vorteile:

1. Du könntest möglicherweise im Verlauf des Spiels neue Hacks erlernen und sammeln. Dadurch hättest du stets die Möglichkeit, mächtigere Hacks einzusetzen.
2. Eventuell könntest du nicht nur den Teaser mit dem Hack laden, sondern auch eine Art Falle platzieren. Wenn der Roboter dann hindurchgeht, wird der Hack automatisch ausgelöst. (Waffe Laden mit der ID oder Falle Laden mit einer ID)
3. Da die ID des Gegners gescannt wird, hätte der Gegner die Möglichkeit, seine ID zu erneuern. Wenn du auf den Gegner schießt und die ID wurde geändert, funktioniert der Hack ebenfalls nicht mehr.
4. Die ID erneuern könnte auch über das Radial Menü gemacht werden. Auf diese Weiße könnte man sich gegen Hacks wehren und letztlich gewinnt wer besser und schneller ist. Fürs Hacken und fürs ID erneuern könnte es Cooldowns geben die man skillen kann um einen Vorteil zu haben.

Ich denke so kannst du ein besseres Gameplay machen als wenn das über ein Terminal passiert. Das Problem dabei könnte nur sein, das die Usability zu komplex wird und das Hacking zu schwierig und damit Sinnlos wird. Aber das müsstest du testen.

PS.: Statt der ID könntest auch einfach hinschreiben: "Roboter [PlayerXYZ] gescannt", Hack auswählen und auf den Roboter schießen.

Ich denke, die Überlegung, die du anstellen musst, ist, wie stark der Akku in dein Spiel integriert wird.

Es gibt beispielsweise viele Filme, in denen der Kampf um das letzte Wasser oder das letzte Öl ein wichtiger Bestandteil der Handlung ist.

Wenn dein Spiel einen Kampf um Akkus thematisieren soll, dann empfehle ich, das Thema Akku vielschichtiger zu gestalten.

Hier ist ein Beispiel, wie ich es mir vorstellen könnte:

1. Statt eines einzelnen Akkus gibt es viele Akkuzellen. Es wirkt irgendwie wenig sinnvoll, wenn du deinem Gegner den Akku entnimmst und er sofort verliert. Ich finde, das sollte anspruchsvoller sein.
2. Zum Beispiel könntest du im Nahkampf nur in einem begrenzten Zeitraum eine bestimmte Anzahl von Zellen von deinem Gegner stehlen können. Du könntest dabei die richtige Taste zur richtigen Zeit drücken müssen. Ähnliche Mechaniken gab es bereits in Spielen wie Assassin's Creed, wo man durch Minispiele Schlösser knacken musste. Dabei bewegte sich etwas hin und her, und man musste zur richtigen Zeit die Taste drücken. Die Schwierigkeit konnte durch die Geschwindigkeit der Bewegung und die Präzision des Tastendrucks angepasst werden.
3. Möglicherweise könnten Waffen wie EMPs existieren, mit denen du die Akkuleistung deines Gegners verschlechtern kannst, um die Chancen im Nahkampf zu erhöhen.
4. Vielleicht könnten auch Fernwaffen vorhanden sein, mit denen du Akkuzellen stehlen kannst. Denk an eine Magnetwaffe oder etwas Ähnliches.
5. Es könnte auch möglich sein, dass du die Roboter nicht vollständig zerstören kannst, aber du könntest vielleicht bestimmte Bauteile abschießen. Diese Mechanik gab es zum Beispiel in Horizon Zero Dawn. Du konntest einem Roboter seine mächtige Waffe zerstören, um sie gegen dich nicht mehr einsetzen zu können.
6. Hacking könnte ebenfalls eine interessante Option sein. Dabei könnte ein schnelles Minispiel erforderlich sein, um sich in den Gegner zu hacken und verschiedene Aktionen durchzuführen.

Wenn du das Konzept der Akkuzellen verwendest, müsstest du darüber nachdenken, wie viele Zellen es gibt. Vielleicht 64 Stück oder so, die du stehlen oder zerstören musst, um deinen Gegner zu besiegen.

Das meinte ich: Du hast einen unbeabsichtigten Motion Blur (der kein Post-Effekt ist).

Ein Motion Blur ist im Wesentlichen ein Bild (Frame) deines Objekts während seiner Bewegung. Dadurch entsteht diese unscharfe Nachzeichnung, die als Motion Blur bezeichnet wird.

Wenn du viele FPS hast oder haben möchtest, müssen die Frames möglichst scharf gezeichnet werden. Hier kommt das Anti-Aliasing ins Spiel. Es handelt sich um Kantenglättung, die sicherstellt, dass die Kanten der Objekte nicht pixelig aussehen, indem zusätzliche Pixel hinzugefügt werden.

Stell dir eine Treppe mit sehr hohen Stufen vor, auf der kein Mensch laufen kann (verpixelt). Das Anti-Aliasing fügt auf jeder Stufe eine zusätzliche Zwischenstufe hinzu, wodurch die Kante schärfer wird. Letztendlich ist es jedoch ein Fake.

Wenn du einen Post-Effekt wie Motion Blur in deiner Szene verwendest, muss weniger scharf gezeichnet werden, was weniger Leistung erfordert. Das Anti-Aliasing muss also weniger zusätzliche Berechnungen durchführen.

In deinem Fall entsteht der Motion Blur, weil du eine Bewegung hast und dein Rechner nicht genügend Frames schnell genug auf deinen Monitor zeichnen kann.

Im Fall von TSR werden bestimmte Berechnungen als Grundlage für mehrere Frames verwendet. Das macht TSR in der Renderberechnung schneller.

MSAA rendert jedes Pixel in jedem Frame.

Daher ist TSR schneller als MSAA.

Zusammengefasst:

1. Wenn du schnelle Kamerabewegungen hast, kannst du Motion Blur verwenden, um dein Bild unscharf zu machen. Dadurch muss das Anti-Aliasing weniger berechnen (gut für die Leistung).
2. In deinem Fall entsteht dieser Effekt aufgrund schneller Bewegungen. Wenn du von MSAA auf TSR umstellst, wird die Kantenberechnung schneller, jedoch auch ungenauer (was bei schnellen Bewegungen jedoch keine Rolle spielt).

Wenn du bei Google nach "Unreal fix motionblur" suchst, findest du Lösungen dazu. Wie gesagt: Interessiert aber nichts was mit Post Effects zutun hat.