Showroom - Aktuelle Arbeiten und Projekte

Hier könnt ihr euch selbst, eure Homepage, euren Entwicklerstammtisch, Termine oder eure Projekte vorstellen.
Forumsregeln
Bitte Präfixe benutzen. Das Präfix "[Projekt]" bewirkt die Aufnahme von Bildern aus den Beiträgen des Themenerstellers in den Showroom. Alle Bilder aus dem Thema Showroom erscheinen ebenfalls im Showroom auf der Frontpage. Es werden nur Bilder berücksichtigt, die entweder mit dem attachement- oder dem img-BBCode im Beitrag angezeigt werden.

Die Bildersammelfunktion muss manuell ausgeführt werden, die URL dazu und weitere Details zum Showroom sind hier zu finden.

This forum is primarily intended for German-language video game developers. Please don't post promotional information targeted at end users.
Benutzeravatar
woodsmoke
Beiträge: 45
Registriert: 30.06.2023, 14:05
Wohnort: Ludwigshafen
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von woodsmoke »

Bild

Arbeite an einen 2. Teil von einer mech simulation. Das erste war Mechwarrior 2 Feeling, das jetzt eher Mech2 Mecenaries.
Dazu nutze ich die alte erste Version aus meinen programmier n00b Zeit. Ist lustig, viel brute force taktik.
Ziel ist eine aufwändigere Gegner AI, ein paar mehr Waffen, Mechs, aufgebohte Optik ...
Vielleicht auch zufallsgenerierte Welten, und da Söldner Permadeath + Punkte-Highscore-System.
Zuletzt geändert von woodsmoke am 11.04.2024, 00:58, insgesamt 1-mal geändert.
joeydee
Establishment
Beiträge: 1044
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »

Habe gestern mal einen Tesselation-Algo ausprobiert, dessen Name ich leider nicht kenne.
Ich schätze zwar, dass der generell deutlich mehr Line-Intersection-Tests benötigt als z.B. Pig Ear, also dürfte nicht besonders optimal sein. Und schmale lange Dreiecke sind ja auch nicht besonders hübsch, alles mehr so Brute-Force, also dürfte nicht wirklich von Interesse sein. Aber: er funktioniert ;)

Dafür ist die Formulierung ziemlich simpel: Nimm einen beliebigen Punkt im Loop als Startpunkt an, gehe im Umlaufsinn durch welche Punkte von dort aus "sichtbar" sind, und füge diese zum aktuellen Fan hinzu. Für Punkte die nicht sichtbar sind, mache einen neuen Loop auf welcher separat gelöst wird.

Ist entfernt mit Schweinsöhrchen verwandt, aber schneidet keine einzelnen Dreiecke ab, sondern ganze Polyloops (welche am Ende dann alle jeweils durch einen einzelnen Fan repräsentiert werden können, dabei aber nicht konvex sein müssen), und arbeitet von innen nach außen statt von außen nach innen.

Die Idee ist an einen Bot angelehnt, welcher seine Umgebung von einem Punkt aus scannt, offene Portale im Scanpanorama markiert, später dann zu diesen hinrollt und von dort aus die noch unbekannten Bereiche dahinter scannt, bis keine Portale mehr übrig sind.

Im Bild startet der Algo bei 0; 1 ist sichtbar, 2 und 3 nicht, 4 ist wieder sichtbar, also wird ein separater Loop 1,2,3,4 in die ToDo-Liste gelegt. Ebenso 4,5,6, sowie 7-19 usw. Zum aktuellen Fan gehören dagegen die von 0 aus "sichtbaren" Punkte 0,1,4,6,7,19,...
Die blauen Kreise markieren jeweils den letzten sichtbaren Punkt und damit Startpunkt für abgetrennte Polyloops, die blaue Linie die Schnittkante zum nächsten wieder sichtbaren Punkt; abgetrennte Dreiecke (wie z.B. 4,5,6) sind trivial und haben hier im Debug-Render keinen neuen Startpunkt, sondern werden ungeprüft in die Renderliste gelegt.
Bild
joeydee
Establishment
Beiträge: 1044
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »

Relativ uninteressant, ich zeigs trotzdem. Weitere kleine Beschäftigungen mit Triangulierung. Diesmal der Original-Schweinsöhrchen-Algo, und dabei lief mir auch die konvexe Hülle über den Weg. Alter Kumpel, lange nicht gesehen ;)

Nimm das nächstbeste Ohr:
pigear01.jpg
Nimm das Ohr mit dem kleinsten Innenwinkel am verbliebenen Polygon:
pigear02.jpg
Nimm das Ohr mit der kürzesten Cut-Strecke:
pigear03.jpg
Definiere "Ohr" als "Konkave Stelle, Verbindungsline der Schenkel ausschließlich außerhalb des Polygons"
(Oder einfacher: Kehre den Umlaufsinn des Polygons um)
Das verbleibende Polygon (hier weiß) ohne weitere solche Konkav-Stelle ist die konvexe Hülle. Behaupte ich mal, Beweisführung geht anders.
pigear04.jpg
Benutzeravatar
Schrompf
Moderator
Beiträge: 4859
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von Schrompf »

Wie unterscheidest Du zwischen z.B. den kürzesten Cut-Strecken? Erstellst Du da jedes mögliche Ohr und wählst dann das aus, was den kürzesten Cut hat? Oder gibt's irgendnen Trick, wie Du z.B. den Punkt erkennst, von dem aus der TriFan den kleinsten Innenwinkel hat?
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
joeydee
Establishment
Beiträge: 1044
Registriert: 23.04.2003, 15:29
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von joeydee »

Im Moment noch Brute Force, also ja, komplette Prüfung in jedem Durchgang.
Man kann aber vorher eine sortierte Liste mit allen konvexen Ecken erstellen, nach dem Grad der Konvexität (Innenwinkel) oder dem Abstand der Schenkel-Endpunkte. Für den nächsten Clip nimmt man dann das erste Element dieser Liste, welches den eigentlichen Ohr-Test besteht. Diese Liste kann man dann nach jedem Clip ja relativ aufwandsarm updaten (Konvexität der beiden Nachbarpunkte kann sich geändert haben) und sortiert halten.
Benutzeravatar
**Achilles**
Beiträge: 7
Registriert: 01.04.2024, 19:25
Benutzertext: Blender Modellierer
Echter Name: Sven

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von **Achilles** »



Ich bin gerade dabei , etwas zu erstellen wo sich wahrscheinlich nie jemand getraut hat es zu versuchen. Ich werde natürlich sehr viele Orte in die Spielidee einbauen. Natürlich wird bald mein erster Trailer fertig werden. Aber zuerst möchte ich Nürnberg nachkonstruieren und dass kostet viel Zeit. Wer sich mit Unity Gut auskennt kann mir gerne helfen. Das Video hier ist nur eine Show , was UPBGE kann. Für mein vorhaben wird es von Level zu Level ausreichend sein und komplett mit Python Programmiert. Ich werde euch hier auf dem Laufenden halten.
Dateianhänge
S ie g.mp4
(10.63 MiB) 6-mal heruntergeladen
Hier ein 10 Jahre Rückblick, und heute? Rockt Blender 4.0 :D
https://youtu.be/LEvoq38JJiY
smurfer
Establishment
Beiträge: 201
Registriert: 25.02.2002, 14:55

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von smurfer »

Hallo zusammen,

es gibt ein paar Spiele, Techniken und Mechaniken, zu denen ich immer wieder zurückkomme. Und im Zuge meines Lernprozesses mit Zig habe ich vieles neu aufgesetzt. Ich habe hier im Forum und auch beim Stammtisch schon das Projekt "Rayworld-NG" vorgestellt. Nachdem ich dort eine Mini-Simulation eines Asteroidengürtels per RTT auf die spiegelnden Wände gemappt habe und irgendwann das Raycasting-Interieur auch eine Geschichte bekommen muss -- wie eine Raumstation oder ein großes Schiff -- bin ich wieder bei einem meiner Lieblingsthemen gelandet: Asteroids in etwas moderner. Wenn das 2D-Minigame soweit (momentan als eigentständiges Programm) läuft, soll es auf den "Bildschirmen" in Rayworld genutzt werden können.
Meine grundsätzlichen Zig-Codeteile, die ich z.B. für die Grafik nutze, sowie die generelle Architektur, sind (hoffentlich) so modular, dass es dann gut eingebettet werden können sollte.
Außerdem war ich sehr positiv überrascht von der Performance in Zig, die einem durch den Code-Stil irgendwie aufgezwungen wird. Man macht sich eben gezwungenermaßen viele Gedanken über die Speicherauslegung, die Cache-bezogen ordentlich Performance liefern. Daher wollte ich mal wieder meine alte Particle-Emitter-Engine neu aufleben lassen und das passt ganz gut zu dem kleinen Asteroids-Raumschiff mit Newton'scher Physik.

Hier der erste Prototyp:
Screenshot_20240506_205553.png
Dazu zwei Anmerkungen:
1. Die Sterne im Hintergrund gehören teilweise zur Galaxy-Textur, teilweise sind sie gerendert und bewegen sich parallax. Ich habe versucht, den Übergang von Bild zu gerendert möglichst nahtlos zu gestalten. Das sieht man allerdings erst in Bewegung.
2. In dem Zusammenhang und mit den Partikeln (im Bild ein paar 10 000), habe ich das erste Mal tatsächlich Pointsprites im Shader genutzt. Hatte ich nie Berührungspunkte mit, aber für den Zweck scheint es ein gutes Mittel, hat viel gebracht.

Ist natürlich alles noch im sehr frühen Teststadium.

Beste Grüße
smurfer
Establishment
Beiträge: 201
Registriert: 25.02.2002, 14:55

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von smurfer »

Noch ein paar zusätzlich Hintergrundinfos:

Üblicherweise verwende ich für einfache Kinetik einen semi-implicit Euler zur Integration (wie erwähnt einfache Integration, RK4 u.Ä. außen vor). Für diejenigen, denen das nichts sagt:
Die Beschleunigung der Objekte wird integriert, es ergibt sich die Geschwindigkeit, diese wiederum integriert zur Position, also

Code: Alles auswählen

acc -> vel -> pos
in jedem (physikalischen) Frame.
Explizite Integratoren, also solche, die aus dem (wenn wir mal in der Physik bleiben) Zeitschritt t den Zeitschrit t+1 berechnen, fügen dem System durch numerische Ungenauigkeiten Energie zu. D.h. bei sehr dynamischen Systemen, wie Feder-Dämpfer-Masse-Systeme (oder noch schlimmer solche mit starren Verbindungen), ist es recht ungeeignet, da diese mitunter "explodieren". Implizite Integration, die zur Berechnung der neuen Werte zu t+1 auch Werte aus der Zukunft (z.B. auch Zeitpunkt t+1) nutzen, entziehen eher Energie, sie dämpfen. Allerdings sind oftmals die Zukunftswerte nicht bekannt.
Bei der o. g. Zweifach-Integration wird wie erwähnt häufig ein ein semi-impliziter Integrator verwendet, für das Beispiel heißt das:

Code: Alles auswählen

acc(t) -> vel(t+1) -> pos(t+1) 
.
Hier wird der neu berechnete Wert für die Geschwindigkeit direkt für die Integration zur Position genutzt. Diese Art von Integratoren ist recht neutral, was die Energie angeht und bietet sich im Bereich der Kinetik für einfache Dinge an.

Da nun Zig explizit SIMD-Instruktionen mit Schüsselwörtern unterstützt, kann sowohl die x-, wie auch die y-Koordinate in einem Vektor gleichzeitig integriert werden und man erhält direkt doppelte Geschwindigkeit, was sich in meinen Messungen auch so bestätigt.

Nun kam mir folgende Überlegung: Für einen Partikel-Emitter muss der Integrator nicht sonderlich genau sein, er darf ruhig rein explizit sein. Warum also nicht einen Vektor bestehend aus

Code: Alles auswählen

(acc_x, acc_y, vel_x, vel_y)
und diesen direkt auf

Code: Alles auswählen

(vel_x, vel_y, pos_x, pos_y)
integrieren. Einzig die Geschwindigkeit zu t+1 im zweiten Vektor muss im nächsten Frame wieder in den ersten Vektor kopiert werden. Auch dafür gibt es SIMD-Instruktionen. Mit etwas Overhead ist für diesen Schritt dann am Ende die Berechnung der Dynamik etwa Faktor 3.0 - 3.5 schneller.

Natürlich habe ich nur meine eigenen Berechnungen als Stichprobe und ich hoffe, hier nicht zu viel geschwafelt zu haben, was vielleicht eh 90% schon wissen und kennen. Aber mir hat es viel Freude bereitet, dahingehend zu optimieren.

Disclaimer: Für die weitere Entwicklung bin ich erstmal wieder zu 2-Komponenten-Vektoren zurück, da der Code mit Umsortieren, lokalen Koordintensystemen, Parent-(Winkel-)Geschwindigkeiten, etc. im gezeigten 4-Komponenten-Vektor etwas unübersichtlich wurde und erstmal die Emitter "fertig" werden sollen, bevor ich final optimiere -- dann kann es wieder aus dem Branch geholt werden.
Benutzeravatar
woodsmoke
Beiträge: 45
Registriert: 30.06.2023, 14:05
Wohnort: Ludwigshafen
Kontaktdaten:

Re: Showroom - Aktuelle Arbeiten und Projekte

Beitrag von woodsmoke »

Ich arbeite gerade an der GAME OVER Graphik anstatt der Gegner KI, wobei ich für die KI schon auf Papier einen Plan erstellt habe:

Bild
Antworten