• Announcements

    • Lars

      Allgemeine Forenregeln   03/13/2017

      Forenregeln Nimm dir bitte einen Moment um die nachfolgenden Regeln durchzulesen. Wenn du diese Regeln akzeptierst und die Registration fortsetzen willst, klick einfach auf den "Mit der Registrierung fortfahren"-Button. Um diese Registration abzubrechen, klick bitte einfach auf den "Zurück" Button deines Browsers. Wir garantieren nicht für die Richtigkeit, Vollständigkeit und Brauchbarkeit der Nachrichten und sind auch nicht dafür verantwortlich. Die Beiträge drücken die Meinung des Autors des Beitrags aus, nicht zwangsläufig das, wofür die Forensoftware steht. Jeder Nutzer, der denkt, dass ein veröffentlichter Beitrag unzulässig bzw. störend ist, ist aufgefordert uns unverzüglich per E-Mail zu kontaktieren. Wir haben das Recht störende Beiträge zu löschen und bemühen uns, das in einem realistischem Zeitraum zu erledigen (sofern wir beschlossen haben, dass die Löschung notwendig ist). Du akzeptierst, durchgehend während der Nutzung dieses Services, dass du dieses Forum nicht dazu missbrauchen wirst, Inhalte zu veröffentlichen, welche bewusst falsch und/oder verleumderisch, ungenau, beleidigend, vulgär, hasserfüllt, belästigend, obszön, sexuell belästigend, bedrohlich, die Privatsphäre einer Person verletzend oder in irgend einer Art und Weise das Gesetz verletzen. Des Weiteren akzeptierst du, dass du keine urheberrechtlich geschützte Inhalte ohne Erlaubnis des Besitzers in diesem Forum veröffentlichst. Mit dem Klick auf den "Mit der Registrierung fortfahren"-Button, akzeptierst du zudem unsere Datenschutzerklärung und stimmst der Speicherung deiner IP-Adresse und personenbezogenen Daten zu, die dafür benötigt werden, um dich im Falle einer rechtswidrigen Tat zurückverfolgen zu können bzw. permanent oder temporär aus dem Forum ausschließen zu können. Es besteht keine Pflicht zur Abgabe der Einwilligung, dies erfolgt alles auf freiwilliger Basis.   Zusatzinformationen Der Forenbetreiber hat das Recht, Nutzer ohne Angabe von Gründen permanent aus dem Forum auszuschließen. Des Weiteren hat er das Recht, Beiträge, Dateianhänge, Umfrage, Blogeinträge, Galleriebilder oder Signaturen ohne Angabe von Gründen zu entfernen. Mit der Registrierung verzichtest du auf alle Rechte an den von dir erstellten Inhalten, bzw. treten diese an das Unity-Insider.de und Unity-Community.de ab. Dies bedeutet im Klartext, dass das Unity-Insider.de und Unity-Community.de frei über deine Texte verfügen kann, sofern diese nicht wiederum die Rechte anderer verletzen. Es besteht weiterhin kein Anspruch von registrierten Nutzern bzw. ehemaligen registrierten Nutzern darauf, dass erstellte Inhalte und/oder die Mitgliedschaft (User) wieder gelöscht werden (Erhaltung der Konsistenz dieses Forums).   Einwilligungserklärung Wenn du mit der Speicherung deiner personenbezogenen Daten sowie den vorstehenden Regeln und Bestimmungen einverstanden bist, kannst du mit einem Klick auf den Mit der Registrierung fortfahren-Button unten fortfahren. Ansonsten drücke bitte Zurück. Stand: 07.03.2011

Life Is Good

Members
  • Content count

    625
  • Joined

  • Last visited

  • Days Won

    6

Life Is Good last won the day on February 19

Life Is Good had the most liked content!

Community Reputation

56 Excellent

About Life Is Good

  • Rank
    Advanced Member

Profile Information

  • Gender
    Male
  • Location
    Köln

Recent Profile Visitors

2,664 profile views
  1. Erstmal solltest du dir natürlich nicht vorschreiben lassen, wie du deinen Code organisierst. Aber doch, das ergibt eigentlich schon eher Sinn, das alles ist ja direkt den Spieler betreffend. Das "normalste" ist wohl einfach eine Methode in deiner Spieler Klasse zu definieren, die Schadensberechnung durchführt, und dann rufst du halt von Gegner, Projektil, whatever einfach die Methode auf. public class PlayerHealth : MonoBehaviour { public void TakeDamage (float damage) { // Schadensberechnung usw. } } public class Projectile : MonoBehaviour // nur als Beispiel, kann natürlich auch ein Partikel oder so sein... { private void OnCollisionEnter (Collision collision) { var playerHealth = collision.gameObject.GetComponent<PlayerHealth>(); // Kein Spieler wurde getroffen. if (playerHealth == null) return; playerHealth.TakeDamage (damage); } } Das würde ich auch zum Spieler packen Zum langsamen Fallen: Du multiplizierst immer noch mit Time.deltaTime
  2. Ohh ja ich hab zum "schnellen" debuggen einfach zellen mit unterschiedlichen Farben instantiert. Mal schauen. Danke für die Links, den 2. kannte ich noch nicht.
  3. Ja ! Ich hab wirklich nicht erwartet so schnell jemand anderen zu finden. Es gibt ja auch kaum Material dazu. Die Seite kenn ich, ist glaub ich auch das einzige praktische was man zu Continuum Crowds findet. Ist eigentlich ein bisschen komisch, da CC ja anscheinend in größeren Spielen schon relativ oft Anwendung gefunden hat (bzw. eine abgeänderte Version) Wie zufrieden bist du denn mit deinen Ergebnissen ? Discomfort und Höhen werden bei mir auch passend behandelt, aber irgendwie passt das mit der gegenseitigen Erkennung bei mir noch nicht, die Personen laufen einfach ineinander, sogar in der selben Gruppe. Ich glaube ich hab bei der Berechnung der Dichte Werte noch irgendwo einen Fehler drin...
  4. Ja, besser gesagt ich versuch's zumindest Ich bin vor ein paar Tagen auf die Info gestoßen, dass die original Implementation mit OpenCL war, also doch auf der GPU lief. Danke für den Link ! Ich denke ich werd sowohl GPU durch Compute Shader als auch Multithreading auf der CPU unterstützen.
  5. Danke, ich weiß, dass es relativ einfach sein sollte das zu parallelisieren. Ich will's aktuell bloß nicht tun. Marching Cubes haben übrigens aber auch nicht viel mit Fast Marching zu tun
  6. Jo, ich hab auch schon daran gedacht das zu parallelisieren. Im Paper das ich lese wird aber leider nicht klar ausgedrückt, ob der Algorithmus tatsächlich parallelisiert wurde. Deswegen bin ich mir gerade verdammt unsicher, ob ich nicht einfach blödsinn gemacht habe Ich übersetz den Code gerade noch in C++, einfach um mal zuschauen was das nochmal für einen Unterschied ausmachen würde.
  7. Ohhh tatsächlich ! Im Build sind es immerhin nur noch etwa 6-7 Sekunden. Zwar immer noch deutlich langsamer aber immerhin. Ich glaub ich muss allgemein versuchen meine Implementation performanter zu kriegen... Eigentlich sollte die methode alle 2-3 Frames durchlaufen können
  8. Hey Ich bin gerade ein bisschen ratlos. Ich hab bei mir in Unity die Fast Marching methode implementiert - und musste feststellen, dass sie wahnsinnig langsam ist (Etwa 15 Sekunden). Eigentlich so langsam das etwas nicht stimmen kann. Ich hab dann testweise einfach mal den Code gepackt und den in eine leere C# Konsolenanwendung geschmissen. (heißt natürlich auch .Net 4.5.2) und der selbe Code braucht da bloß etwa 3 Sekunden (VS im Debug Mode, Release nochmal etwas schneller) Meine Frage ist also, ob jemand eine Idee haben könnte warum das in Unity so langsam läuft. Hier der Code: // Der Einfachheit halber ist die Methode statisch und nimmt Group direkt als Parameter an. // Eigentlich würde die Methode über eine Anzahl an Gruppen in der 1. for schleife iterieren. private static void FastMarching(Group group) { // for each group for (int i = 0; i < 1; i++) { group.unknown = new List<GroupCell>(); group.known = new List<GroupCell>(); group.candidate = new List<GroupCell>(); // GridCells enthält 10.000 Elemente. for (int j = 0; j < group.gridCells.Length; j++) { var cell = group.gridCells[j]; // Zu Beginn sind alle Zellen in der unknown liste. group.unknown.Add(cell); cell.isCandidate = false; // 100 Elemente in gridCells sind hier mit isGoal = true markiert. if (cell.isGoal) { cell.isKnown = true; cell.isUnknown = false; group.known.Add(cell); group.unknown.Remove(cell); } // 9.900 demnach nicht. else { cell.isKnown = false; cell.isUnknown = true; } } // Ziel erreicht, wenn keine Zellen mehr in der unbekannten Liste liegen. while (group.unknown.Count > 0) { // Diese For schleife ist auch zugleich die lastigste (logischerweise) for (int j = 0; j < group.known.Count; j++) { var cell = group.known[j]; // Holt sich einfach die 4 direkt angrenzenden Zellen einer gegebenen Zelle (cell) // Das Grid ist also 2 dimensional. var neighbours = Grid.GetNeighbourCells(width, length, group.gridCells, cell); for (int k = 0; k < 4; k++) { var neighbour = neighbours[k]; if (neighbour != null && neighbour.isUnknown) { neighbour.isCandidate = true; neighbour.isUnknown = false; group.candidate.Add(neighbour); group.unknown.Remove(neighbour); } } } for (int j = 0; j < group.candidate.Count; j++) { // Nichts wichtiges hier. } GroupCell bestCell = null; for (int j = 0; j < group.candidate.Count; j++) { // Nichts wichtiges hier, liefert einfach die beste Zelle zurück. } bestCell.isCandidate = false; bestCell.isKnown = true; group.known.Add(bestCell); group.candidate.Remove(bestCell); } } } Edit: Ich hab die Konsolenanwendung mal auf .Net 2.0 geändert und der Code läuft auch bloß minimal langsamer, also weit von den Werten in Unity entfernt. Edit 2: Unwichtige Codestellen entfernt.
  9. Ich habe meine ersten Schritte in Richtung Programmierung so mit 13 Jahren gemacht, damals noch mit Acknex' 3D Gamestudio & Lite C. So nach nem halben Jahr hab ich dann aber gemerkt, dass ich zu blöd dafür war weiter zukommen und bin mit 3.X auf Unity & C# gewechselt. Ich hatte irgendwie immer eine Ablehnung für solche Bücher (die sind einfach tot langweilig in meinen Augen ) also hab ich mir im Grunde alles mit Tutorials und ausprobieren beigebracht. Das Forum hier hat natürlich auch viel dazu beigetragen (wenn ich mich an die ganzen blöden Fragen zurückerinnere die allein Sascha oder Mark mir beantwortet haben ). Ich bin kein Profi, aber ich würde sagen mitlerweile bin ich auch ein ganz passabler Programmierer geworden. Ich glaube viel zu meiner Entwicklung hat auch die Tatsache dazu beigetragen, dass ich nicht so gerne allein entwickel. Also hab ich mir immer Projekte gesucht bei denen ich helfen kann. Mitlerweile programmier ich seit über 2 Jahren für ein kleines Projekt oder nehm ab und zu kleine Aufträge nebenbei an. Außerhalb von Unity schreib ich seit ein paar Monaten an meiner eigenen Engine aus Spaß. Diesmal in C++, auch wenn ich immer noch ein größerer Fan von C# bin.
  10. Mesh manuell speichern geht auch nicht. Schau dir mal deinen Inspector in der runtime an. Das Mesh-Feld hat einen Wert (dein Mesh) aber wenn du draufklickst wird das Mesh Asset nicht im Projekt selektiert, weils das nicht gibt. Also musst du das Mesh nocheinmal seperat speichern. Das machst du mit AssetDatabase.CreateAsset.
  11. Du musst auch das Mesh als Asset speichern, da es ansonsten bloß in der Szene lebt und somit, logischerweise, auch nicht über die Szene hinaus verwendbar ist.
  12. https://msdn.microsoft.com/de-de/library/14akc2c7.aspx ? Static sagt in dem Kontext, dass die Methode direkt über den Klassennamen aufgerufen werden kann. Ref bewirkt, dass der Parameter per Referenz, statt als Wert übergeben wird -> public class AwesomeClass { public static void FooValue (Vector3 vec) { vec = new Vector3(0, 1, 0); } public static void FooRef (ref Vector3 vec) { vec = new Vector3(0, 1, 0); } } int Main () { var vec = new Vector3(0, 0, 0); AwesomeClass.FooValue (vec); // vec ist (0, 0, 0) AwesomeClass.FooRef (ref vec); // ref muss auch beim Methoden Aufruf geschrieben werden // vec ist (0, 1, 0) }
  13. 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.
  14. Damit meint er, dass Unity's Coroutinen im Main Thread, also bloß auf einem Kern laufen. Die GPU wirst du aber im Normalfall für Pathfinding nicht brauchen. Bei Algorithmen wie Continuum Crowds ist es aber so (höchstwahrscheinlich auch in der Lösung aus dem Video) dass die einzelnen "KIs" nicht mehr einzelne Akteure sind, sondern als Menge betrachtet werden. D.h. das beispielsweise alle Mitglieder deiner Menge sich mit der selben Geschwindigkeit fortbewegen und kein individuelles Verhalten aufweisen. (danach siehts im Video auch aus)
  15. 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.