KI

Okay, ich bin da schon wieder raus. Pointlight ist Pointligt in der Unreal Engine. Was soll das für ein Preset sein? Und dann noch in Klammern dahinter schreiben, dass du das gerade erlogen hast. Wie soll man da bitte versuchen das nachzuverfolgen und Vorschläge zu machen? Wahrscheinlich hast du wieder irgendwelche Tutorials geschaut, nicht verstanden, aber sahen toll aus. Aber dann musst du den Ersteller von dem Tutorial fragen, weil sonst reden wir hier ständig von unterschiedlichen Dingen.

Zitat von Tomarr

Okay, ich bin da schon wieder raus. Pointlight ist Pointligt in der Unreal Engine. Was soll das für ein Preset sein? Und dann noch in Klammern dahinter schreiben, dass du das gerade erlogen hast. Wie soll man da bitte versuchen das nachzuverfolgen und Vorschläge zu machen? Wahrscheinlich hast du wieder irgendwelche Tutorials geschaut, nicht verstanden, aber sahen toll aus. Aber dann musst du den Ersteller von dem Tutorial fragen, weil sonst reden wir hier ständig von unterschiedlichen Dingen.

Ich denke auch nicht das das wirklich Sinn ergibt, wenn man keinen Ratschlag annehmen kann. Es ist halt nervenaufreibend wenn man sich die Zeit nimmt und jemanden versucht zu helfen und dann läuft es nur ins Leere. Spar dir deine Energie. Und Cleantron kann sich ja mal überlegen ob er wirklich Rat möchte welchen er Umsetzen möchte, ansonsten gibt es ja genug Bereiche hier wo man einfach zeigen kann was man gemacht hat. Ich denke das wäre sinnvoller.

Zitat von Sleepy

Pointlights sollte man meiner Meinung nach niemals als Hauptlichtquelle einsetzen. Es ist zwar erstmal naheliegend, ein Pointlight als Sonne oder Glühbirne zu verwenden, aber sie haben einen entscheidenden Nachteil gegenüber Spotlights: Ihre Lichtquelle ist theoretisch unendlich klein.

Kommt halt drauf an, wofür man das Light einsetzt. Lustigerweise ist ausgerechnet dein Beispiel mit der Sonne kein Pointlight, sondern ein directional Light (der Winkel bestimmt dann auch ob Tag oder Nacht ist). Für die Munition hätte es schon einen Sinn ergeben, weil wenn da ein Laserpunkt gefeuert wird, dann leuchtet er halt in alle Richtungen. Nicht z hell, soll ja nicht blenden, nur ein paar Licht- und Schattenreflexionen.

Zitat von Sleepy

Bei der Sonne oder einer Glühbirne werden die Strahlen jedoch nicht aus einem unendlich kleinen Punkt ausgesendet, sondern von einer Fläche.

Nich ganz. Ein Lichtstrahl ist ein Photon. Man sieht es nur, wenn es reflektiert wird. Was du in einer Glühbirne siehst, oder als Sonne, ist halt nur die Oberfläche die diese Photonen emittiert. Ganz so funktioniert es in einer Simulation aber nicht. Du hast zwar einmal die Möglichkeit emissive Materialien zu erstellen, aber das ist sehr rechenintensiv und funktioniert mit RTX usw. eher nicht ganz so gut, gerade wenn es um Reflexionen in der Umgebung geht. Deswegen eine Mischung aus beidem, einmal die Lichtquelle, Pointlight, um ein sehr gutes Ergebnis beim Raytracing zu bekommen und gute Schatten und Reflexionen und nur ein wenig emissives Material, um den Schuss sichtbar zu machen, sodass er auch leuchtend aussieht. So eine feste rote Kugel würde halt auch nicht passen.

Aber wozu mehrere Spotlights, das verstehe ich jetzt nicht so ganz. Denn die Munition würde ja rundherum leuchten.

Wenn ich jetzt zum Beispiel eine Deckenlampe darstelle, die nach unten strahlt, dann ja, Directional Ligt. Aber bei einer Kuggel oder einem Strahl, der sich frei im Raum bewegt, wozu da mehrere Directional Lights? Weil jede Quelle verlangt auch wieder Berechnungen und entsprechende GPU/CPU-Leistung, plus das Risiko, dass die Lichtquellen sich überschneiden ab einer gewissen Entfernung, oder eben halt auch Lücken bilden.

Kommt mir persönlich jetzt schwieriger vor, als ein einziges Point Light da mit dem Strahl mitzuschicken.

Aber Directional Lights haben in der Software auch keine Fläche, es strahlt halt nur in eine Richtung. Und, wenn du dann 4 Directional Lights nimmst, statt einem Pointlight, ich weiß nicht so recht, ob es da nicht von der Performance her besser ist nur ein Licht zu verwenden. Ich weiß halt nicht, wie die Engine das im Hintergrund abarbeitet, wenn mehrere Lichtquellen vorhanden sind, denn mit dem Sourcecode, da hatte ich nun wirklich noch keine Lust mir den anzusehen. Er benutzt ja Raytracing, da baked man Lichter eigentlich nicht, denn es ist ja Echtzeitberechnung.

Das ist ja das, was ich meine. In der Software hat kein Licht eine Fläche, sie alle gehen von einem Punkt aus. Flächen haben eigentlich nur Modelle, die mit einem Emissiv-Material verbunden werden.

Nicht ganz. Directional Ligt geht quasi von einem unendlich weit entfernten Punkt aus. Deswegen kannst du es für den Laser auch nicht benutzen, denn nur die Richtung ist entscheidend und leuchtet die ganze Szene komplett gleich aus, also mit Schattenwurf natürlich. Deswegen auch für die Umgebungsbeleuchtung für Tag/Nacht. Die Position von Directional Lights ist absolut unwichtig, es wird immer die gesamte Szene ausgeleuchtet, auch, wenn du sie in ein Objekt einbaust.

Dann gibt es ja noch das Spotlight, ich glaube, das meinte ich ursprünglich, dies strahlt aber nur Kegelförmig in eine Richtung, hat also wieder einen Ursprungspunkt, keine Fläche.

Naja, und ich bleibe halt dabei, ein einziges Pointlight beste Wahl, denn diese Quelle hat bereits, ohne Vervielfältigung/Mehrfachnutzung, alle Aspekte, die nötig sind und ist billiger als 4 oder mehr Spotlights, oder was auch immer. Kurze Reichweite, ohne Schattenwurf, perfekt und schnell zu berechnen.

Zitat von cleanTron

Es ärgert mich so sehr das ihr Recht hattet. Ich mein Unrecht hatte ich ja nicht, Recht aber auch nicht.

Für mich gibt es aber eigentlich kein klares „richtig“ oder „falsch“. Jeder bringt seine eigene Sichtweise und Erfahrung mit, und daraus entsteht das, was sich für einen selbst stimmig anfühlt.

Gerade deshalb ist so ein Forum wertvoll. Auch jemand mit viel Erfahrung kann an einen Punkt kommen, an dem er nicht weiterkommt – und genau da setzt der Austausch an. Es geht nicht darum, wer recht hat, sondern darum, voneinander zu lernen.

Ich selbst probiere Dinge oft erstmal alleine aus, bevor ich mir Tutorials anschaue. Aber wenn ich merke, dass ich feststecke, frage ich gezielt Menschen, die diesen Weg schon gegangen sind. Und genau das ist für mich der große Vorteil hier: Man kann auf Erfahrung zugreifen, die man selbst noch nicht hat.

Am Ende ist es ein Kreislauf. Die, die dir heute helfen, standen früher an einem ähnlichen Punkt. Und irgendwann bist du selbst derjenige, der anderen weiterhilft – was du ja auch schon gemacht hast.

Vielleicht hilft es, das Ganze mehr als offenen Austausch zu sehen und weniger als richtig oder falsch. Dann fühlt sich Weiterentwicklung auch nicht wie ein Kampf an, sondern eher wie ein natürlicher Prozess.

Zitat von VerLesSail

Für mich gibt es aber eigentlich kein klares „richtig“ oder „falsch“.

Na die Diskussion geht ja nicht um richtig oder falsch. Gerade beim Programmieren gibt es sehr viele Wege etwas umzusetzen. Die Frage ist immer nur, wie sehr versucht man etwas zu optimieren. Gibt es Schleifen, die vielleicht sinnlos durchlaufen werden, gibt es eine Möglichkeit einen Effekt zu erzeugen, der vielleicht weniger Rechenpower benötigt, oder auch besser aussieht, oder auch leichter zu handhaben ist, oder läuft eine Abfrage vielleicht ins Leere, obwohl es so aussieht, als wenn es funktioniert.

Was ich schade finde, ist, heutige Rechner sind so schnell und haben so viel Speicher, dass der Code meistens nicht noch einmal überprüft wird. Selbst große Firmen, die AAA-Titel rausbringen lassen lieber alten Schrottcode in ihren Spielen, weil es einfach nur funktioniert, weil die FPS stimmen ja aufgrund der Rechenpower trotzdem, alles gut. Vielleicht ist das bei einzelnen Projekten auch okay, wenn man es erstmal zum Laufen bringt. Das Problem dabei sit nur, man gewöhnt sich so schnell daran, es irgendwann immer wieder nicht zu optimieren, dass irgendwann auch der Erkenntnisgewinn durch Verbesserung wegfällt.

Zitat von cleanTron

Die Schleifen sind wohl die größte Gefahr. Das Manches immer und immer wieder berechnet wird obwohl es gar keine Relevanz mehr hat. Ein Schuss und das Geschoss fliegt so lange im Speicher rum, jeden Tick wird die Kollisionsabfrage durchlaufen. Das muss man natürlich begrenzen, bei meinem 2D Spiel ist das leicht, 2 Sekunden Lebensdauer dann automatisch löschen. Bei 3D Shootern ist das theoretisch komplexer, wobei es da sicher ähnlich gemacht wird. So richtig weiss ich auch nicht wie man der UE sagt das sie den Speicher auch wieder frei machen soll. Manchmal lad ich nen Level bei dem ich Performance Probleme hab und wenn ich danach nen Level lade der eigentlich fluffig läuft hab ich da doch die selben Performance Probleme. Das ist schon eigenartig. Die Schleifen aus dem anderen Level laufen da wohl im Hintergrund weiter weil es keinen auto stop/ clear gibt.

Ich hab übrigens noch die selben Probleme mit 2 Level, der eine Level ist gedreht zum Spielmodus und lässt sich nicht anpassen und beim anderen wird der Player Start vollkommen ignoriert.

Gerade, wenn du immer wieder etwas änderst passiert das absolut schnell mal. Bestes Beispiel ist mein Lieblingsbeispiel in deinem BP, wo ein Branch einfach nur auf True gestellt war, keine Variable als Input, somit auch immer nur der Zweig True ausgeführt wurde. Logisch, das wird deine FPS jetzt nicht ins bodenlose ziehen, das sind winzige Bruchteile einer Sekunde, die diese Abfrage ins Leere läuft. Aber, stell dir Mal vor, das wird jetzt 1000 Mal pro Minute aufgerufen. Du spielst das Spiel jetzt 30 Minuten, das sind 30.000 sinnlose Abfragen. Mag vielleicht ein wenig autistisch von mir klingen, aber der Gedanke alleine, ist nicht schön.

Deswegen, unbedingt immer möglichst sämtliche Möglichkeiten der objektorientierten Möglichkeiten der Unreal Engine nutzen: Man muss sich eigentlich schon echt Mühe geben nicht objektorientiert in den Unreal Blueprints unterwegs zu sein. Aber auch ich schaffe das immer wieder, gerade, wenn ich etwas ausprobiere. Und, das bringt einen sehr schnell in Schwierigkeiten, wenn du dann nach einer Woche mal wieder in den Code schaust, selbst, wenn du ihn kommentierst, du wirst nicht mehr genau wissen, was du da gemacht hast.

Also, Grundregel, immer schön objektorientiert bleiben. Weil dann kannst du auch kleine Codeteile ändern. Dir reicht dann halt, was benötigt die Funktion als Input, was liefert sie als Output. Der neue Code muss halt dasselbe liefern und gut ist.

Und das ist halt, um mal beim Eingangsthema zu bleiben, das Problem mit KIs. Wie du ja mitbekommen hast, derzeit experimentiere ich sehr mit lokalen KIs und LLMs. Eine KI kann dier vielleicht eine Lösung anbieten, was du machen kannst. Aber sogar das derzeit beste KI-Modell für Coding und Bugfinding, Opus 4.6, liefert dir absolut keinen sauberen Code. Es funktioniert, ja, aber lesbar, sauber, in gekapselten Funktionen und Bereichen, nein, das kriegen die einfach noch immer nicht hin.

Zitat von Sleepy

Das ist auch so eine Sache. Ein Tick ist eine Berechnung die Innerhalb eines Frames statt finden. Bestimmte Abfragen müssen in jedem Frame passieren aber auch manche Abfragen kann man auch verzichten.

Generell sollte man auf Ticks grundsätzlich verzichten. Zumindest in den Actoren. Kollisionen sind Events. Spart auch wieder zig Zyklen pro Sekunde.