Beiträge von LemmaVomWeissenPfad

Welche 5% denn?

Okay ich werde mich jetzt mal dransetzen und eure Vorschläge in die Tat umsetzen Danke an Sleepy und Harlyk

Ah super vielen Dank 123 Ich hab Blender's Spin verwendet und dachte das funktioniert so

Ich dachte an Bricks, weil es ne Kanalisation werden soll.

Ah okay, dankeschön. Ich hab nur leider keine Erfahrung und das war mein erstes Modell, das ich gemacht habe. Ich habe mich natürlich auch schon über Modulares Level Design informiert, bin aber noch nicht so dahintergestiegen, wie man jetzt z.B. so einen Art Gang (wie ich gepostet habe) aus modularen Einzelteilen bauen kann.
Vielen Dank aber für deine Mühen

Hey danke Sleepy, ich seh aber leider noch kein Bild?

Vielleicht solltest du dir überlegen, die Tools, die du in deiner Engine haben willst, einfach in UE4 zu implementieren?

Wie siehts aus Grombou? Schon angefangen?

Okay Moment. Soll ich die FBX Datei hochladen?

Also hier sind die Bilder als Mesh

Hallo,
Frage ist kurz: Wie unwrappe ich folgendes Modell, sodass ich eine Textur drüberlegen kann, ohne, dass irgendwas verzerrt ist.

Im folgenden Bild sieht man glaub ich ganz deutlich, dass das Material "gebogen" wird, wenn ich in UE4 irgendeins draufklatsche:

Wie kann ich es denn hinbekommen, dass dies nicht mehr passiert?

Ach du musst ja nicht studieren, um das zu verstehen. Les dir einfach die Artikel durch, die ich beigehängt habe.
Du musst dir als erstes die Frage stellen: Wie fange ich an? Also, wie fängst du an?

Fang mit nem leeren Projekt an. Dann versuchst du alles nach der Reihe aufzuziehen. Wenn man schon vorhandene Templates verwendet, finde ich es immer schwer alles nachzuvollziehen, wenn einem die API noch nicht geläufig ist. (Glücklicherweise ist sie schön durchdacht.) Um mit UE4 zu programmieren, muss man sich an gewisse OOP Themen gewöhnen, wie z.B. Vererbung, Polymorphie. Das gilt auch für BP.
Unity macht das ganz anders, die Engine hat ein durchdachtes Entity - Component Programmiermodell. Dies ist ein Pattern und ersetzt nicht das OOP, sondern "stopft" Lücken, sodass Vererbung nur in bestimmten Fällen nötig ist (z.B. um von MonoBehavior zu erben.) Eigentlich kann man sich das dort so vorstellen.

Du hast nur die Karosserie eines Autos. Du kannst es jetzt so ausrüsten wie du willst. Du programmierst ein Stück Räder (Diese Räder kannst du natürlich auch für andere Autos verwenden.), natürlilch auch einen Motor, ein Lenkrad, Sitze etc. All diese Dinge kannst du acuh in anderen Autos ( in Flugzeugen eben nicht) verwenden. Wenn du fertig bist, kannst du die Räder, das Lenkrad usw. einfach an das Auto "stecken" und wenn du alles richtig durchdacht hast, kann das Auto jetzt fahren und reagiert auf deine Lenkbewegung. Dabei ist es wichtig zu beachten, dass du dich immer nur auf ein Skript konzentrieren kannst. Du solltest Code, der sich auf das Lenkrad bezieht, auch nur im Lenkrad Skript halten. Wie interagierst du jetzt mit den Rädern? Da gibt es verschiedene Möglichkeiten:

1. Events. Wenn du dein Lenkrad nach links drehst, dann könnte die Routine so aussehen:
Wenn Drehung im letzten Frame:
Informiere alle Abonnenten darüber, dass das Lenkrad um x Grad gedreht wurde.

Was ist jetzt ein Abonnent? Das ist jemand (meistens ein anderes Skript), der sich bei deinem Skript angemeldet hat, um genau diese Information zu empfangen.
Das einzige, was du tun musst, ist es der Programmiersprache zu sagen, wann genau die Abonnenten informiert werden sollen. Du musst nicht mal wissen, wer sich angemeldet hat. Du sagst einfach. An alle Abonnenten, schicke diese Information ab. Wichtig ist dabei jedoch darauf zu achten, dass die Empfänger auch wissen, was sie mit der Information anfangen sollen. Sie müssen die Fähigkeit haben, auf dieses Event zu hören. Wenn diese Fähigkeit nicht vorhanden ist, dann gibt es in einigen Sprachen einen Compilerfehler in anderen wird dieser Abonnent einfach ignoiert.

z.B. könnten sich die Räder beim Lenkrad als Abonnent anmelden, sodass sie über etwaige Lenkbewegung erfahren.
Dies könnte so aussehen.

Klasse Rad mit der Fähigkeit auf Lenkbewegungen zu achten:
[...]
Wenn Lenkrad vorhanden ist, dann melde dich als ein Lenkbewegungsempfänger an (also jemand der weiß, wie man mit dieser Information umgeht), um auf Lenkbewegungen zu achten.
[...]
Methode Lenkbewegung_Empfangen(Grad x):
// Tue irgendwas

Jeder Empfänger muss eine Methode bereitstellen, die die Information "empfängt" (hier Lenkbewegung_Empfangen)
Natürlich unterstützt BP das auch: https://docs.unrealengine.com/…/Events/Custom/index.html

2. Referenzen.
Das Lenkrad weiß, dass es Räder gibt, merkt sich diese und kann sie über bestimmte Methoden, die dieses Rad bereitstellt, ansprechen.
Das könnte so aussehen:
Liste von Rädern X;
[...]
Befülle X mit Rädern, die wirklich existieren; (Nun ist X voll)

Methode Lenkbewegung(Grad g):
Für jedes Rad r in X:
r.bewegeRadUmGrad(g)

Dabei sprichst du das Rad nur über diese Methode an, sie ist also eine öffentliche Methode. Das Rad hat auch private Methoden, die intern verwendet werden, um diese Methode auszuführen. Diese privaten Methoden sind von außerhalb des Skripts nicht sichtbar und das ist auch gut so.
Man sieht hier gleich, dass auf alle Fälle ein Rad existieren muss, damit das Programm funktioniert. Lenkrad ist also abhängig von Rad, aber Rad ist nicht abhängig von Lenkrad. (Um dieses Problem zu lösen, musst du das sogenannte Dependency Inversion Principle anwenden etc.) Aber eigentlich ist das auch logisch. Ein Lenkrad ohne ein Rad erfüllt keinen Zweck, ein Rad ohne Lenkrad aber schon (z.B. könnte es ja ein Roboter sein, der selbst steuert.)

Ich habe vorhin gesagt, dass du an Objekt Orientiertem Design nicht vorbei kommst, wenn du mit der UE4 entwickelst. Schon wenn du ein neues BP erstellst, wirst du gefragt, von welcher Basisklasse du erben willst, dh. welche Fähigkeiten du erwerben willst. Du könntest dann weitergehen und eine große robuste Vererbungsstruktur aufbauen, sodass z.B. das Flugzeug-Auto von Auto erbt. (das Flugzeug-Auto kann alles was Auto kann plus fliegen.)
Aber das musst du nicht. Anders als in Unity kannst du es aber. Die UE4 bietet dir noch einen weiteren Weg, denselben Weg wie Unity. Das Entity-Component pattern ist hier auch zugänglich.
Dazu gehst du einfach, wenn du ein neues BP erstellst folgendermaßen vor: Wenn du das BP geöffnet hast, klickst du im Reiter "Components" auf "Add Component". Jetzt siehst du erstmal eine lange Liste von Komponenten, die dir die Engine schon zu Verfügung stellt (und die du auch benutzen solltest.). Ein Komponent ist z.B. das Rad skript, oder ganz praktisch ein Movement Skript, das es dir ermöglicht, dich zu bewegen. Wenn du aber ein eigenes Component schreiben willst, Klickst du gleich auf den ersten Eintrag in der Liste: "New Blueprint Script Component." Du wirst jetzt zu einem Tab weitergeleitet, der dich fragt von welcher Basisklasse du erben willst, welche Fähigkeiten du also mit deinem Komponent als Standard haben willst. ("Choose Parent Class") Nun wählst du das für dich passende aus.
Dann machst du einfach so weiter, wie ich es oben erklärt habe. Rote Nodes im BP Editor sind Events, die ich vorhin schon erklärt habe (z.B. EventBeginPlay) Diese befinden sich auch im passend genannten Event-Graph.
Hier sieht man, wie intuitiv es ist, mit Events zu programmieren. Wenn das Spiel startet, sendet das Spiel einfach an jeden seiner Abonnenten, dass das Spiel begonnen hat. Du musst dich nur darum kümmern, dieses Event auch zu empfangen. (Also wie oben erklärt, deinem Skript die Fähigkeit zu geben, diese Information zu empfangen. Du musst dich in BP nicht beim Event-Sender registrieren, das geschieht automatisch.) Dies geschieht, indem du rechtsklickst und dann in das Feld, das auftaucht: EventBeginPlay eintippst. Dann Enter, dann erscheint auch schon die Node. Diese wird dann aufgerufen, wenn das Spiel startet. Ganz einfach.

Wenn du diesen einfachen Strukturen folgst, dann klappt alles in egal welcher Programmiersprache.
Das, was ich versucht habe zu verdeutlichen nennt sich das "SOLID" Programmierprinzip gemischt mit dem Entity-Component Prinzip. (Beides Objekt Orientierte Prinzipien)
Um wirklich mit Programmieren anzufangen, musst du dich unbedingt zuerst mit Objektorientierter Programmierung befassen,
dann mit dem SOLID Prinzip (https://en.wikipedia.org/wiki/SOLID_(object-oriented_design) Nur die ersten drei; das sind die wichtigsten)
Danach mit dem sehr intuitiven Enity-Component Prinzip.
Dann startest du mit BP durch. Das gute an BP ist, dass du keine Syntax erlernen musst und dich nicht Speicherlecks usw. herumschlagen musst, die in C++ auftreten.
Ein kleines Programm sollte natürlich auch ohne diese Prinzipien gehn.

P.S. Das SOLID Prinzip ist ein sehr weit verbreitetes Prinzip und ich verwende es sehr gerne und oft. Es gibt noch viele andere und ich will keines besser oder schlechter reden.
Pattern sind im übrigen ungemein wichtig.

Hoffe ich konnte helfen.
Lemma

Ja genau ich mein ja was du sagtest ;D

Das würde mich wirklich freuen, wenn dazu ein anständiges Tutorial kommen würde Vielen Dank

Ah danke für den Einblick. Das mit dem Skalieren wusste ich nicht, vielen Dank. Wenn ich noch Fragen habe, kann ich mich dann nochmal melden?

P.S. Ich benütze Gimp, weil ich mir PS nicht leisten kann... Gibt es da auch so etwas wie Smart Object?

Okay danke. Ich hab schon was gutes erreicht mit, der Boden reflektiert jetzt dank Roughness mal stärker mal schwächer. Nur fehlt noch irgendetwas. Wie soll die Normalmap aussehen? Und wo finde ich 4k Texturen die kostenlos sind? Ich hab gesehen, dass Sleepy etwas gepostet hat, sind aber alles low res. Ich glaub ich muss selber welche machen oder?

Hallo,
ich muss leider sagen, dass ich mich mit sowas überhaupt nicht auskenne.
Angenommen ich möchte, dass mein Boden in etwa so aussieht, wie hier auf dem Bild: https://www.flyaway-service.de…s/2015/11/P2_3449_bea.jpg

Dabei soll der Boden dieselbe Grundfarbe haben, wie dort zu sehen ist (also cementartig, wie man ihn eben aus der Tiefgarage kennt), auch mit Schmutz etc.
Wenn ich mir nen Textur aus dem Internet raussuche und sie auf mein Model ziehe (nur die Textur), dann sieht das ganze wie ein riesiger Pixelbrei aus.

Was muss ich denn tun, damit das einigermaßen nach Cement/Tiefgaragen Boden mit Schmutz aussieht.
Außerdem wiederholt sich immer dasselbe Muster nach einer Weile, wenn ich meine Bodenstücke aneinandersnappe. (Was klar ist. Wie löse ich das am besten?)
Mit PBR bin ich bestens vertraut, jedenfalls mit der Theorie und der Mathematik. (Auch kann ich den Schmutz dann mit Vertex Painting draufmalen). Also mir gehts nur um die Albedo Textur.

Ich hoffe jemand von den Künstlern kann mir da helfen

Ich finde Sleepy hat nur zum Teil Recht.

Die Engine macht viel aus, wenns ums visuelle geht. Unity hatte z.b. bis vor kurzem kein SSRR implementiert, was ein großer Nachteil ist. Unity hat standardmäßig Blinn-Phong anstatt GGX implementiert. Übertriebenes Kantenflimmern kann ausgemacht werden. (Siehe z.B. Demovideo Blacksmith)
Weiterhin: Unity hat weniger qualitativ hochwertige Post Process features implementiert. Mir fehlt z.B. ein guter Bloom Effekt. Der jetzige ist schlecht, man findet auf dem Marketplace viel bessere.
Baking dauert gefühlte Ewigkeiten.
Partikelsysteme haben kein Lighting Modul.
Überdies stört mich auch der fehlende Material Editor, aber das ist eigentlich nicht so wichtig.
Unterm Strich gibt es viele qualitative Unterschiede zwischen den Engines. Unity kann natürlich genau dieseleben Dinge wie UE4, man muss sich halt alles auf dem Assetstore zusammenkaufen, was nervig ist.
Das einzige, was Unity besser macht als UE4 ist (precomputed) Dynamic GI. Die Entwickler von P.A.M.E.L.A haben genau deshalb Unity gewählt. (so erinnere ich mich jedenfalls)
Nicht dass Unity eine schlechte Engine ist, sie hat einfach nicht so viele standardmäßige Features wie UE4.

Noch was, welche Lightmapping Fehler meinst du denn @Sleepy

P.S. Ich war schon mal irgendwann registriert, kann mich jedoch nicht mehr erinnern, wie ich hieß, oder welche E-Mail ich verwendet habe.