React Physics 3D : First Impressions

With my home engine coming to the state of being able to visually represent a world and move about within it, I've decided to set about sorting out a physics representation.

Very much as I did with the mathematics where I set about writing all my own code and then adopting a library; in order to best learn the process from first principles I also set about writing my own physics engine and visualizer (the latter using the much more familiar to me fixed function pipeline of DirectX 9 - Yes it still has a use in 2023!)

The physics implementation I went with was a simple rigid body test for cuboids and spheres.  Then a ray cast.  At which point I set about seeking a library as it's a huge topic I didn't want to sink too much time into.

I settled, after about a fortnight of reading and trying on React Physics 3D.

My initial impressions are that it is easy to set up, supports CMake and just worked; though I'm yet to fully get to grips with it, I am happy I have my world and simulation set up and working.

I've also happily separated my game objects from my visual objects with the use of my Ecs and I'm able to do the same, by registering a new Ecs update system with my entity list and simply piping the commands to create and destroy physics objects per frame.

The update pumping of time matches my engine instantly, so I had a lot of wins.

However, I am not building in a permissive manner, I have maximum warnings as errors, I have strictness on and permissive off; I also remove all compiler specific extensions, so I am using only C++ in it's rawest, most portable form.

Immediately, even though I've compiled React separately and then just link to the library statically, I have a bunch of the React headers giving me errors; notably map, BroadPhaseSystem and DefaultLogger.

The first two are the same sort of issue, which just surprised me, there's a constexpr uint64 set to minus one (so it's max) an unsigned value set to a signed negative to under roll it... Well it's quite bad practice:

static constexpr uint64 INVALID_INDEX = -1;

And I immediately updated this to:

static constexpr uint64 INVALID_INDEX { std::numeric_limits<uint64_t>::max() };

I may feed this back to the author, he most likely knows, maybe there's even a reason for it, personally I'd always stick to numeric limits and max in this case though, not least as it is constexpr and not a hack ;) 

The other one was a lambda expression in a call to std::transform for making all logging strings lower case, the code simply used ::tolower.  However, it was not type safe, it was converting int to char, but that's not explicit and so I changed it over to read:

std::string toLowerCase(const std::string& text) {
                std::string textLower{ text };
                std::transform(textLower.begin(), textLower.end(), textLower.begin(), [](const char& character) -> char { return static_cast<char>(std::tolower(character)); });
                return textLower;
            }

The lambda here is hard to read, so lets split it out:

[](const char& character) -> char 
{
    return static_cast<char>(std::tolower(character));
}

We take in a character, return a character, explicitly, so we have to cast the int return of std::tolower... simple really, but hard to read.  It compiles down well; but just using "::tolower" well that's a decay to int and you have to be permissive in your type exchange... I don't like that, express yourself in your code type correctly, and it'll be type safe.

Physics Debugger in my Home Game Engine

It may not look much, but this is a huge step forward in my home game engine development.  This is a physics visualization tool I've written, to show me the shapes I register with my physics simulation, it communicates with the game client one frame behind the client, and lets me zoom a camera around the world to see whether shapes line up and to take a snapshot of the physics/collisions being resolved this frame.

The whole physics system is pretty much a bag of spatial checks at the moment, for instance I ray cast from a given point to the four corners of a cube to test whether the point is within, that's pretty compute-intensive.

But at least now I can see there is only one such cube (the purple/pink) one in the scene.

I can also clearly see the ground mesh (the yellow/red triangles).

Infinity is just the blue.

Also, this rendering of the physics world is using yet another renderer I've put together, again integrating ImGui as my defacto GUI in such circumstances.

I need to do a lot of work on this, but it's just a fun project.

And recently having a bit of run, something you can tinker with, something which just makes you think and relax is perhaps key to improving ones skills.

Before I started this whole home game engine (despite working on games at work) I had no idea how to put a renderer together; even as badly as I have; and certainly no idea about a physics engine, now I have the rough knowledge of both.

My home project backing up my experience at work, and also the home project lets me try things I might not otherwise do at work, like totally break things... Oh no wait, I break things all the time....

Home Engine - Bank Holiday Camera Controls & More Models

After the silence earlier in the year I'm so happy to be blogging more often, and I hope you are all enjoying it too; I can see some regulars popping by and a few new faces in the stats list; but still far too many of you are totally anonymous, drop me a comment!

Anyway, what I have I been up to?

Well, under the hood I've totally revamped how the uniform buffer objects are passed to the rendering operation in the vertex shader.  I've also moved the view and projection matrix calculations into a nice camera system class, so they're contained and sensible to use.

As a result I've then added some key bindings to move forward, strafe and rise/drop the camera on the plane of x-z.  Likewise I've added a free mouse mode to let me move the mouse and fly over the terrain.

Speaking of terrain I've added a checker board to show me the X-Z plane at about -0.5 Y.

I also noticed a winding order in my Blender exporter tool, I've not fixed that in the python, just patched it in my loader and created a few more models to start building out a play space.

Technology wise I need to make the camera more usable - a full third person camera basically.  Then I would like an orbit cam, which moving in the strafe would move it around the locked object.

Then I'm going to think about texturing and lighting.

The solid coloured aesthetic is intentional though, so anything more fancy is a low priority for me.

I am feeling much more comfortable in Vulkan though; and of course enjoyed moving all the glm implementation from the first (and second passes) over this project.

That's perhaps something I've not mentioned to you before, this project as a home engine... Well I've started and restarted it a few times.  The original was in DirectX9 way back; I wrote a page about it in 2004.

Then I re-wrote that in fixed function pipeline OpenGL; that didn't go very far, indeed I received a letter to cease and desist from an IP owner for that particular project's name was known in the wider world.  That IP has moved onto yet another owner now, so best of luck to them.

I however was knocked for six and it wasn't until 2018 that I started to look at a game engine at home again, spurred on by my change of job; and I really enjoyed that first pass, but it didn't focus on the graphics side of things, it was far more about the technology such as threading, memory management, and something you may have heard of, an Entity Component System.

All those pieces remain.

But this new project is very much just about my putting features together into a renderer, indeed the application level item is called "renderDemoApplication" and that is all this is.

What might the game be?  I'm still thinking about that, but I have three strong contenders and when I've picked one, you folks will be the first to hear about it.

Home Engine - Blender Export & Model Loading

Some progress in my home engine has been had, first of all multiple geometry rendering through my fixing up and better understanding both render passes and descriptor sets.

All of this is nuts and bolts, what I want to get to; just like the DirectX 11 rendered version; is to play with 3D geometry and placing objects into a scene.

To this end my hand written geometry is no longer hacking it, and you will have seen from my raw game engine posts I did use Milkshape 3D.

Milkshape, lovely as it is to my eye, is not a modern well featured 3D suite and sadly does not let me easily plug into the geometry live within it (one can only export and perform post-processing).

To that end I delved into how one might write a Blender add-on to export your own format...

Long Story short, here's my text intermediate output from just such a plug-in written in python.

The plug-in is far from robust, I followed the lines of another open source plug in and applied my own, copying it into blender with a batch file and clearing the pycache each time I perform an edit.

But it is doing the job I initially want, and I get my own format of file output.

And indeed I can load these into my engine...

I can work on the axis for the data output and start to ensure my camera system from the main client works as expected in vulkan; since the maths here is exactly the same code I don't anticipate any issues.

This should free my mind up to think about a lighting system and to finally get back to where I was with the coloured cubes in the DirectX 11 version and ultimately onto a full scene.

I have four constant things in the world, a ground plane, a skybox and a center marker flag (showing X, Y and Z axis respectively) with a quartet of boxes in the center of the scene.  This is the test scene for the "world" loaded into the scene graph.  And it's where I want this to be this time next week perhaps.

Since progress has been much quicker now I'm past the deep dive into learning the initial set up of vulkan.

I can also appreciate much more why folks just pick up an off the shelf engine, I myself make little prototypes in Unreal Engine 4.  But this kind of denudes me of the walk through these technologies.

For the most part creating an engine like mine, which is planned to have solid shaded low poly vehicular combat, well it's a solved problem, so I'm enjoying following in a lot of well trod foot steps to better my understanding of the processing, memory, mathematics and challenges in writing a game engine.

Home Engine - Set Course for Vulkan

Over the last year I've been experimenting with writing my own home game engine, initially I spent time writing my own line rendering and then a wrapper with SDL2 all using my own mathematics library as a refresher.

Then I set up an engine framework, switched my own none-peer reviewed and frankly shaky maths for glm and started to use DirectX11. You can see a clip in my earlier blog post here.

I dabbled with other graphics interfaces, but ultimately I wanted to land on one of the two big modern interfaces, either DirectX12 or Vulkan.... And since I'm a linux guy at heart Vulkan won out. The difficulty? Well, setting up a Vulkan renderer just to render the "Hello World" triangle is over a 1000 lines of code.... And well, I wanted to write a framework as I went so I could just port this Vulkan back-end work into my abstract renderer API for my existing DirectX11 driven engine. That is my next step, but tonight, after a few hours each night this week I've finally gotten to the 3D step and I'm so excited I wanted to share with you.

So here we see I have multiple pipelines & render passes. It's creating and submitting multiple command buffers, I have integrated ImGui very roughly too.

But this is the first time I've used the uniform buffers, descriptor sets and descriptor layouts to send a uniform buffer (MVP) to the shader and get actual 3D.

I'm strongly following this online tutorial.

Though I also have the Vulkan Programming Guide official book and I'm writing my own functions as I go so the porting to the existing Home Engine API is minimal (or rather as minimal as I can get it).

One of the key pieces of tech in the base engine (driven happily by DirectX 11 when I switch to it) is a full camera fly mode system and a scenegraph rendering models.  I've also got a python driven exporter written for my own model format from Blender (and desperately need to get better with using Blender).  And I have a Python driven project generator (which calls down into CMake quite neatly).

The engine is structured into six major modules:

Base - which contains a host of utility functions, data types and tooling assistance.

Ecs - yes, I'm writing my own Entity Component System.

Renderer - The abstract renderer API which the application level creates and uses in the main game loop.

Application - Main app & game loop, I'm using SDL2 as the main interface here for input & window management in a cross platform manner too.

Physics - A basic hand written rigid body physics implementation, at the moment it really only supports rays, cubes and sphere intersection tests and I'm thinking of shopping around for an off the shelf something.

Game - Contains specific game logic, like spawning, camera controls, input mapping and uses base to provide timing.

This is all very rough and ready, it's a project to keep me interested in my craft really.

And putting Vulkan into the mix has been a real nice way to resurrect where things where, as you may gather I had the DirectX 11 and basic camera system all working in October 2021; but I've been a busy boy since then, both with work, life and moving house....

Now the new office is done and I'm building models in real life, I figured it'd be a nice time to build them in virtual spaces too.

P.S. I have no idea why some blocks are in white backgrounds, very annoying of Blogger to do that?

Home Engine - Lines and Camera Interaction

 Yes, yes, it has been a while; both here and on the YouTube channel, I've just been very busy okay?... Okay.  Friends?... Friends.

So what have I been up to in code?... Well today I added line rendering to my home engine, this is still using the underlying "Triangle" raw data, so I have to always have a cleanly divisible by 3 (for the sides of a triangle) number of indices in the data, but otherwise it just seamlessly integrated.

Its using "LineList" as the underlying primitive type, which maps to the D3D11 type under.

I also noticed that these lines from 0, 0, 0 to 1, 0, 0 and 0, 1, 0 and 0, 0, 1 respectively are "backwards", that is my unbeknownst to me at some point my camera has started to spawn around in front of there my scene objects are, so I'm looking back along the Z axis not "up" along it... Am I making sense?

I also improved the camera some by linking the rotation of the camera to the mouse, which makes it super intuitive.

The failed part of the work this last month was an effort to update both the Vulkan and the OpenGL renderer implementation.  This was an utter failure, the simple reason being that I've gone too long with my limited knowledge with DirectX.  I'm sure the "port" to DirectX12 will be easier, but yeah, I've already gotten the other API's so far from my implementation (abstract base classes) that it's quite alien to return to them.

I'll circle back on that, maybe break down the API's with failed/broken builds until I can slowly etch away at the challenge.

Raw Graphics Engine : C++ Project

It has been a whilst since I had a personal improvement project grace these pages, so here's one I started over the weekend.... A graphics engine.

Sure this is something I play about with all day in the office, we're writing games!  That's literally my job, but I've been a system engineer for such a very long time, and I've seen all these sparkly things coming from folks working on game play and wanted some sparklies of my own.

I therefore began two projects, both are graphics engines, but they're very different from one another... one is in Vulkan, which is not what we're talking about here, no we're talking about the other one... And this is a graphics engine I've written myself.

It's gone through three phases since Saturday, Sunday and then just tonight.  The first phase was setting up the basic rendering, getting a triangle on the screen and making it flat (orthographic) projection.

The engine is written in C++, uses SDL2 for the window and renderer, but the engine itself does all the geometry transforms through linear matrix mathematics that I hand crafted, and it reaches into the third dimension in orthographic mode.

The shapes can be rotated, scaled, translated, the usual.  But before I drove myself mad with writing shapes by hand on graph paper, I wrote a very simple importer for the very simple Milkshape 3D model editor, and started with a sphere:

Milkshape has appeared on these pages before and is really the only modelling package I'm familiar with, I really do need to learn Blender don't I?

So with models loading I got a little adventurous:

This mesh really stresses my single core linear mathematics, so I started to switch it out in favour of GLM tonight:

// Model

glm::mat4 model(1.0f);

model = glm::translate(model, trans);

model = glm::rotate(model, glm::radians(angleZ), { 0, 0, 1 });

model = glm::rotate(model, glm::radians(angleY), { 0, 1, 0 });

model = glm::rotate(model, glm::radians(angleX), { 1, 0, 0 });

model = glm::scale(model, glm::vec3(scale.x, scale.y, scale.z));

So, that's been my three days.. I'm interested where and what I will do with this engine.

However, Vulkan, that's the other thing I'm learning.