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 - 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 - Loading PNG Textures into DirectX11 with SDL2

ANYONE Interested in my sharing the code to do this?  Leave a comment, 10 comments and I'll blog it.

I'm using SDL2 as the background framework for providing cross platform input and window handling, but I'm writing my own renderers for various platforms (DirectX11, 12, OpenGL and Vulkan).

All of them support coloured shape and line renderering to one extent or another, so I decided to take the leap into texture mapping.

First of all I put in all the framework to represent textures in my engine in a cross platform manner, and for ease I decided to use SDL2_Image to load my pixel data.  And I started with a simple PNG file I created in MSPaint....

Immediately I ran into issues, PNG is RGBA, the png I created had a transparent background as far as I knew it should all work.  I swapped to RAW pixels and I was getting 4 bytes per pixel, it was only after a bunch of reading and then stepping into the SDL_Surface format did I realise the data might be whatever format but the surface was clearly 3 bytes per pixel.  And funky things were happening.

My assumption that MSPaint was outputting 4 bytes per pixel was just wrong, instead it's 3 bytes, RGB.  And there's no matching DXGI_FORMAT for just RGB - least none I could spot.

A quick reexport in GIMP setting the explicit pixel format to 8bpc RGBA, which then of course just worked....

Therefore, it's official, using an SDL2_Image load of a PNG as your DirectX11 texture is perfectly possible.

And for me, this reduces the need to include yet another library (other than SDL) to handle image loading.

----

Not even sure how, but this older video got attached to this post, which is about "SuperSampling".... but really just changing the renderer to window resolutions...

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.

Perlin Noise Terrain Chat #0

No ship diorama update.?!?!??!!?  Yes, thank you for the six messages (a record for messages in just a few hours - I'm writing this one Monday night) there will be an update later this week.

So what have I been up to?... Well, I've been rewiring the conservatory, so I can work in it, and this space is to become a second office space for me, a different place to let my creative code juices flow.

The first thing I've been doing is playing about with my raw graphics engine and building terrains within the 3D space.

Now, I did a bunch of terrain generation for a Hex-bases wargame that never made it to market; many years ago, and I still have one of the early prototype screenshots here:

 

Its that underlying mesh I was looking at getting to, some cell by cell generated terrain that I could undulate and stitch together with seamless edges.

 But before all that my graphics project needs a generator, and I decided to build the height map for this mesh with perlin noise.

This is my perlin implementation, I'll go a head and play about with generating a mesh from this, luckily I only have to generate the y value for a given x and z axis distance, so I could parallelise this quite well across my many core machines.

More to follow I guess...