Jump to content
Unity Insider Forum

Zer0Cool

Members
  • Content count

    1,865
  • Joined

  • Last visited

  • Days Won

    132

Zer0Cool last won the day on June 14

Zer0Cool had the most liked content!

Community Reputation

389 Excellent

7 Followers

About Zer0Cool

  • Rank
    Advanced Member
  • Birthday 01/04/1974

Contact Methods

  • Website URL
    http://https://www.facebook.com/huginmuninstudios
  • Skype
    zer0f0rce

Profile Information

  • Gender
    Male
  • Location
    Germany

Recent Profile Visitors

4,516 profile views

Single Status Update

See all updates by Zer0Cool

  1. So mal wieder ein Update zu dem Grasrenderer an dem ich immer noch arbeite. Ich habe noch einmal das Wegdrücken des Grases durch den Spieler (in dem Fall ein Ball) überarbeitet. Im Video habe ich das Gras zudem auch einmal mannshoch generiert, damit der Effekt besser wirkt. Weitere Fortschritte im Projekt sind, daß ich nun die Graspositionen des Unityterrains auslesen kann und mit diesen den Grasrenderer "füttern" kann. Es gibt aber immer noch viel zu tun, unter anderem muss ein Paging für das Auslesen der Positionen des Unitygrases eingebaut werden.

    So viel Spaß damit, ich hoffe ich bin nicht zu schnell gerollt ;)
    https://streamable.com/zynfr

    1. Show previous comments  6 more
    2. Zer0Cool

      Zer0Cool

      Ist noch nicht "eingebaut", wäre aber ein nettes weiteres Feature, ich habe sowieso alle Positionen aller Grasdetails permanent im Speicher, daher lassen sich solche Features recht schnell umsetzen. Das Hauptproblem bei so etwas ist immer ein effizienter Speicherzugriff, damit bei einem Entfernen von Gras nicht die Performance droppt...

      Das System "kann" sehr interaktiv sein und trotzdem performant, dies liegt an der verwendeten Technik. Es werden sowieso alle Grasdetails in jedem Frame über ein Speicherarray neu gezeichnet. Manipuliert man dieses Array kann man Instanzen hinzufügen oder entfernen. Man sollte dies eben nur nicht unbedingt jedes Frame tun, da eben auch ein Speicherzugriff Performance kostet.

      Aktuell habe ich eingebaut, daß das Gras bereits auf den Spieler reagiert, dies macht der Shader und kostet daher "fast" keine Performance.
      Bin gerade dabei ein kleines Video zu machen mit einer kleinen UI, welches alle Settings vorstellt, werde ich heute oder morgen mal Hochladen.

      Ich kann dir später gern das System als Betatest zur Verfügung stellen, wenn es dann halbwegs fertig ist, dann habe ich auch gleich einen guten Test des Systems.

    3. Thariel

      Thariel

      Ich weiss nicht, wie du es machst, aber ich hab mal ein Speichersystem entwickelt, das während des spielens permanent alles direkt speichert. Da hatte ich auch das Problem, dass jedes mal die Suche nach dem passenden Objekt im Savegame viel zu viel Ressourcen in Anspruch nahm. Da hab ich sowas wie eine Bibliothek gemacht... Hab die Objekte ein einzelne Savegames aufgeteilt (A1, A2, A3, ...) und je nach Position des Objektes gab es ein zugehöriges File. So ging das dann einigermassen, aber hab das dann sein gelassen.

      Ich würde mich schon für ein Test interessieren :)

    4. Zer0Cool

      Zer0Cool

      Ich habe ja mit Absicht alle Objekte in eine Speicherstruktur gelegt, damit diese als Block an die GPU übergeben werden kann, damit entsteht jeweils nur 1 Drawcall für alle Gras-Instanzen. Jedesmal wenn man Speicherzugriffe macht, Speicher umstrukturiert oder Speicher zusammenlegt verliert man Performance und da dies meist jeweils pro Frame durchgeführt werden müsste, sollte man dies vermeiden solange es geht.
      Wenn ich später wirklich einmal ein Objekt "suchen" muss, dann erledigt das der Compute-Shader. Dieser bekommt sowieso bereits alle Instanzen "in die Hand" und kann solche Filteraktionen extrem performant durchführen. Der Compute-Shader filtert mir aktuell bereits alle Instanzen aus, die nicht im Kamera-Frustum liegen und er filtert Instanzen die Out-of-Range sind.

×