Beiträge von Annubis

    Das geht nicht.

    Im Array werden keine Daten gespeichert.

    Also @Runtime werden definitiv Daten im Array gespeichert und sind auch änderbar. Wenn du mit abspeichern ein Savegame meinst, dann werden die im BP auch ins Array gelegt und dann auf die Festplatte in einen vorgegebenen Ordner gelegt. Dazu gibt es eine Unmenge an mehr oder weniger langen Tutorials.


    Solange also dein Array im Charakter oder im Persistant Level liegt, haste die Daten (nicht nur Arrays) jederzeit zur verfügung, Natürlich musst du beim Nutzen von Streaming oder laden/speichern von einzelnen Level/Maps darauf achten, dass die Daten übergeben oder sonst (savegame) abgespeichert werden.

    Ich sehe das so das wenn z.B. 1000 Spieler zur gleichen Zeit zugriff auf die Datenbank (umgangssprachlich) haben und alle Gegenstände in dieser einen Ansammlung sind würde der Server zu sehr belastet werden. Dies ist jedoch nur eine Vermutung von mir, ob das keine Auswirkung hat weiss ich nicht.

    Wie gesagt, sehe ich kein Anwendungsfall dafür. Ich kenn jetzt dein Konzept nicht. Aber mal folgendes:


    DataTable: Du kannst hier nur vorgegebene Daten auslesen. Willst du Daten ändern, erhält dein Spiel ein Update. Was mich zu der Frage bringt, warum Spieler den DataTable vom Server auslesen? DataTable bekommt der Spieler auf seinen Rechner.


    Wenn du in einem DataTable suchen lässt, wobei hier auch erst wieder der Anwendungsfall betrachtet werden muss, dann kannst du das auf dem Server machen, der Nutzen wird allerdings nicht vorhanden sein.


    Array: (Datenbank) In einem Array kannst du alles ändern was du willst. Das wohl typischste Array, was wir kennen, dürfte das Inventar sein. Natürlich kannst du in der Programmierung für alles mögliche ein Array anlegen. Dass du ein Array im Sinne einer echten Datenbank hast, wo alle Gegenstände bzw. Objekte deines Spiels drinn sind, halte ich mal für ausgeschlossen, da ein Anwendungsfall dafür nicht existieren dürfte.


    Abhängig von deinem Konzept, brauchst du also nur wenige Arrays (vorgegebene Objekte) oder mehr Arrays (individualisierbare Objekte).


    Soll der Spieler Eigenschaften bspw. durch Crafting eines Gegenständs ändern könne, dann brauchst nen Array. Erhält der Spieler von dir vorgegebene Gegenstände, dann brauchst nur nen DataTable.


    Beispiel DataTable: Apfel <- hat nur vorgegebene Attribute (Haltbarkeine, Gesundheitsregeneration beim Essen) den Apfel kann dein Spieler nicht "pimpen"


    Array: Schwert/Schild <- aus einem DataTable lootet dein Spieler ein Schwert, was vorgegebene Werte hat (Schaden, Haltbarkeit) jetzt willst du, dass der Spieler des Teil verbessern kann. Hierbei spielen verwendete Materialien und sein Skill etwas zu Verbessern eine Rolle. Es sollen zufällige Werte am Ende rauskommen. Das neu entstehende Item steht in keinem DataTable und muss in einem einem Array mit einer individuellen ID abgespeichert werden.


    Es muss letztlich ein Anwendungsfall diskutiert werden. Denn anlegen eines Array aus einer Datenbank ist programmierbar und muss nur eindeutig sein. Dein Inventar hat immer eine ID für den Inventarplatz und ein Spalte als Referrenz für den Datatable oder eben einen leeren Platz für ein Individuelles Item.

    Das Problem was ihr hier diskutiert, ist schon spannend. Es fällt mir jedoch schwer einen Anwendungsfall abzuleiten. Der Nutzer kommt doch in keinem Spiel (zumindest die ich kenne) dazu die gesamte Datenbank eines Spiels zu durchsuchen.


    Auf wieviele DataTable man etwas aufteilt, spielt keine Rolle, weil die DataTable referenzierbar sind. Das Inventar hat also bei Items aus mehreren DataTable immer eine Spalte in der die Referenz vermerkt ist. Ein Inventar damit zu durchsuchen, ist der Performance egal.


    Wenn man somit DataTable für verschiedene Kategorien von Daten anlegt, stellt sich kein Problem. Außerdem kann man ein Array anlegen, wenn man es denn unbedingt darauf anlegt, dass alle Daten aus allen DataTable in einem Array liegen, vomit man letztlich auch alle Items durchsuchen kann.


    Im Übrigen sucht der Nutzer nach Namen und nicht nach IDs. Also gibt der Entwickler/Ersteller dem Nutzer vor, in was für einer Datenbank er was genau suchen kann. Alle Items eines Spiels zu durchsuchen, sollte also von vornherein unmöglich sein.


    Typischerweise lässt man den Nutzer das Inventar durchsuchen oder beispielsweise spezielle Gegenstände. Wenn er bei nem Händler steht, dann kann er dessen Inventar durchsuchen oder wenn er in einem Baumenü ist, dann kann er alles durchsuchen, was für ihn als Bauteil zur Verfügung steht.


    Letztlich sollte man das Problem also selbst klein halten.

    Da ich aktuell 5 Structs (Gegenstandsarten) habe, habe ich auch 5 Inventar-Arrays.

    Da ist doch schon der Fehler. Gegenstände müssen immer eindeutig identifizierbar sein. 5 Structs für Gegenstandsarten mögen noch okay sein, aber dein Inventar besteht nur aus einem einzigen Array.


    Wenn ich mich recht entsinne, hat das schonmal jemand gefragt und das selbe oder ein ähnliches Problem aufgezeigt.


    Letztlich schnappst du die Excel oder etwas vergleichbares und erst wenn alle Gegenstände in einer einzigen Tabelle stehen, dann klappt das auch.


    Fehlern kommt es immer, wenn etwas nicht eindeutig identifiziert werden kann, wie du das anstellst, ist dir überlassen, dass muss nicht über die Indexzahl erfolgen oder kann auch eine gemischte Identifizierung sein, nur muss sie eben eindeutig ablaufen.


    Hast du schonmal versucht mit Tag zu arbeiten? viele kommen damit besser zurecht als mit Indexzahlen.


    Deine Gegenstände haben Eigenschaften, die meisten erstellen mehrere Listen, weil sie meinen, dass das übersichtlicher ist. Bspw Waffen, Nahrung, Rüstung, Baumaterial, Rohstoffe.


    Dieses System halte ich persönlich für möglich aber eben auch extrem anfällig. Besser ist es, wenn alle Items in einer Liste stehen und neben der Indexzahl einen Tag erhalten. bspw Nahrung.


    Eigenschaften einer Sache müssen nicht ausgefüllt werden und erhalten dann auch keinen Wert. Viele Werte sind also für verschiedene Items überhaupt nicht auszufüllen, aber über Tag kannst du schnell und einfach filtern.


    Größtes Problem für mich war es damals, wenn du später Gegenstände individualisierst.

    Wie du eine Animation erstellst, ist grundsätzlich egal. Wie schon gesagt ist es eine Frage der Wahrnehmung und der Interpolation.


    Die Geschwindigkeiten zweck maximaler FPS ist nur interessant, wenn es um Reaktionsspiele geht, weshalb meist Shooter davon betroffen sind. Das Problem liegt dann aber eher in der Darstellung des Bildes bzw. jedes einzelnen Bildes und der Geschwindigkeit mit der berechnet und dargestellt wird. weshalb es auch nix bringt bei einem 60Hz Monitor 200FPS zu haben.


    Für deine eigene Wahrnehmung ist alles über konstanten 30FPS egal, lass dir da nix einreden. Monitore mit einer höhren Herzzahl sind allerdings dennoch besser für die Augen, da sie schonender sind, das nimmst du so bewusst nicht wahr, aber Bildverzerrungen "verbessert" dein Hirn dennoch automatisch ohne dass du dich darauf konzentrieren musst.

    mach dir keine Gedanken zur Software. Du fotografierst dein Objekt typischerweise im "Kreis" also fängst an einer seite an und läufst dann mit oder gegen den Uhrzeigersinn um das Objekt und machst Fotos. Dann kannst du das wiederholen aus einem anderen Winkel (oben/unten).


    Die Software weiß das, weil sie die Änderungen in den einzelnen Fotos auswert und meist zeigt dir die Software sogar an, wo selches Bild hingehört. Ich denke, das jede Software das mittlerweile hinbekommt.


    Du wirst sicher nicht wie ein Irrer um das Objekt hüpfen und völlig willkürlich Fotos machen, wobei selbst das kein Problem sein sollte, ein Stativ kannst verwenden, bringt aber nix. Setz die Verschlusszeit runter und die ISO hoch und gut ist. Für die Software reicht das, probiers mit dem halbswegs modernen Handy mal aus. 12MP reichen dafür locker aus, musste nicht gleich ne Spiegelreflex auspacken.

    Sleepy Sonne/Schatten sind halt generell Kacke. Entweder die brennen helle Stellen aus oder liegen zu dunkel im Schatten. Du brauchst grad wenn du draußen ein Objekt fotografierst eine gewisse Zeit und in der wandert die Sonne und damit der Schatten, was logischwerweise zu Problemen führt. Die Programme arbeiten ja mit einer gewissen Logik in ihren Berechnungen und wenn sich die Szene ändert dann kommt die Logik auch nicht klar.


    Wenn die Programme heut Retopo und Fehlerkorrektur beherrschen, sodass du händisch wenig machen musst, dann wird die Photogrammetrie immer interessanter, weil dich am Ende des Tages vermutlich am meisten interessiert, wieviel Zeit du da rein versenkst.


    Was Texturen angeht, kann ich nix sagen, weil ich immer nur das Mesh (grau) rausgezogen habe, aber ich gehe davon aus, das du wirklich extrem gute Texturen direkt aus der Berechnung kaum bekommen wirst. Warum? Die Programme stückeln letztlich alles zusammen, was niemals (heute) zu einer wirklich brauchbaren Textur führt. Sieht man auch in zahlreichen Tutorialvideos.


    Aber wenn das Mesh halt relativ gut als Ergebnis am Ende aus dem Programm kommt, dann ist der Aufwand für eine Textur natürlich insgesamt erträglich, zumal du mit den zahlreichen Fotos ja im Prinzip auch schon alles hast. Und da gilt dann auch wie du sagst, je besser das Equip, je besser die Textur.


    Die größe des Objektes ist erstmal weniger relevant mit Blick auf die Anzahl der Bilder. Am Anfang bin ich auch davon ausgegangen. Die Anzahl der Bilder verringert die Fehlerquote bei der Berechnung. Bei größeren Objekten verbessert sie den Detailgrad. Beispiel: Wenn du Holzbalken nimmst, brauchst vielleicht 20 Fotos und bekommst ein recht gutes Ergebnis. Wenn du allerdings einen Himbeerstrauch mit 20 Fotos nimmst, dann wirst wohl eher garkein Ergebnis erhalten. Die Anzahl der Fotos hängt wesentlich von der Komplexität des Objekts ab, weniger von der Größe. Umso mehr Ecken und Kanten oder sich gegenseitig verdeckende Details, umso mehr Fotos musst du machen.

    Ist bei mir auch schon ne Weile her. Software gibt es einiges, wobei ich garnicht mehr so recht weiß, wie die hieß. Die Technik ist schon schick, hat aber aus meiner Sicht so viele Nachteile, dass sich das nicht lohnt.


    Zunächst ist es so, dass einfache Objekte (Felsen, Steine, etc), welche im Grunde auch recht einfach zu modellieren sind, keinen Sinn ergeben, denn faktisch ist der Aufwand bei solchen Objekten größer als wenn du sie händisch erstellt.


    Bei komplexeren Objekten ist das Problem letztlich auch nicht anderes, allerdings ist dort das Problem, dass du mehr fehler in der Erstellung hast, da du oft mit der Kamera nicht alles erfasst und dann jede Menge händisch nachbearbeiten musst. Im Anschluss kannst grad in der Natur vorkommende Objekte nur sehr spezifisch verwenden, des sieht man ja auch gut an den Beispielen auf Quixel.


    Praktisch hast du noch ein weiteres Problem, wenn dein Objekt draußen steht. Du musst für den Idealfall auf einen durchgängig bewölkten Himmel warten. Sonne ist für die Technik halt kacke, denn dann musst du so schnell Fotos machen, dass sich Schatten auf dem Objekt möglichst nicht ändern, was bei mehr als 50 Bildern nahezu unmöglich ist.


    Was mich auch noch gestört hat, waren die Texturen, die konnt ich zumindest bei der von mir verwendeten Software vergessen, von knackig scharf war das weit weg, also musste ich da auch noch nachhelfen.


    Für mich persönlich ist der Aufwand zu groß, obwohl die Technik schon genial ist. Wenn die UE5 kommt, werd ich mir das nochmal ansehen, da die Engine mehr Polygone verkraftet, sodass der Kosten-Nutzen-Aufwand vielleicht wieder gegeben ist und die Software wird auch immmer besser.


    Was im Übrigen auch noch relativ interessant ist, dass man kleinere Objekte auf eine Drehscheibe stellt und dann mit Hilfe einer Kamera oder einer sehr guten Webcam aufnimmt, dafür gibts mitlerweile auch gute Software und gut YT-Tutorials, aber auch hier gilt, dass man am Ergebnis nochmal einiges selbst nacharbeiten muss.

    Bin mir sicher, dass die Performance darunter leidet lauter Blueprints anstelle von Static Meshes in dem Level zu benutzen. Aber es wird nur ein Blueprint für viele verschiedene Bäume genutzt. Wie sollte es sonst möglich sein, z.Bsp.: die Äste von Bäumen zu bewegen, oder einen realistischen abwechslungsreichen Wald zu gestalten, wenn ich dutzende verschiedene Static Meshes nutze und dass nur für einen Abschnitt eines Waldes, ich aber bei großen Maps nun einmal viele verschiedene Laub und Nadelbäume habe, ist das für die Performance sicher auch nicht gut. Mit dem Asset habe ich vielleicht ein zwei dutzend verschiedene Blueprints für die verschiedenen Arten von Bäumen, die sich dank der Nodes in immer anderen Positionen aufstellen lassen. So sieht ein Wald schon etwas besser aus, gerade Große, da jeder Baum einzigartig ist.

    Ungeachtet, dass ichdir alle seine Videos ans Herz lege, so solltest du dir die Videoreihe zu den Foliageshadern von Ben Cloward anschauen. Einige Angaben in deinem Text erübrigen sich vielleicht dazu und gut ist die Videoreihe allemal. Die Wassershadervideos lege ich besonders ans Herz, weil sie einfach sehr gut erklärt sind und einfach nachzubauen sind.

    Wenn ich die Screenshots richtig sehe, dann hängst du an einer realen/physikalischen Umsetzung. Die Berechnung des Schadens läuft auf dem Server, soweit ich das erkennen kann.


    Irgendjemand schrieb es schon mal, da könnte der Server irgendwann in die Knie gehen. Natürlich wird das cheaten etwas verringert.


    Von der Performance halt ich die Rangehensweise allerdings für fragwürdig. Wenn die Pings nicht mehr stimmen, wird das schnell undurchsichtig. Hast du Lags auf Client und Serverseite, warum auch immer, dann werden Treffer zum Glücksfall und eventuell auch zum cheaten.


    Die Trefferabfrage benönigte eine sehr hohe Priorität und möglichst wenig Traffic. Abstrahiere dein Problem. In einer Client/Server Beziehung spielt erstmal nur eine Rolle, ob du getroffen hast, die Schadensberechnung kannst ja auch im Anschluss durchführen. Ein LineTrace dürfte am schnellsten sein.


    In den Screenshots seh ich noch, das du Actor zersörst. Generell würde ich Geschosse mit Niagara machen, allein wegen der Performance und hier keine Meshes zum Einsatz bringen. Das was du optisch als Spieler wahrnimmst, solltest als Entwickler eher faken und nicht real abbilden.


    Wenn man wirklich Kugeln und andere Geschosse als Mesh mit einer Physik darstellt und daran eine Treffer und Schadensberechnungs machst, wird dir das nur bedingt gelingen, weil es kein Singleplayer ist. Nicht jeder hat die selben Frames und willst du die Flugbahn tatsächlich zwischen Server und Client abgleichen. Ich denke, das zwingt den Server in die Knie und dein Netzwerk auch.

    Displacement = Verschiebung. Tesselation = Polygonzerlegung (Kachelung).


    Die beiden Begriffe haben nichts gemeinsam. Displacement gehört zu den Texturen und Tesselation gehört zu den Polygonen (Meshes (2D/3D)).


    Displacement bestimmt die Verschiebung eines Punktes relativ zu einem einheitlichen Ausgangspunkt. Typischerweise erziehlt man damit den Eindruck von Tiefe (3D-Effekt).


    Tesselation ist eine rechenbasierte Methode (meist nahen) Objekten mehr Polygone und damit mehr Struktur zu geben. Die Unterteilung eines Meshes wird dadurch erhöht weshalb sich feinere Details (insbesondere Rundungen) darstellen lassen.


    Bei einem LandscapeMaterial hilft dir Displacement gerade kleinere Steine, Sand, Blätter und Äste auf dem Untergrund darzustellen, ohne das ein eigenes Objekt dafür verwendet wird. Die meisten Anfängerbeispiele zeigen es anhand von Steinen oder Straßen, aber eben auch Sand oder Kies. Anstatt Millionen von Steinen zu modelieren und auf der Karte zu verteilen damit ein 3D Effekt entsteht erreicht man das selbe Ergebnis übers Displacment.


    Tesselation verwendet man auf dem Gitternetz der Landscape selbst damit Hügel oder auch Uferstreifen detaillierte Dargestellt werden können. Gerade wenn es um Rundungen im LandscapeGitter geht, hilft dir Tesselation ungemein damit keine eckigen Kanten entstehen.