Changing graphics engines

Finished doing the import tool. And surprisingly it takes just a couple seconds to run (compared to taking dozens of seconds when directly importing in the game).
I also tweaked the cloud shader to make it render before the cells (so now it is always behind them). Here’s a screenshot of that:


Membrane wiggle is back

Also I almost completely accidentally made it so that the wiggle depends on world position, so now when the cell moves it wiggles more. There is some slight weirdness with the texture swapping directions sometimes, but I’ll leave it for now.

I hit an issue with the lighting (BSF now for me doesn’t want to import any transparent shaders with lighting… hopefully this can be resolved), so for now the cell doesn’t have any lighting on it.


First look at chunks. The lighting seems to not be smooth and instead the vertex boundaries are very visible.

Also iron_01 and iron_02 models are missing… and many of the model names don’t correlate with the .blend files we have…

1 Like

Turns out the non-smooth lighting was due to “mark sharp” option on all the edges of the rock models.
This is after editing the models:

The light is still a bit strong, but I’ll do the editor next before doing a final round of tweaking.

1 Like

Working on the editor now. For some reason the script exposed versions of the mouse position to world coordinate translation didn’t work, so I swapped the scripts to call the C++ get target point method.
Also added style to the scroll bar (which now works with the mouse wheel):


Some work on getting organelle models showing up in the editor:

A ton of the models are either named something strange or the texture names are missing, so only just one organelle works for now.

1 Like

The editor is now working (at least the organelles I could test):

But for some reason they don’t show up in the stage yet. Once I get that done, I think I’m mostly done with everything and can jump over to Windows to fix the build there.


Remade the organelle shader. This also has the lighting issue ( so they don’t react to light.

1 Like

Video player is now done:

So I think this means that, while there are a bunch of stuff still do, it’s time to commit to svn and start thinking about merging.
There’s a ton of changes:

I already did a merge with the engine. If anyone wants to check the commit history on that, it’s here:

I also created a pull request for thrive:

I’m not going to merge it just yet


Great work on this, you’ve made really rapid progress :slight_smile: :+1:

Things are getting closer to being done:
Soontm it will be time do a public tech test to see if the game runs on different computers.

1 Like

Getting closer to having animations on flagella again:

Those are just the changes needed to handle importing the animation data…

1 Like

Code for the flagella animation is now done (hopefully). However the model and animation is a bit broken, but that is already being worked on by @Uniow. So hopefully the flagella will look good soon.


Added skybox importing and I added one to thrive. Seems it doesn’t do much for the membrane:

But in the editor it makes the grey hexes look less dull:


Speed changing of the flagella animation is back in.
Positioning of the flagella is now correct (on the membrane edge):

Opened an issue about the resizing being broken:

1 Like

I guess I should post something here as well for this week.
I did mostly non-visible stuff:

I took a few screenshots just to put here:

Here I accidentally used the vertex buffer size for rendering so only a part of the membrane showed up.

Here’s a screenshot of renderdoc showing how the membrane is now a triangle list (to support directx):

I don’t have a screenshot of the working membrane as it looks exactly the same as before.

The membrane is now rendering as a triangle list, which means that directx support is closer.


The bsf version is now ready for early testing:

I forgot to mention that the pull request is now merged. All that’s left to do is fix a bunch of stuff and hopefully find some way to squeeze more performance on intel, however that might be a bit problematic:

I’m currently working on fixing crashing on shutdown (so that I can debug the reported memory leak):

1 Like

The high memory usage was due to each organelle loading its texture (instead of there being one copy). There is now a partially working solution (I think it causes everything to be loaded exactly twice):

Fixing this properly needs a bunch of changes to the resource import process to create a manifest file. The good news is though that there was no memory leak related to bsf. However I did find one small(ish) memory leak, that is now fixed in Leviathan.

I’m also working on moving my custom hacky bsf setup, to be supported in bsf directly:


I feel like this topic is once again relevant, with the huge number of compatibility issue reports ( 193 currently) and what I presume to be actual bugs in bsf causing random crashing while trying to render:

These issues are currently not going to get better as the bsf developer has put bsf on the backburner after starting a new job. It’s been more than two months since the last commit and the developer has also not replied on the bsf forums in a while.

So as unfortunate it would be for short term progress, we need to consider a different graphics engine (or maybe even switching to godot, but that once again is way more work, with a new graphics engine the existing GUI can be kept as is). I’ve been looking at a bunch of different ones, but one that really caught my eye is diligent engine:

It has a bunch of nice features, like:

  • Supports a ton of APIs DirectX11, DirectX12, Vulkan, Metal, and OpenGL 4.3+. So it should cover all the platforms, though I spotted in their documentation that On Windows 7 only Vulkan and OpenGL is usable, so people with old intel integrated graphics need Windows 10, but that shouldn’t be a problem.
  • It is low level graphics API abstraction, meaning that it is basically a layer to help code so that your code can work with all the rendering backend. This should make it way less likely that there are things that are not possible. But at the same time this means I need to code our own graphics pipeline using the basic rendering operations.
  • It seems to be in very active development with commits happening daily. But referring to the previous point I perceive only a small risk from the project being abandoned as it seems to be a thin enough library that I could consider working on it myself after I gain more graphics programming experience from working on such a low level library.

While low level by default, it has a pbr rendering module: but I haven’t yet checked how easy that is to use, if it is easy to use we can use that to render all the stuff in Thrive.

So my plan is

  • First adding a bunch of abstractions so that Thrive doesn’t use anything bsf related, instead it would use Leviathan objects that wrap the bsf objects. With this a graphics engine change will be much more transparent to Thrive, though some changes will be required.
  • Second change the engine graphics abstractions to use Diligent internally. And then make changes needed to thrive. But before fully committing I’ll try to make a tech demo to see if people with intel graphics can run the game.

This should reduce the impact of the change. And hopefully make the game playable for a large number of potential new fans who haven’t been able to play the game yet. The next phase is then to change out CEF which also causes a lot of compatibility issues with a custom GUI library that will at the same time be more lightweight as well as easier to use.