Jump to content
Unity Insider Forum

Leaderboard

Popular Content

Showing content with the highest reputation since 12/30/2022 in Posts

  1. Ich wollte nur noch mitteilen, dass es so geklappt hat! Die Startkoordinaten und die jeweiligen Bilddimensionen werden bei unterschiedlichen Monitorauflösungen neu berechnet! // Screensize der orthogonalen Kamera ist 6 // Kamera Units vertikal: Camerasize (6) * 2 = 12 Units werden von der Kamera vertikal erfasst // Kamera Units horizontal: 12 Units / 9 * 16 = 21.3333 Units werden von der Kamera horizontal erfasst float propX = 12f / 9 * 16 / sprite.GetComponent<SpriteRenderer> ().bounds.size.x; // Verhältnis von Screenbreite und Bildbreite float propY = 12f / sprite.GetComponent<SpriteRenderer> ().bounds.size.y; // Verhältnis von Screenhöhe und Bildhöhe int width = (int)(Screen.width / propX); int height = (int)(Screen.height / propY); int startX = (int)(Screen.width / 2 - width / 2); int startY = (int)(Screen.height / 2 - height / 2);
    2 points
  2. Ohh...ich hoffe das funktioniert mal bei mir, wenn ich für unterschiedliche Zielgeräte erstellen will Hast du das mal dazu gelesen -> https://forum.unity.com/threads/unityframework-bitcode-error-with-google-mobile-ads.1371879/ Nur ein Vorschlag...vielleicht bringt es dir was?
    1 point
  3. Layer scheinen mir schon sinnvoll dafür, damit du die Animationen kombinieren kannst. Man könnte jetzt natürlich überlegen, für jeden der Raketenwerfer ein eigenes Objekt mit eigenem Animator zu machen, aber Layer sollten auch gehen. Davon unabhängig ist Macanim aber schon dafür gedacht, dass du Parameter benutzt statt Play(). Dann kannst du auch vernünftig Transitionen zur Laufzeit debuggen.
    1 point
  4. Hallo, hier ein Zeitraffervideo vom Bau der Burg des Barons. Das Modell ist noch nicht fertig. Im Augenblick werden Erdlöcher ausgehoben, Marmor zum Bauort getragen und dann von den entsprechenden Arbeitern die Teile der Burg errichtet.
    1 point
  5. Also erst mal die Grundlagen lernen und dann Projekte angehen und "VERSAGEN". Will ehrlich sein. Dafür reichen bereits die Youtubevideos heutzutage. Bücher sind eher fürs Nachschlagen gut. Durch Versagen habe ich mehr gelernt und bin da wo ich heute bin. Beispiel, hätte ich kaum Performanceprobleme, hätte ich nie erfahren, was Performanceprobleme verursacht. Probleme beim Skalieren. Also mein Code war so schlecht, dass ich nicht erweitern konnte. Daher rate ich auch vielen ab gleich mit großen Spielen anzufangen. Immer kleines bissel anfangen und Features einbauen. Und, irgendwann merkt man schon bei Kleinigkeiten, dass es nicht so schön ist und man versucht das besser zu machen. Und auf Dauer wird man immer und immer besser darin. Beispiel was klein ist. Ein Spiel wie Mario. Space Invaders. Breakout. Solche Spiele sind sehr simple, aber haben potenzial sehr coole Features zu bekommen. Beispiel Mario Mehrere Levels Speicherpunkte Gegner Bosse Punkte Leben und Respawnsystem Missionen und Events Procedurales Level System (eher nicht für Anfänger gut, aber man würde viel lernen) Space Invaders Gegnergruppen Bosse Events Waffenupgrades / Powerups Inventarsystem Coolere Effekte und Design Levels Breakout Bewegende Blöcke Mehrere Bälle Powerups Und generell jeder könnte Multiplayer bekommen. Multiplayer ist nicht immer einfach :D. Es kommt drauf an. Ich kann ja dazu meine Erfahrung sagen. Ich habe nie Studiert (außer 2-3 Monate ^^ und dann abgebrochen) und sogar keine Ausbildung gemacht. Ich habe mit Programmierung ca. in 2004 angefangen und mir selbst beigebracht und damals gab es keine Tutorials wie heute. Kaum Youtube Videos (glaub youtube gab es damals nicht mal). Damals musstest du VIEL Geld ausgeben um zu lernen. Ich hab dennoch geschafft kostenlos zu lernen. Mein großes Projekt begann damit, als ich eine Webseite in PHP schrieb, was wie Facebook ähnlich aufgebaut war. (Ja.. zeitlich wurde tatsächlich (The)Facebook entwickelt und wir beide hatten die selbe Idee. Ich hab ne Seite geschrieben für Schüler und meine Umgebung, die sich dort finden und sich anschreiben können. So ne Art Social Media / Single Börse. Hätte ich nur gewusst, dass man damit Geld machen kann xD.) Also programmieren konnte ich dann schon so langsam bereits gut, aber immer noch fehlte strukturiertes Vorgehensweise. Falls das interessiert, so sahen sie aus: https://myworks.hardcoded.mywire.org/statics/images/php/fd_1.png https://myworks.hardcoded.mywire.org/statics/images/php/fd_2.png https://myworks.hardcoded.mywire.org/statics/images/php/fd_3.png Durch das Projekt habe ich viel dazu gelernt, wie man es nicht machen sollte, wo meine Sicherheitslücken waren usw., denn die Seite war definitiv hackbar, hehe. Irgendwann begann ich mich fürs Hacken in Spielen zu interessieren. Fing mit AutoIT und C++ an. Ich habe tatsächlich für Counter-Strike Wallhacks geschrieben, aber nur für mich persönlich ab und zu verwendet. Mir ging nur ums lernen. Tatsächlich funktionierte es nach Jahren immer noch. Ich riskierte, aber hab kein Bann bekommen. Vielleicht, weil ich ganz kurz benutzt habe. Hier, muss man gesagt haben, war ich immer noch Anfänger. Ich konnte kaum ohne nachzulesen weiterkommen. Ebenfalls wuchs dadurch meine Interesse für Bots und Automation. Mochte immer mehr alles zu automatisieren. Egal am PC oder in Spielen (auch, wenn es laut AGB nicht darf). Das tat ich meistens mit AutoIt https://i.imgur.com/2MoD3rZ.png <- bei dem Bild sieht man sogar wie ich beschreibe, dass ich ich Captcha Codes automatisch löse (hier war ich aber bereits in Pro ^^). Nach der Webseite Sache in der schulischen Ausbildung war ich damals in der Programmierstunden der "Beste", weil ich einfach zu Fortgeschritten war. Das war 2011 oder so. Trotz des "schwänzens" hat mir der Lehrer eine 1 gegeben, weil er einfach gemerkt hat, dass ich mich zu sehr langweile. Nebenbei liebte ich in Garrysmod mit Expression 2 zu programmieren, weil du in einem Spiel, Multiplayer programmiert hast und gleichzeitig Visual gesehen hast. Beispiel eine Autosteuerung, Flugzeug oder visuelle Effekte, Physik, Züge, Ampel, Simulationen usw. War mega nice. Mein "richtiges" Lernen kam mit C#, denn vorher hab ich kaum über Architektur und andere Dinge bedenken müssen. Kann nicht sagen, wann genau ich C# anschaute, aber ich interessierte mich für Spieleentwicklung, aber mit C++ fand ich das irgendwie nicht so geil. Entdeckte irgendwann XNA was in C# war damit fing es an. Ich mochte direkt C# und wusste, dass diese Sprache mein Mainsprache sein wird. Entdeckte dann Unity ca. in 2012-2013. Nebenbei programmierte ich noch in Lua und habe sogar Aufträge aus dem Internet angenommen. Nach Studiumabbruch ab 2014 war ich selbstständig, denn ich konnte hier bereits richtig gut programmieren, aber Vorgehensweise war noch nicht gut. Sprich, wie sollte alles aufgebaut werden. Skalierbarer usw. Ab hier wurde es aber ernst, weil ich unternehmerisch vorging. 2016 wurde ich dann professionell mit C#, weil ich nun fast alles beherrschte, wie man auch als Developer sein muss, weil ich so viel ausprobiert habe und immer wieder neu und neues angefangen habe und so viel dazu gelernt habe. Das war eigentlich Mega boost kann man sagen und hab mich sehr viel für Dinge interessiert, wie man etwas Aufbaut und Techniken ausprobiert. In Discord sieht man dazu oft was von mir. Theoretisch kann man sagen bin sogar Software Ingenieur. Das heißt, war bereits in dem Level, wo ich Leute sogar beraten kann und sagen kann wie etwas aufgebaut werden muss. Heutzutage könnte ich ein Unternehmen beraten, wenn es in Unity . Naja bissel tue ich das ja tatsächlich. Fazit Was ich damit sagen möchte ist, dass man selbstständig auch gut werden kann. Man muss oft versagen und aus den Fehler lernen, dass macht dich zum "pro". Zum Beispiel hab ich neulich mit Teilzeit angefangen, weil ich unternehmerisch mir neue Erfahrung aneignen wollte. Dort arbeiten Leute die aus dem Studium kommen oder noch Studenten sind. Der Code ist in der Qualität, wo ich 2013/2014 programmiert haben. Also Grotten schlecht. Überall Singletons, Manager und andere Dinge. Vieles in eine Klasse reingepackt. Und sie selbst erkennen bereits, dass nun bald "neu" programmieren müssen, aber geht nicht. Es ist bissel "zuspät". Also das Lernen wie man programmiert ist einfach, aber die Umsetzung von Ideen dafür braucht man etwas länger. Man muss tatsächlich viele praktische Erfahrung haben und sehr oft erkennen, dass hier und da was falsch läuft um nächstes mal das zu vermeiden. Disclaimer: Kann sein, dass nicht alle Jahreszahlen stimmen. Ist einfach zulange her.
    1 point
  6. Hast du denn noch anderweitig irgendwie mit Programmierung zu tun, außerhalb des Selbststudiums in den eigenen 4 Wänden? Eine der wie ich finde wichtigsten Dinge beim Lernen ist oftmals der Input und Austausch von und mit anderen Leuten. Ich hatte beispielsweise die letzten 2 Jahre meines Studium hobbymäßig versucht, mir Programmieren beizubringen. Aber so wirklich Klick hat es erst gemacht, als ich meinen ersten Job hatte und mit Leuten zusammenarbeiten konnte, die mehr Erfahrung als ich hatten. Sowohl sich den Code anderer anschauen und dazu Fragen stellen zu können, als auch Feedback zum eigenen Code zu bekommen, hat mich unglaublich schnell weiter gebracht. In diesem Sinne finde ich auch den Vorschlag mit dem Game Jams nicht schlecht - soweit ich weiß schwören viele Leute darauf dort mitzumachen, selbst wenn man noch nicht so viel Erfahrung hat.
    1 point
  7. Das Buch von Rheinwerkverlag habe auch, fand es allerdings nicht wirklich spannend. https://learn.unity.com/pathway/junior-programmer fand ich allerdings recht hilfreich. Das fängt praktisch bei Null an, arbeitet sich durch diverse Themen und beinhaltet die ganzen Assets.
    1 point
  8. Ich finde Unity als Programmier-Lernumgebung auch super. Aber das ist für jeden unterschiedlich.
    1 point
  9. Empfehle ich dir nicht...sicher hat Unity so seine Eigenheiten, aber es ist für dich eine Plattform auf dem du aufbauen kannst. Erstelle doch einfach mal ein 3D Objekt und bewege es mit den Tasten Dann bewegst du es z.B. über Sin/Cos Dann fängst du an mit Arrays und erstellst GameObjekte die in diesem Array gespeichert werden Dann gehst du das Array durch und löscht das Objekt aus dem "Spielfeld" usw... So lernst du C# und gleichzeitig mit Unity umzugehen... ist meine Meinung...ich empfehle jedem Anfänger mal Snake zu programmieren. Du hast da so ziemlich alles was ein Spiel ausmacht. Ein Spielfeld...Futter für die Schlange...die Schlange die sich bewegt. Mache dir Gedanken wie der Computer es schafft die Schlange zu zeichnen und zu bewegen....einfach mal anfangen.
    1 point
  10. Also ich habe tatsächlich alles über Tutorials gelernt und ne Menge Game Jams gemacht. Ich würde sagen einfach programmieren und wenn du Probleme hast kannst du es einfach in das Forum Posten Man muss am Ball bleiben.
    1 point
  11. Das große Problem am "Programmieren lernen mit Unity" ist, dass du dabei 2 Dinge lernen musst/willst. Das Eine ist das Programmieren selbst. Also quasi eine Sprache zu erlernen. Aber eben nicht nur die Vokabeln sondern auch die richtige Anwendung. Das Andere ist die Besonderheit in Unity, die Objekte, Module und Funktionen zu steuern und Informationen über sie abzufragen. Wenn man sich Tutorials für Unity anschaut, dann wird mehr oder weniger das Können der Programmiersprache vorraus gesetzt und es geht meist nur um die Besonderheiten in Unity. Diese sind zwar alle mit der Programmiersprache verzahnt, aber sie sind eben Obendrauf! Wenn man das Programmieren nicht verstanden hat, kommt man mit den Besonderheiten in Unity nicht weit. Deswegen würde ich empfehlen entweder erstmal nur die Grundlagen des Programmierens zu lernen (unabhängig von Unity). Oder aber mit Unity zusammen, aber dann (egal ob das Projekt einem gefällt oder nicht) nach jedem Schritt zu schauen, ob man verstanden hat was da passiert. Einfach mal eine ähnliches Szenario aufbauen und das Gelernte gleich anwenden. Auch wenn es erst einmal sinnlos erscheint. Schritt für Schritt! Aber das musst du machen! Es einfach nur abtippen um dann zu sehen, dass es bei dir genauso funktioniert reicht nicht. Du musst es zerlegen und analysieren. Es wird dann bestimmt irgendwann Klick machen. Und dann ist alles klar! Es wird immer Dinge geben, die du erst mal nicht verstehst. Aber du wirst mit jedem Mal schneller zur Lösung kommen. Und dann kannst du das Wissen auf alles was du willst anwenden. Du bist bestimmt nicht dumm. Es hat einfach nur noch nicht "klick" gemacht!
    1 point
  12. Tutorials variieren stark in dem, was sie tun. Ich hab da vor vielen Jahren mal diesen Post zu geschrieben, der ein bisschen damit zu tun hat. Es gibt so Tutorials, die ich für meinen Teil als weniger wertvoll erachten würde. Die zeigen dir einfach einmal, wie man eine bestimmte Sache macht. Bessere Tutorials erklären dir dazu noch das Wie und vor allem das Warum. Die erste Sorte Tutorials finde ich deshalb weniger gut, weil sie eine bestimmten Fähigkeit vom Leser erfordern. Der Leser muss in der Lage sein, ein spezifisches Beispiel zu nehmen, die Konzepte dahinter selber (!) zu erkennen und diese dann abstrakt zu verstehen. Wenn du also liest, wie man einem Knopf in der Szene beibringt, eine bestimmte Tür zu öffnen, dann erkennst du mit diesem Skill ganz schnell, dass du dasselbe Konzept auch anwenden kannst, um eine Fernsteuerung zu bauen, die der Spieler in die Hand nehmen kann, um damit ein Auto fernzusteuern. Diese Fähigkeit ist bei Leuten aber unterschiedlich stark ausgeprägt; und ich bin davon überzeugt, dass man sie trainieren kann. Ich glaube, dass wenn du das Gefühl hast, "dumm" zu sein, dann liegt das daran, dass du diese Fähigkeit nicht oder nicht stark ausgeprägt besitzt. Ich würde jemanden dann aber nicht als dumm bezeichnen. Gibt einen Haufen Arten, wie man schlau sein kann. Und das ist nur eine davon. Deswegen finde ich Tutorials besser, die das "Warum" noch mit dabei haben. Wer das nicht alles selber sofort versteht, kann die zugrunde liegenden Konzepte besser erkennen, wenn sie erklärt und nicht nur über Beispiele vorgeführt werden. Davon abgesehen ist es für dich natürlich besser, an dir selbst zu arbeiten und nicht an allem um dich herum. Wenn du also keine Tutorials, Bücher oder anderes hast, mit denen es richtig Klick macht, dann versuche, diese Fähigkeit zu verbessern. Da kannst du, wie @gombolo sagt, einfach immer weiter programmieren. Setze dir selber Ziele. Oder mache Coding Challenges, z.B. hier. Programmieren lernen ist etwas, das deine grundlegende Denkweise beeinflusst. Du gehst als jemand, der diese Fähigkeit hat, mit einer ganz anderen Logik an die ganze Welt heran als jemand, der anders denkt. Sein Gehirn so umzupolen ist ein Prozess, der sehr lange dauern kann. Wenn du das wirklich können willst, darfst du dich von der zähen Reise dahin nicht entmutigen lassen.
    1 point
  13. Programmieren....programmieren...und wieder und immer wieder programmieren. Das ist der einzige Weg die Programmierung zu erlernen und ab und zu tut es gut mal ein paar Tage nicht zu programmieren damit die Synapsen Zeit habe sich zu verknüpfen 😃
    1 point
  14. Moin! Die TestRunner.dll solltest du im Build nie brauchen. Die ist ja für die Tests im Editor da. Wenn er also meint, die beim Builden nicht zu finden, dann ist das... okay? Die Warnung suggeriert allerdings, dass Unity trotzdem versucht hat, sie zu finden. Und das ist komisch. Aber eher weniger bedenklich. Wenn du versehentlich Test Code im Build hättest, gäbe es einen scheppernden Error und keine sanfte Warnung. Burst ist ja der neuere Compiler von Unity, der (und da korrigiert mich gerne) vor allem zum Ausspucken performanteren Codes da ist. Ist iirc verbunden mit DOTS und so. Wenn du davon nichts nutzt, dann brauchst du Burst Support auch nicht. Oder anders gesagt: Wenn du nicht weißt, was Burst macht, dann brauchst du ihn nicht Mit der Plattform hat es nichts zu tun. Unity kann ohne Burst auf jede Plattform builden.
    1 point
  15. Das ist ja keine Warnung vom Compiler. 65 ist die Zeilennummer, bei deiner pragma-Zeile muss aber der Fehlercode rein. Wenn du also Compilerfehler cs0649 kriegst, kannst du das mit #pragma warning disable 0649 deaktivieren. Hier hast du aber keine Compilerwarnung, sondern ein Debug.LogWarning, das zur Laufzeit fliegt. Und zwar aus einer Unity-Komponente heraus. Die kannst du nicht deaktivieren. Hier hast du aber zum Glück keinen nervigen, unvermeidbaren Spam, sondern eine reale und sinnvolle Warnung, weil etwas in deinem AnimatorController falsch verkabelt ist. Das solltest du dir vielleicht einfach mal ansehen.
    1 point
  16. Du brauchst eine Bedingung um die Animation zu beenden bzw. zu stoppen. Entweder setzt du einen Haken bei "Has Exit Time" oder du erstellst einen Parameter und verknüpfst diesen mit der "Animation". Was willst du den eigentlich genau machen? Edit: ich würde Warnungen nie mit einer Präprozessor-Direktive deaktivieren...es gibt schon einen Grund für die Warnung und außerdem ist das nicht schön
    1 point
  17. Hallo gombolo, richtig, mein Team besteht aus mir allein. Alle Projekte habe ich zu 100% allein erstellt. Es geht mir immer recht gut von der Hand.
    1 point
  18. Hallo, Einen Hab ich noch 😉 LateUpdate Wird zwar oft nicht verwendet oder vergessen dass es die überhaut gibt, ist aber in machen Situationen wichtig. Die Methode LateUpdate() wird aufgerufen, nachdem alle Update-Funktionen aufgerufen wurden, aber noch vor dem Rendern. Dies ist nützlich, um die Skriptausführung zu ordnen. Zum Beispiel sollte eine Verfolgerkamera, in der LateUpdate() Methode implementiert sein, da Objekte nachverfolgt werden, die möglicherweise in Update oder FixedUpdate Funktionen bewegt wurden. Dies sollte sicherstellen dass, alle verfolgten Objekte bewegt wurden, bevor die Kamera aktualisiert wird, um ein „Nachspringen“ der Kamera zu vermeiden. Gruß Jog
    1 point
  19. Falls Englisch für dich okay ist... http://blog.13pixels.de/2019/what-exactly-is-fixedupdate/ FixedUpdate ist das MonoBehaviour-Event, mit dem du wirklich Framerate-unabhängig wirst. In einigen Fällen reicht Update auch, z.B. weil es um einen linearen Ablauf geht oder der Unterschied nicht für das Spiel entscheidend ist. Wenn z.B. eine Knopf-Animation bei unterschiedlicher Framerate minimal anders aussieht, ist das meistens kein Beinbruch. Update hat allerdings dieselbe Frequenz, auf der das Spiel rendert. FixedUpdate nicht. Du kannst mehrere Updates (und damit auch Renders) zwischen zwei FixedUpdates oder mehrere FixedUpdates zwischen zwei Updates haben. Wenn du merkst, dass du FixedUpdate nutzen willst, dann musst du mit etwas Code das Stottern beseitigen. Wenn du dir mal den Inspektor der Rigidbody-Komponente anschaust, siehtst du da die Eigenschaft "Interpolate". Die macht genau das, weil Rigidbodys mit der Physik-Engine auf FixedUpdate laufen, aber dann bitte auch nicht stottern sollen. In meinem Artikel oben hab ich ein Script verlinkt, das das für beliebige Objekte machen kann.
    1 point
  20. Wenn ich mir die Skripte kurz anschaue sehe ich beim zweiten direkt, dass dieses Skript die FixedUpdate-Methode verwendet. Diese wird unabhängig zur Framerate (Standardm. 50x pro Sek.) ausgeführt, weshalb diese für eine wirklich flüssige Bewegung für Animationen nicht verwendet werden sollte. Stattdessen sollte Update verwendet werden. Jedoch muss darauf geachtet werden, dass die Bewegungsgeschwindigkeit dann nicht an der Framerate gekoppelt ist. Das erste Skript macht es da schon grundsätzlich richtig, denn mit Time.deltaTime erhält man die Zeitspanne seit dem letzten Frame und man kann dementsprechend den richtigen frame unabhängigen Zielpunkt bestimmen. Ohne den Code aufs Detail zu analysieren bin ich mir aber nicht sicher, dass die gewählte mathematische Funktion für die Berechnung der Zielposition für dein Vorhaben geeignet ist. Außerdem verwendest du einmal Slerp und beim anderen Lerp. Wenn es darum geht, dass eine Kamera ein Objekt folgen soll, empfehle ich, dass du dir Cinemachine anschaust, dann musst du dir mit der Implementierung nicht den Kopf zerbrechen und alles andere ist Einstellungssache.
    1 point
  21. Hallo, es gibt etwas Neues vom Projekt. Bisher hatte ich nur eine Bevölkerungsgruppe, die Siedler. Alle Gebäude und Einrichtungen wurden von Siedlern bedient. Die Ausbaustufen der Häuser beinhalteten auch nur eine größere Anzahl von Siedlern. Ziel war es somit nur eine ausreichende Anzahl von Siedlern in der Stadt/Dorf zu haben. Durch die unterschiedlichen Bevölkerungsgruppen entsteht jetzt eine größere Dynamik. So besiedelt dann nach einem Aufstieg der Unterkünfte nur die nächste Bevölkerungsgruppe diese Unterkunft. Die vorhergehende Gruppe muss dann ausziehen. Desweiteren werden dann die Produktionsgebäude von unterschiedlichen Bevölkerungsgruppen bedient. So wird es neben den Siedlern dann Bauer, Arbeiter/Handwerker, Bürger und Gelehrte geben. Als Aufstiegsvoraussetzungen wird neben den Verschönerungen dann auch Bildung und Kultur geben.
    1 point
  22. Hi, wollte euch hier nur informieren dass es bald ein neues tool für Unity gibt "Nano Tech", was ähnlich wie Nanite funktioniert, hierzu werde ich ein crowdfunding starten! Das Tool ist momentan noch ein Prototyp, die Grundfunktionen sind aber schon eingebaut: https://www.indiegogo.com/projects/the-unity-improver-nano-tech Proof of concept ist somit schon erledigt, jetzt gehts hauptsächlich ums verbessern und optimieren. Ich hoffe ihr könnt mich dabei unterstützen, es gibt auch ein kleines Asset als Geschenk für die newsletter Anmeldung! Das crowdfunding soll helfen, das Tool noch besser zu machen! Beste Grüße, Chris P.S.: Hier ein link wenn ihr was zur englischen forum variante besteuern möchtet: https://forum.unity.com/threads/nano-tech-similar-to-nanite-high-detailed-rendering-for-hdrp-urp-and-built-in-rp.1292223/
    1 point
  23. Vielen Dank! das ganze Video war auf jeden Fall extrem Aufwändig und ich musste für solche Effekte einige Tricks nutzen. Es handelt sich bei den Animationen aus einer Mischung von Unity 3D und Cinema 4D. Für den Übergang von 3:11 bis 3:15 wurden beispielsweise 8 verschiedene Renderpässe / Rendervorgänge benötigt: - Zwei dieser Pässe bestehen aus ein in Unity gerendertes statisches Bild, welches in Cinema 4D auf Geometrie projiziert wurde - Zwei weitere für eine beleuchtete Geometrie - Zwei Wireframe-Versionen - Und zuletzt zwei Masken, die in After Effects dabei helfen, alles zu dem gewollten Effekt zusammen zu mischen. Hier mal ein Beispiel mit dem Frame 139 dieser Animation: Die anschließende Welle war dabei relativ einfach, hier wurde die Szene ein weiteres Mal gerendert. Das rote Netz war hier während der gesamten Animation sichtbar, so konnte ich während der Videobearbeitung entscheiden, wann ich es ein oder ausblende. Die verformende Animation wurde ebenfalls in Cinema 4D erstellt. Insgesamt wurde diese Szene mit allen Effekten 13-mal mit verschiedenen Einstellungen gerendert. So ähnlich hat es sich während des ganzen Videos durchgezogen.
    1 point
  24. Moin, hier mal ein neues Video von mir. Ich stelle hier die Funktionsweise verschiedener Reflexionstechniken anhand der Unity-Engine, in Verbindung mit gerenderten Szenen vor und zeige einen direkten grafischen Vergleich der einzelnen Techniken. Verglichen & erklärt wird das Ray-Traced Reflection, Screen-Space Reflection, Planar Reflection und die klassischen Cubemaps. In diesem Video habe ich versucht, soviele Details wie möglich einfließen zu lassen, ohne Zuschauer, die nicht mit der Spieleentwicklung vertraut sind "abzuschrecken". Jedoch denk ich, dass die Informationen meiner Recherche, die auch auf der Analyse des Sourcecodes einiger Renderer/Renderpipelines basiert, in dieser Form auch für den ein und anderen Entwickler interessant ist. Ich wünsche mal viel Spaß mit dem aufwendigsten Video, das ich bisher gemacht habe:
    1 point

Announcements

Hy, wir programmieren für dich Apps(Android & iOS):

Weiterleitung zum Entwickler "daubit"



×
×
  • Create New...