Life Is Good
-
Posts
696 -
Joined
-
Last visited
-
Days Won
17
Life Is Good's Achievements
Advanced Member (3/3)
91
Reputation
-
Marching Cubes generiert ein normales Mesh aus einer SDF, den musst du gar nicht "auf einen Planeten anwenden", der Algor_i_thmus bleibt genau gleich. Den groben Lösungsansatz siehst du in seinem Video beim Planeten float distance = radius - length(pos) + noise(pos); Das ist in dem Fall deine SDF, wobei die SDF einer Sphäre float SphereSDF (vec3 pos) { return length(pos) - radius; } ist (normalerweise genau umgekehrt, aber das macht nichts, dann kehrt sich einfach nur dein Distanzwert um). Das erklärt also warum du ne Kugel rauskriegst. Was dir fehlt ist noise(pos) und hier wirds deutlich schwieriger. Im Grunde versuchst du mit Funktionen so rumzumodellieren dass du irgendeine modifizierte Form deiner Kugel kriegst. Es gibt jede Menge unterschiedliche Algorithmen um die unterschiedlichsten Ergebnisse zu erzielen. Da wirst du wild ausprobieren müssen und das wird dauern bis du auf ein Ergebnis kommst mit dem du zufrieden bist.
-
Entity Component Systems & Data Oriented Design In Unity
Life Is Good replied to Life Is Good's topic in Text Tutorials
Nein, sorry. Ist aber höchstwahrscheinlich sowieso schon veraltet. Ich würde an deiner Stelle nach neueren Resourcen suchen. -
Passend dazu, und auch zu Unity's ECS, lass ich mal diesen exzellenten Artikel hier liegen https://www.gamedev.net/blogs/entry/2265481-oop-is-dead-long-live-oop/
-
Entity Component Systems & Data Oriented Design In Unity
Life Is Good replied to Life Is Good's topic in Text Tutorials
Hab das repository mal aktualisiert, und die 3 Themengebiete auf 3 unterschiedliche PDFs aufgeteilt. Ich glaube das wirkt einfach besser, und überfordert nicht so sehr. https://github.com/LifeIsGoodMI/ECS-And-DoD-In-Unity Hier auch nochmal im Anhang. ECS_StartGuide.pdf ECS_Unity_Article.pdf The_Core_Of_Unitys_ECS_Documentation.pdf -
Ich hab einen nicht so kurzen Artikel über Unity's Implementation eines Entity Component System (ECS) Model & Data Oriented Design (DoD) geschrieben. Es ist keinerlei Vorwissen über ECS oder DoD erfoderlich. Der Artikel behandelt die Prinzipien von ECS, DoD, beinhaltet eine eigene kleine Dokumentation über die fundamentalen Konzepte von Unity's ECS und enthält einen kleinen Start Guide, indem ich Stück für Stück zeige wie man ein sehr simples "Spiel" umschreiben kann. Am Ende kommt dann noch ein kleiner, kritischer Kommentar zu Unity. Sowas muss man natürlich nicht am Stück lesen, man kann da durch springen wie man will. Ihr findet den Artikel und das Unity Projekt auf meinem GitHub Account: https://github.com/LifeIsGoodMI/ECS-And-DoD-In-Unity Ausserdem scheints so, als würde GitHub's PDF Viewer keine Hyperlinks unterstützen, also hab ich die PDF hier noch einmal zusätzlich angehangen. ECS_DoD_Unity.pdf
-
Ich hab den Algorithmus ein wenig angepasst, um das Problem mit den weichen Ecken zu lösen. Im Grunde schau ich mir einfach die vertices an, die nicht ganz korrekt sind, addier alle Normalen zusammen (nennen wir das Ergebnis einen Vektor A) und interpoliere dann von diesem Vertex aus in die Richtung A bis die SDF an diesem Punkt = 0 ist. Ich musste allerdings einen kleinen Bias einbauen, aber ich denke das sind einfach bloß Genauigkeitsprobleme, da die Implementation aktuell komplett auf floats setzt. Die schwarzen Linien am Ende zeigen das Ergebnis der Normalen (Vektor A) bei den Vertices, die zunächst gesmoothed wurden. Ich werd noch mehr testen müssen, um zu schauen, ob die Lösung so allgemein aufrecht erhalten werden kann.
- 1 reply
-
- 4
-
-
Hey, Ich experimentier aktuell mit meiner eigenen Idee rum, Oberflächen aus Distanzfunktionen (signed distance function, SDF) zu generieren. Ihr könnt meinen Ansatz in diesem Thread verfolgen, falls ihr euch für so Voxel Zeugs interessiert: https://www.gamedev.net/forums/topic/697431-a-novel-approach-to-non-manifold-dual-contouring/ Im Grunde gehts darum Eckpunkte (vertices) durch Schnittpunkte von Oberflächenkanten (surface edges) ausfinding zu machen. Die 2D Methode scheint ohne probleme zu funktionieren, und ermöglicht so auch scharfe geometrische Features wie Ecken. (dabei ist's auch deutlich einfacher zu verstehen, als 2D Dual Contouring) Mit dem 3D Ansatz bin ich aktuell noch ein wenig am kämpfen, aber erste Ergebnisse gibts dazu auch schon, wie ihr hier nochmal sehen könnt:
- 1 reply
-
- 5
-
-
Happy Flappy Unicorn ( Kobolde anzukotzen )
Life Is Good replied to Ahteris's topic in Vorstellung eurer Projekte
Ich find die Grafiken toll! Sieht gut aus. -
Ich hab mal ein wenig Code auf mein GitHub profil hochgeladen.
Simple, leichte und (relativ
) saubere Implementationen von A* und Flow Fields pathfinding (bei A* fehlt noch ein kleines Video oder so...)
Mir ist aufgefallen, dass gerade zu A* ziemlich verwurstelte Code Beispiele bei Google rauskommen
Wen sowas interessiert, der kann ja mal reinschauen. Vielleicht schreib ich auch mal 'ne Tutorial oder so dazu.
A* https://github.com/GoGreenOrDieTryin/Unity-A-Star
Flow Fields https://github.com/GoGreenOrDieTryin/Unity-Flow-Fields-
Darf man Kritik äußern xD? Warum übergibst du den Start/Ende/Grid im Konstruktor. Jetzt musst du jedesmal ein neues A* Objekt erzeugen wenn du ne neue Suche machen willst...
Ansonsten wenn du mehr Performance haben willst nutz nen Heap. Der sorgt dafür das du nicht immer durch die ganze Liste iterierst wenn du den besten Knoten haben willst.
Aber ansonsten ne schön einfach zu verstehende A* Implementierung. Aber weil ich angeben will hier ist meine https://github.com/Djeurissen/SmartAI/blob/master/SmartAI/Search/AStarSearch.cs
-
-
1
-
- Report
-
Klar ! Es kann nie sauber genug sein
Dabei hab ich mir ehrlich gesagt nichts besonderes gedacht, einfach so simple wie möglich gehalten.
Eigentlich hätte ich start & ende auch einfach public machen können, um die dann über den Inspector zu zuweisen.Zum Speicher:
Absolut. Ich halt meistens bloß so viel wie möglich lokal. Wenn man daraus was größeres machen würde, könnte man allein dadurch noch gut was an Performance rausholen.Dein Code gefällt mir übrigens auch gut.
-
Muss ich doch Glatt mal Testen, Suche schon lange was gescheites^^ Meine versuche Schlugen leider fehl und ergaben das die KI 6754374 meter neben den Pfad rumm eierte^^
-
-
Gekürzt //... using System.Linq; //... [SerializeField] private GameObject[] gameObjects; //... gameObjects.ToList().ForEach(go => { if (go.activeSelf) go.SetActive(false); }); //...
-
Ich bin mal ein wenig durch meinen Code gesprungen. An einer Stelle muss ich sehr häufig über eine kleine Anzahl an Elementen iterieren
Foo target; for (int i = 0; i < 4; i++) if (collection[i].flags == fooFlag) target = collection[i];
Ein ganz simples Stück Code also.
Linq sieht aber natürlich sehr viel hübscher aus, also hab ich statt des Oberen Schnipsels zu erst so was hier gemacht
var target = collection.First(e => e.flags == fooFlag);
Was ich beobachtet habe: Das 2. ist halb so schnell. Das sind 20ms, statt 10ms (wird jeden Frame aufgerufen, d.h. zweiteres erfüllt schonmal gar nicht mehr die 60hz Anforderung, was ja heute ziemlich standard ist.... Macht also viel aus !)
- Show previous comments 10 more
-
Ohh, bist du auf der aktuellsten Version ? Ich hab gehört dass das NavMesh mit der neuen Version ein wenig kaputt gegangen sein soll. Ich hab's das letzte mal vor nem Jahr oder so verwendet und da ging sowas noch.
-
Na, das Problem existiert zumindest seit Version 5.4.1. Ich muss es mal in Unity 2017 nochmal testen, aber glaube nicht, daß an der Ecke was passiert ist:
https://feedback.unity3d.com/suggestions/navmesh-agent-local-avoidance-recalculate-navmesh-path-when-another-agent-get-in-the-way
Wenn man mit einer handvoll Agenten hantiert, merkt man das Problem noch nicht unbedingt, da die local avoidance auf sehr kurzen "Ausweichpfaden" noch funktioniert (also wenn nur 2 Agenten aneinander vorbeilaufen sollen).
Ein typischer Testfall ist, du lässt 20 Agenten zu einen Ziel laufen (z.b. Spieler). Beim Unitynavmesh klumpen die Agents dann an einer Stelle vor dem Spieler (aus Laufrichtung) zusammen (und stapeln sich teilweise hintereinander auf). Eigentlich sollten aber die Agents den Spieler einkreisen. Gibt auch noch andere Probleme an engen Stellen auf dem Navmesh, wenn sich die Agents "treffen". -
Ich hab's bloß mit einer handvoll Agenten getestet also
¯\_(ツ)_/¯
-
void Start() { c = new TEST(); } Du rufst hier den Konstruktor von TEST auf, Unity rät ausdrücklich davon ab, das bei von MonoBehaviour abgeleiteten Klassen zu tun. Dazu solltest du auch eine Meldung in der Konsole sehen. C# hat übrigens keine Pointer, sondern bloß Referenzen.
-
Ich bin gerade dabei meinen Path Tracer auf die GPU zu porten, dabei ist mir was interessantes aufgefallen.
Ich hab den selben Code 2 mal mit bloß einem Unterschied:
Der eine ist rekursiv, der andere iterativ (da Recursion ja nicht so doll für GPUs ist )
Ansonsten hab ich nichts verändert !
Die Ergebnisse sind identisch.
Und jetzt kommts:
Der rekursive hat 10min und 11sek gebraucht, der iterative bloß 157sek.
Das ist ein Performance boost von etwa 390% !!
Skaliert wohl mit längeren Berechnungen noch mehr. -
Nach 3h debuggen den Fehler meines kleinen Path Tracers gefunden. Ich hab vergessen meine Vektoren im Default Constructor mit 0, 0, 0 zu initialisieren. Ich komm mir gerade verdammt blöd vor
- Show previous comments 1 more
-
Joa ich hab auch schon mal einen Abend und den halben nächsten Tag damit verbracht einen Bug zu suchen, weil ich eine Component am falschen GameObjekt angehängt hab.. Da kommt man sich echt dämlich vor ^^
-
Ist doch nice. Ist zwar erst einmal bicht so toll, aber aus solchen Fehlern lernt man am besten. Mir geht's zumindest so.
-
Jup, ist bloß etwas frustrierend, wenn man seinen Code wieder durchgeht und den Fehler nicht findet. Normalerweise hab ich so grob 'ne Ahnung was der Fehler ist
-
Tesselation Shader können sowas. Unity selbst bringt aber keinen mit. Ich glaube Sascha hier aus dem Forum hatte mal selbst einen geschrieben und in den Asset Store gestellt, wenn nicht sind da auf jeden Fall andere zu finden (RTP Pack z.B. kommt auch mit einem Tesselation Shader)
