Showroom - Aktuelle Arbeiten und Projekte

[Krishty]

Ich habe mir mal ein gigantisches Epsilon gegeben und damit einige Grenzfälle gefunden und gefixt, wo das entstehende Geometrie-Setup Ärger gemacht hatte. Das Epsilon versucht, Schnittpunkte sehr nah an Kanten oder Eckpunkten zu erkennen und absichtlich drauf zu bewegen. Dadurch kollabieren winzig schmale Dreiecke zu Linien und ich erzeuge sie gar nicht erst. Das hat in der Theorie den Vorteil, dass auch nach dem zehntausendsten Schnitt der Gesamtmesh noch aus sinnvollen Dreiecken besteht. In der Praxis habe ich es bisher nur an diesem 4-Dreiecke-Quadrat erprobt, das von einer 4-Dreiecke-Pyramide (Spitze nach unten) durchstoßen wird. Aber jetzt lass ich es mal auf meinen Schrank los.

Epsilons sind ja fast nutzlos, weil die Koordinaten großer Dreiecke fern des Nullpunkts weniger Genauigkeit haben als die kleiner Dreiecke nahe dem Nullpunkt. Hatte ich hier schonmal den Offset-Trick für konstante Gleitkommagenauigkeit ge-anti-jammert?

[Schrompf]

Ich glaube ja, aber tu's gern nochmal. Es funktioniert damit für meine Bedürfnisse, und es ist auf jeden Fall besser als die Grenzfälle zu ignorieren und einfach auf Teufel komm raus jedes Winzdreieck durchzuschleifen.

[Krishty]

Gleitkommazahlen haben konstante Genauigkeit innerhalb eines Exponenten. Zwischen 1 und 2 können sie also genau so viele Koordinaten speichern wie zwischen 2 und 4, 4 und 8, usw. (im Fall von float nämlich 2²³, also rund 8.3 Millionen) – es ist bloß der Exponent, der sich zwischen diesen Bereichen ändert.

Deshalb geht CSG & Co. gern kaputt, wenn du Geometrie verschiebst – zwischen 0,0625 und 0,125 liegen auch 2²³ Koordinaten, und du stellst vielleicht dein Epsilon drauf ein, aber wenn du die Geometrie hundert Einheiten vom Ursprung verschiebst ist die Genauigkeit ein paar Millionen Mal grober und dein Epsilon viel zu klein. Oder umgekehrt, falls du vom Ursprung entfernt testest und dann Geometrie zum Ursprung hin verschiebst.

Du brauchst die maximale mögliche Seitenlänge deiner Geometrie. Die rundest du zur nächsten Zweierpotenz auf und addierst das zu all deinen Koordinaten. Falls deine Geometrie negative Vorzeichen haben kann, nimmst du ×1,5.

Also wenn deine Levels höchstens von -1000 bis +1000 gehen können, macht das 2000 Seitenlänge. Aufgerundet zu 2048 × 1,5 = 3072. Du addierst zu allen deinen Koordinaten vor jeder Operation 3072, führst die Berechnung durch, und ziehst danach wieder 3072 ab. Die Koordinaten deiner Geometrie liegen dann komplett zwischen 2048 und 4096. Damit haben alle deine Gleitkommazahlen den selben Exponent. Du hast eine durchgängige Genauigkeit von (4096-2048)/2²³ = 0,000244140625 Einheiten. Egal, welche Stelle deiner Geometrie du verarbeitest – die Genauigkeit ist immer gleich und dadurch wirkt sich auch das Epsilon gleich aus.

Wenn du’s im Debugger lesbar haben willst und nicht den vollen Koordinatenraum brauchst, kannst du auch einfach 10.000/100.000/1.000.000 etc. addieren. Dann sind die Koordinaten im Debugger perfekt lesbar, nur mit einer Eins und ein paar Nullen davor. Musst halt wissen, auf wie viel Genauigkeit du verzichten kannst.

[Schrompf]

Hm. Naja. Ja, aber. Dann nimm doch gleich Fixpoint? Ok, da kann der Compiler wahrscheinlich nicht so schön vektorisieren, weil du permanent bei Multiplikationen den Überlauf zu 64bit mitnehmen musst.

Ich hab wie gesagt die Grenzfälle aktiv herbeigeführt mit nem Epsilon sehr viel größer als ULP in dem Zahlenbereich, der hier auftreten kann. Ich will gar nicht "genau drauf im Rahmen der Genauigkeit" erkennen, sondern "das ist ein bissl nah für meinen Geschmack, mach mal genau drauf". Das kann ganz weit draußen immer noch zu Präzisionsproblemen führen, sicher, aber es ist doch ein ganz anderer Ansatz als das Auswursteln eines verlässlichen Epsilons.

[Krishty]

Hm. Naja. Ja, aber. Dann nimm doch gleich Fixpoint? Ok, da kann der Compiler wahrscheinlich nicht so schön vektorisieren, weil du permanent bei Multiplikationen den Überlauf zu 64bit mitnehmen musst.

Festkomma hat eine Reihe Nachteile, z. B. musst du round-to-nearest selber implementieren (insbesondere bei Divisionen), Multiplikationen auf Überlauf prüfen, usw. usf. Ein Punktprodukt kann ja in Festkomma schon haarsträubend sein. Hat halt Gründe, warum das seit 1997 niemand mehr tun möchte. Mit dem Offset bekommst du das Beste beider Welten – kannst rechnen wie immer, aber kein muh floats are doing float stuff mehr.

[Schrompf]

Das ist ein Argument. Auch die vielen fertigen Operationen sind sehr bequem.

[Zudomon]

Verliert man nicht durch dieses hin- und zurück schieben bei den Float Zahlen auch an Genauigkeit?
Und was wäre, wenn man stattdessen das Epsilon variable macht, je nachdem, wie weit das Vertex vom Ursprung entfernt ist?

[Krishty]

Verliert man nicht durch dieses hin- und zurück schieben bei den Float Zahlen auch an Genauigkeit?

Genau, du reduzierst alle Koordinaten einmalig auf die selbe Präzision.

Und was wäre, wenn man stattdessen das Epsilon variable macht, je nachdem, wie weit das Vertex vom Ursprung entfernt ist?

Das wäre ULP (Unit in the Last Place). Wäre der Königsweg, wird aber schnell sehr aufwendig, weil das ULP bei vielen Operationen nicht offensichtlich ist. sqrt(x²+y²+z²) sind wie viele Operationen mit wie vielen Rundungen auf die nächste ULP? Schrumpft der Fehler durch sqrt() ebenfalls auf die Quadratwurzel des Eingangsfehlers oder nicht? Nutzt du Multiply-Add?

Ich mach’s so aber das empfehle ich anderen genau so wenig wie ein eigenes Build-System.

[Schrompf]

Mein Schrank CSGt jetzt live mit 40fps. Hab die Schnittebene bissl über die Zeit animiert, ich könnt dem stundenlang zuschauen :-) Gelegentlich flackert noch irgendein Problemfall für ein Frame auf, und aufm Screenshot ist offensichtlich, dass das Ergebnis nicht mehr watertight ist. Und ich hab noch nen Bug in der Vertex-Interpolation, was aber bei meinem Einheitsfarben-Look nicht weiter auffällt.

Ich glaub, ich mach jetzt erstmal wieder bissl Gameplay.

[joeydee]

Habe mal diese praktische Mapgenerationsmethode ausprobiert. Die Idee mit den 8 Ausgängen je Tile habe ich von Inkwell Ideas (DungeonMorphs).
Hier mit nur einer einzigen handgezeichneten Dorf-Kachel, allein das gibt schon ziemlich Vielfalt im Straßenlayout. Funktioniert natürlich auch für regelmäßigere Layouts, wo z.B. eine große Kachel aus n*n Tiles mit einem üblichen Dungeon-Tileset vorgestaltet ist.
Leider gerade nicht viel Zeit für weitere Experimente, aber ein Set aus 5-6 Großkacheln und ein kleiner Tile-Editor dazu könnte schon interessant werden.

[Schrompf]

Schick. Ich hab erst ein bissl gebraucht, um das zu verstehen: die Map besteht aus diesem einen Tile, aber gedreht und/oder gespiegelt? Funktioniert schon echt gut! Nach ner Weile sieht man dann die Tilegrenzen, weil die Häuser und Bäume den Saum nicht berühren. Aber die dann auch noch Seamless über Kante zu kriegen, könnte eine unlösbare Aufgabe sein.

[Chromanoid]

Cool! Erinnert mich an Carcassonne Junior :) Da passen auch alle Teile in jeder Richtung zusammen (allerdings nur 4 Punkte). Vielleicht kann man das ja fraktalweise lösen und dann auf jeder Detailstufe höher Dinge löschen und verschieben.

[joeydee]

könnte eine unlösbare Aufgabe sein

Unmöglich immer alles für dich ist ;)

Nein im Ernst, das ist ja vor allem günstig für weitläufig zusammenhängende Strukturen wie eben Map-Wege, wenn man da ohne viel Gestaltungsaufwand einigermaßen abwechslungsreiche Maps (vor-)gestalten möchte. Ich war da überrascht wie schnell das so abwechslungsreich wird und der Tile-Charakter verlorengeht mit 8 statt 4 Ausgängen je Kachel, und wie frei die Gestaltungsmöglichkeit inerhalb einer Kachel dadurch wird, auch in Bezug auf Vorzugsrichtungen.
Ich würde da aber für Einzelassets (vor allem für Vegetation etc.) wohl eher nur "Empfehlungsflächen" über diese Methode anlegen, und dann Assets nachträglich platzieren ohne Rücksicht auf Kachelgrenzen.

[Schrompf]

Hab mal wieder was Neues angefangen. Ja, am Schleichspiel mach ich irgendwann weiter, versprochen. An dem hier ist der ZFX-Stammtisch Schuld, insbesondere xima, glaube ich. Irgendwer hatte ein Unterwasser-Zellulärer-Automat-Spiel vorgestellt, wo man ne Mauer unter Wasser gezogen hat und dann Druckluft reingepumpt, bis die Luft das Wasser unten rausgedrückt hat. Speziell das graublaube diffuse Unterwasser-Licht - ebenso zellulär - hatte mich sehr beeindruckt, also mach ich jetzt mein Eigenes.

Es soll so ne Art 2D-Subnautica werden - rumtauchen, Basisbau, Nahrung finden und vielleicht selbst züchten, Tier- und Pflanzenwelt, Buddeln und Licht&Dunkelheit, Unterwasser-Strömungen. Bislang geht nur ne grundlegende Kartengenerierung mit bissl Fels und ner Eisschicht obendrauf, die dann zellulär bis zu ner gewissen Dicke wächst. Als nächstes kommt erstmal ein Charakter und ein bissl Rumtauchen, bevor ich mich dann an der Luftdruck-Wasser-Interaktion versuche.

Das Wasser ist unten, das Weiße oben ist die Luft, dazwischen Eis und ein Felsklotz mit 4 Layern Parallax-Deko-Hintergrund.

[smurfer]

Oh ja, der (und für mich der erste) Stammtisch war inspirierend. Das sieht gut uns und klingt von der Beschreibung ebenso, Schrompf. Das Schöne an solchen zellbasierten Techniken ist auch meiner Ansicht nach, dass es gleich, wie in deinem Bild, automatisch in so eine Nostalgie-Pixel-Richtung geht.

[Schrompf]

Ich komme näher. Aktuell habe ich entweder eine farbgetreue Version meines Blurred Parallax, die durch's Blurren mit Schwarz einen Rand kriegt. Oder ich habe eine Premultiplied Alpha-Blur, bei dem es zwar keinen schwarzen Rand gibt, aber die Farben sich dafür aufsummieren und ich ein fröhlich buntes Unterwasser-Abenteuer im SuperMario-Stil bekomme.

Krieg ich noch raus. Mit weichgezeichneten Hintergrundlayern erkennt man jedenfalls endlich, welcher Teil spielmechanisch relevant ist, und welcher nur Deko.

[edit] Ok, nach bissl Verständniskonflikt mit Premultiplied Alpha hier die sauber gemischte Version. Die Background Layer sind schön matschig, der Vordergrund steht heraus. Und in Bewegung parallaxt es ganz angenehm. Hab irgendwo noch ein vermaledeites halbes Pixel Offset in meinen Rendertargets, daher sind haben alle Konturen einen halbdunklen Rand, aber das finde ich noch.

[Andy90]

Endlich habe ich es geschafft, 3D-Animationen in mein Game Framework zu integrieren. Jetzt habe ich damit begonnen, einen Charaktercontroller zu erstellen, um endlich ein kleines 3D-Spiel damit zu entwickeln. Das Rendering von Modellen war im Framework schon eine Weile möglich, aber ohne Animationen ergibt das nicht viel Sinn in einem Game Framework. Ich meine, es wird wahrscheinlich nie mit einer Engine wie Unity, Unreal oder Godot mithalten können :) Aber ich lerne fast täglich etwas Neues dazu. Selbst wenn es frustrierend ist, wenn etwas nicht sofort funktioniert, ist es umso schöner, wenn man es schließlich schafft. Vieles wäre wohl nicht möglich gewesen ohne die Hilfe anderer, die in vielen meiner Posts wertvolle Inputs geben und mir weiterhelfen.

Sei es der Maus Raycast, um 3D-Modelle zu finden, das Synchronisieren der Bullet-Matrix und der Render-Matrix oder die Animationen. Es ist großartig, dass es immer noch Foren gibt, wo man positive Unterstützung erhält. Davon könnte sich StackOverflow eine Scheibe abschneiden. Vielen Dank nochmal :)

Aber nun zum Charaktercontroller: https://streamable.com/t5glcu

und das wäre der Aktuelle game code

Code: Alles auswählen

using BulletSharp;
using Genesis.Core;
using Genesis.Core.Behaviors;
using Genesis.Core.Behaviors.Physics3D;
using Genesis.Core.GameElements;
using Genesis.Graphics;
using Genesis.Graphics.RenderDevice;
using Genesis.Graphics.Shaders.OpenGL;
using Genesis.Math;
using Genesis.Physics;
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.ComponentModel.Design;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Runtime.CompilerServices;
using System.Text;
using System.Threading.Tasks;
using System.Windows.Forms;

namespace Genesis3D_Game
{
    public partial class Form1 : Form
    {
        private Game game;

        public Form1()
        {
            InitializeComponent();

            // Create the game baseclass with the GLRenderer
            this.game = new Game(new GLRenderer(this.Handle), new Viewport(this.ClientSize.Width, this.ClientSize.Height));
            this.game.TargetFPS = 60;

            // Create the sun
            Light sun = new Light("Sun", new Vec3(10.0f, 10f, 10.0f));
            sun.Intensity = 0.2f;

            // Create a new 3D scene with an base layer
            var scene = new Scene3D("Scene", sun);
            scene.Camera = new PerspectiveCamera(new Vec3(0.0f, 0.0f, 0.0f), new Vec3(this.ClientSize.Width, this.ClientSize.Height), 0.1f, 100f);
            scene.Camera.Rotation.Y = 90.0f;
            scene.AddLayer("BaseLayer");


            // Create an Physics Handler
            PhysicsHandler3D physicsHandler = new PhysicsHandler3D(0f, -9.81f, 0f);
            scene.PhysicHandler = physicsHandler;

            // Load the Skydome
            String modelspath = new System.IO.FileInfo(System.Reflection.Assembly.GetEntryAssembly().Location).Directory + "\\Resources";
            scene.Skybox = new Skybox("skydome", modelspath + "\\Assets\\Skydome1\\skydome.obj", new Vec3(0), new Vec3(0), new Vec3(75));

            // Create an big qube for the underground with an BoxCollider
            Qube qube1 = new Qube("Qube_1", new Vec3(0f, 0f, 0f));
            qube1.Size = new Vec3(50f, 0.5f, 50f);
            qube1.Shader = new DiffuseSolidShader();
            qube1.Color = Color.White;
            scene.AddGameElement("BaseLayer", qube1);

            var boxCollider = qube1.AddBehavior(new BoxCollider());
            boxCollider.CreateCollider(physicsHandler, qube1.Size.Half(), 0f);

            // Create the player model with an Capsule Collider and check for collisions.
            Model model = new Model("Character", new Vec3(2f, 2f, 0f), modelspath + "\\Assets\\Animation\\Human.fbx");
            model.PlayAnimation("Armature|idle");
            scene.AddGameElement("BaseLayer", model);

            var collider = model.AddBehavior(new CapsuleCollider());
            collider.CreateRigidBody(physicsHandler, new Vec3(0f, 0.75f, 0f), 0.5f, 0.5f, 15f);
            collider.RigidBody.AngularFactor = new BulletSharp.Math.Vector3(0, 0, 0);
            collider.OnCollide += (sce, game, collisionObject) =>
            {
                RigidBody refbdy = (RigidBody)collisionObject;
                GameElement element = (GameElement)refbdy.UserObject;
                Console.WriteLine("Collision with " + element.Name + " UUID " + element.UUID);
            };

            // Create an 2 Qube with an collider
            Qube qube2 = new Qube("Q2", new Vec3(2f, -0.1f, 0f));
            qube2.Shader = new DiffuseSolidShader();
            qube2.Color = Color.White;
            var qubeCollider = qube2.AddBehavior(new BoxCollider());
            qubeCollider.CreateCollider(physicsHandler, qube2.Size.Half(), 0);
            scene.AddGameElement("BaseLayer", qube2);

            // Add the scene to the game
            game.AddScene(scene);
            game.SelectedScene = scene;

            // OnInit Event create the debug drawer
            game.OnInit += (game, renderer) =>
            {
                physicsHandler.PhysicsWorld.DebugDrawer = new Genesis.Graphics.Physics.BulletDebugRenderer((GLRenderer)this.game.RenderDevice);
            };

            // After the rendering debug draw the physics
            game.OnRenderEnd += (game, renderer) =>
            {
                //physicsHandler.PhysicsWorld.DebugDrawWorld();
            };


            // Game Update logic
            game.OnUpdate += (game, renderer) =>
            {
                // Let the camera follow the player
                PerspectiveCamera camera = (PerspectiveCamera)scene.Camera;
                camera.Location = Utils.GetRelativePosition(model, new Vec3(0f, 2.5f, -4f));
                camera.Rotation.X = -20f;
                //Utils.LookAt(camera, model.Location);

                // Setup the Velocity for the player movement
                float vx = 0f;
                float vY = collider.RigidBody.LinearVelocity.Y;
                float vz = 0f;

                float rx = 0f;
                float ry = 0f;
                float rz = 0f;

                float speed = (float) game.DeltaTime * 0.3f;

                // Move the player
                if(Input.IsKeyDown(Keys.W) || Input.IsKeyDown(Keys.S))
                {
                    if (Input.IsKeyDown(Keys.W))
                    {
                        vz += speed;
                    }
                    else if (Input.IsKeyDown(Keys.S))
                    {
                        vz -= speed;
                    }
                    if (model.Animator.CurrentAnimation.Name != "walk")
                    {
                        model.PlayAnimation("walk");
                    }
                }
                else
                {
                    if (model.Animator.CurrentAnimation.Name != "Armature|idle")
                    {
                        model.PlayAnimation("Armature|idle");
                    }
                }

                // Activate the RigidBody for the player again and set the velocity
                collider.RigidBody.Activate();
                collider.RigidBody.LinearVelocity = new BulletSharp.Math.Vector3(vx, vY, vz);
                //collider.RigidBody.AngularVelocity = new BulletSharp.Math.Vector3(rx, ry, rz);

            };

            game.Start();
        }

        private void Form1_Load(object sender, EventArgs e)
        {

        }

        // Update the viewport
        private void Form1_Resize(object sender, EventArgs e)
        {
            game.Viewport.SetNewViewport(ClientSize.Width, ClientSize.Height);
            game.SelectedScene.Camera.Size = new Vec3(ClientSize.Width, ClientSize.Height);
        }

        // End the game when the for get closed
        private void Form1_FormClosing(object sender, FormClosingEventArgs e)
        {
            game.Stop();
        }
    }
}

Den Controller werde ich später in einen GameBehavior umwandeln (so heißen die entity components in meiner Engine)

[Schrompf]

Ja geil! Jonathan wiederholt es immer wieder, und auch ich hau nochmal in diese Kerbe: ein animiertes 3D-Modell ist eine absurd komplexe Kette von Operationen, die alle hinhauen müssen, damit man am Ende aufm Screen die korrekte Anim sieht. Und Du hast das alles gemeistert. Glückwunsch!

Wenn Du Bock auf ein neues Abenteuer hast: schau Dir mal Rotation-Interpolation mittels Quaternions an. Dann könnte Dein Charakter beim Übergang Stehen zu Laufen 200ms Übergang kriegen und alles würde weniger ruckartig aussehen.

[xq]

Ja geil! Jonathan wiederholt es immer wieder, und auch ich hau nochmal in diese Kerbe: ein animiertes 3D-Modell ist eine absurd komplexe Kette von Operationen, die alle hinhauen müssen, damit man am Ende aufm Screen die korrekte Anim sieht. Und Du hast das alles gemeistert. Glückwunsch!

Dem kann ich nur so zustimmen. Geile Arbeit!

Auch an Schrompf, das mit dem geblurrten Hintergrund sieht mega fancy aus, ich bin gespannt, wie sich das in Bewegung so macht

[Andy90]

Danke sehr :) so hier ist nun der Fertige Character Controller: https://streamable.com/yqxwmv. Hatte noch einen Fehler in der Physik Simulation gefunden, welcher dafür sorgte das bei hohen FPS zahlen, die Bewegung rucklig war. Endlich wird ein Schuh aus den ganzen 3D sachen.

Hier ist noch der Source Code: https://github.com/Andy16823/GFX/blob/d ... troller.cs

[joeydee]

Ich mag ja Content- und Geometrieerzeugung direkt im Code für manche Zwecke. Und überlege daher auch immer, wie ich mit übersichtlichen Codezeilen auch komplexeren Content zusammensetzen könnte.

Was ich zu diesem Thema gerade mache, und warum, dafür muss ich leider etwas ausholen:
Da ich in letzter Zeit viel mit OpenSCAD und 3D-Druck für Modellbau zu tun hatte, reift in mir schon geraume Zeit der Gedanke, ein kleines modulares CSG-Scripting auch für C# zu basteln, auf Grundlage meiner früheren CSG-Tests (irgendwo oben hier im Thread, CSG-Ursprungscode war nicht von mir, nur transferiert).

Für Modellbau konstruiere ich z.B. kein fertig detailliertes Haus in Blender, um es dann am Stück auszudrucken (ein final detailliertes 3D-Modell würde bei mir nie fertig werden). Vielmehr lege ich nach dem Maßstab sowas wie Stockwerkshöhen, Tür- und Fenstergrößen fest, und scripte dann erst einmal passende generische Wände mit beliebig zu verteilenden Öffnungen. Die Fenster selbst sind dann wieder separat gescriptet (verschiedene Muster bei flexiblen Maßen), und es wird erst am Ende (in RL) alles zusammengefügt. Wie ein Bausatz eben.

So kann ich z.B. nachträglich neue Fenster oder Dachrinnen und Ablaufrohre entwickeln, als eigenes Modul, ohne dass sie an ein spezifisches Modell/Projekt passen müssen; durch die Parametrisierung kann ich dann das Objekt für ein konkretes Modell angepasst erstellen und platzieren. Anpassen bedeutet dann z.B. auch, Treppenstufen richtig zu verteilen für beliebige Delta-X/Y-Steigungen, und Geländer in passendem Winkel dazu generieren. CAD-Bauteile eben. (Parametrisierte Modellbautreppen in 1:160 habe ich z.B. auf Thingiverse hochgeladen: https://www.thingiverse.com/thing:5427671/files)

Vorteile also: Unabhängige Entwicklung/Ergänzung von immer mehr Details; Wiederverwendbarkeit; Code-Übersicht durch Parametrisieren und Wegpacken.

Anwendung im Modellbau sieht z.B. so aus; alle Teile basieren hier auf solch generischen Objekten, und es lassen sich mit anderen Maßen und Kombinationen ziemlich no-brainig wieder völlig andere Gebäude zusammensetzen (im ersten Bild sind tatsächlich Teile für andere Gebäude zu sehen, hatte leider kein passenderes Foto).




Hier erste Gehversuche in meinem eigenen Code für generische Wände, wobei die Aufrufe je nur Einzeiler sind; das Modul "myWall" hat ca. 20 Zeilen. Was der String bedeutet, dürfte sich im Bild von selbst erklären.

Code: Alles auswählen

wall1 = myWall(30, 20, "WD W"); 
wall2 = myWall(40, 20, " WW  W ").at(35);

Ob mir das am Ende für Gameobjekte wirklich viel bringt und ich mal sowas wie das "Rusty Inn" so detailliert wie oben komplett in Code zusammensetzen kann, weiß ich noch nicht. Es geht auch erstmal nur um das einmalige Erstellen statischer Modelle. Nicht die volldynamische Generierung Ingame, nicht um vollprozedurale abwechslungsreiche Welten. Aber macht Spaß, damit zu spielen.

[Schrompf]

Je nachdem, wie weit Du das treibst, könnte das echt cool werden

[Chromanoid]

Ja echt cool. Ich hätte ja gerne ne Mischung aus Klicken und Parameter. Hattest Du mal https://www.plasticity.xyz/ getestet? Ich glaube das ist nicht zum Coden, aber dafür wenigstens Klicken :))

[joeydee]

Ich hätte ja gerne ne Mischung aus Klicken und Parameter.

Nennt sich eigentlich "CAD" ;) Natürlich hatte ich auch schon u.a. in Klassiker wie Fusion360 oder Tinkercad geschnuppert. Aber ich möchte ja neben reinen Zahlen- und Geometrie-Abhängigkeiten auch z.B. automatisches Auf-/Abrunden lösen wie "Bau mir ein Gitter von (x)mm Breite und rund 10mm Abstand, aber immer gleichmäßig aufgeteilt", außerdem Abhängikeiten mit if-Entscheidungen, Pseudorandom-Funktionen, und Komplexeres. Also Dinge, wo tatsächlich kleine Algorithmen dahinter notwendig sind. Am nächsten kämen dem glaube ich die Blender Geometry Nodes, die sind wirklich mächtig.
Aber ich möchte es tatsächlich mitten in meinem Projektcode erzeugen können, nicht extern mit Dateiimport, und die Geometrie darf auch gerne relativ Indie-Basic bleiben.
Das wird also leider kein Modeller für die Allgemeinheit, mit dem ich behaupte dass alles schneller, besser und einfacher wird ;)

[antisteo]

Ich habe eine nichtdeterministische CPU als Emulator implementiert. Dahinter werkelt eine Implementierung, die die Potenzmenge aller Zustände als Bitvektor kodiert und danch ein Feuerwerk an bitweisen Operationen darauf abfährt.



Hier noch das Github:
https://github.com/carli2/ndcpu

[joeydee]

Ein paar grundlegende Dinge gelöst wie z.B. die Verträglichkeit des 3D-Printer-RHS-Koordinatensystems mit meinem Framework-LHS, negative Scales für Spiegelungen, Farben (technisch per-Vertex, praktisch per Polygon, usage per Objekt), Debug-Highlighting ausgewählter Objekte, auch solcher die bei Operationen verlorengehen.
Operationen sind jetzt nicht mehr Methoden-Rückgabewerte, sondern nach kürzlichem Austausch im Chat using()-Scopes, Destruktoren und Stacks. Das Syntax-Prinzip ist dadurch technisch fast wie in OpenSCAD. Es fehlen zwar immer noch etliche Kleinigkeiten, aber es wird langsam nutzbar für mich.

Code: Alles auswählen

            CSGBuilder B = new CSGBuilder();      
                  
            //difference demo box
            using (B.difference())
            {
                B.cube(50, 50, 10);
                using (B.hl()) using (B.color(0, 1, 0)) using (B.at(20, -5, 2)) B.cube(10, 10, 20);//highlight
                using (B.color(1, 1, 0)) using (B.at(15, -3, 3)) B.cube(10, 10, 20);
            }

            //walls
            using (B.at(0, -30)) myWall(B, 32, 20, " WDW", 0);
            using (B.at(65, -30)) using (B.color(0.8f, 0.9f, 1)) using (B.scale(-1, 1, 1)) myWall(B, 32, 20, " WDW", 0);

            //windows
            using (B.at(0,-45)) using (B.timesX(5, 10)) myWindow(B, 5, 7);
            using (B.at(0, -55)) using (B.timesX(5, 10)) myWindow(B, 5, 7, 2, 3, 0.4f);

[gombolo]

Seit ein paar jahren programmiere ich sporadisch an einem Spiel. Shmups (Shoot 'em Up-Spiele) mögen zwar nicht die größte Fangemeinde haben, aber sie sind immer noch ein faszinierendes Genre, das viele interessante Herausforderungen bietet. Es deckt viele verschiedene Aspekte der Spieleentwicklung ab.

Ich habe neulich den dritten Endboss fertiggestellt.

YouTube Video
itch.io Seite

[Schrompf]

Ich mag solche Spiele, außer vielleicht dem "Git gud"-Aspekt. Ich freu mich!

[Mirror]

Erinnert mich an SWIV auf dem Amiga. Das habe ich gerne gespielt. Schönes Video...

[gombolo]

Vielen Dank für Euer Feedback... :)

Was den Aspekt des "Verbesserns" betrifft, so ist dies doch letztlich der ultimative Grund für die Einführung neuer Dinge.

Wir alle streben danach, in irgendetwas besser zu werden. Sicher...der Schwierigkeitsgrad beeinflusst maßgeblich den Verlauf unserer Lernkurve.

Die Einstellung dieses Schwierigkeitsgrads durch den Entwickler entscheidet darüber, ob ein Spiel den Spieler nur frustriert oder ihn dazu animiert, weiterzumachen. Eine falsche Einstellung kann dazu führen, dass das Spiel keinen Spaß macht. Da gebe ich dir Recht. Die Herausforderung besteht darin, diese Balance zu finden.