would it be better to use OpenGL or Vulkan? And for UI editors, is it done with ImGui?

MichaelKlint · 2026-05-17T19:08:38+00:00

"Your opinion is wrong because having an opinion is...unhealthy."

MichaelKlint · 2026-05-17T19:06:54+00:00

It will be available on the beta branch on Steam in a few days, and then it will go onto the default branch in two weeks or so, after it's been thoroughly tested. The beta branch is something you can opt into in the application properties in the Steam interface.

MichaelKlint · 2026-05-17T14:10:15+00:00

Yes. There is a demo on the Steam store page here, and it will be updated when 5.1 is released: https://store.steampowered.com/app/251810/Leadwerks_Game_Engine_5/

MichaelKlint · 2026-05-17T01:51:31+00:00

Great job!

MichaelKlint · 2026-05-16T22:55:13+00:00

Because I suspect what you created with Vulkan isn't that impressive.

MichaelKlint · 2026-05-16T20:39:16+00:00

MSAA works great and runs fast. I have no idea why I am the only developer using it.

MichaelKlint · 2026-05-16T18:59:54+00:00

Thanks!

MichaelKlint · 2026-05-16T18:59:04+00:00

Show us your renderer.

MichaelKlint · 2026-05-16T18:46:21+00:00

Vulkan is garbage, don't let anyone try to shame you into using that broken junk.

MichaelKlint · 2026-05-05T17:02:42+00:00

Strange how "close to the metal" actually means "layers and layers of useless abstractions". If they keep this up they will finally reach parity with OpenGL in ten years.

MichaelKlint · 2026-04-20T22:06:29+00:00

Considering the number of high-profile failed projects and how many studios are throwing in the towel on their own proprietary technology, it seems like Vulkan is a terrible choice for triple-A games.

MichaelKlint · 2026-04-15T19:09:23+00:00

You might want to give it another try. I'm working with about 10 different GPUs and everything is working flawlessly, even old Intel integrated graphics chips. The vendors have really cleaned up their drivers.

MichaelKlint · 2026-04-15T19:05:37+00:00

Great, I am glad you have moved on to weird Vulkan driver issues.

MichaelKlint · 2026-04-15T18:50:50+00:00

I have worked extensively with bindless textures in OpenGL, writing a complete renderer build around this technique. It's not worth it.
https://www.leadwerks.com/community/blogs/entry/2352-real-bindless-textures/

We saw severe driver bugs that arose during development. I don't mean that we discovered a driver bug we didn't know about, I mean a new driver came out that introduced the bug, when everything was working fine on the previous driver. On Nvidia drivers it was a severe memory leak that was extremely hard to track down. On AMD cards the program just crashed when the new driver came out. Both issues were solved after we reported them and demonstrated the problem, but it wasted a lot of time and I had to tell people for several months they had to install an old driver.

The way bindless textures are implemented in that extension isn't great to work with. The resident / nonresident stuff is weird, the fact you have to recreate a new sampler to change any settings is weird, and managing multiple bindless texture handles across different contexts is not great. Although they're not terribly complex, bindless textures are dangerous and any problems are very hard to track down. Eventually you're going to run into an issue where you start inexplicably crashing the driver because you have the equivalent of an invalid memory address on your GPU.

Worst of all, the freedom of being able to access any texture at any time often leads to poor design. Being constrained to just 16 texture samplers kept me more focused and I actually ended up with simpler code that ran faster that way.

I ended up switching back to standard texture binding. The only things I lost doing that were multidraw indirect rendering and projected decals on transparent surfaces, since those are rendered in a forward pass. I am okay with this tradeoff.

MichaelKlint · 2026-04-08T17:51:42+00:00

Render all transparent objects into a separate framebuffer. When finished, use the framebuffer color attachments as inputs for a full-screen shader that draws all transparent objects on top of the scene.

You can use the clear values and blend function to make the layers blend together. For example, the surface roughness could use a max or additive blend, so the final roughness is at least as rough as any of the glass planes at that pixel. If your normals are stored in some kind of normalized (0-1) texture format, use 0.5, 0.5, 0.5, 0.0 for the clear color of the normal attachment. That way the glass pane normals will just sort of blend together, and blend with the background, even when the alpha channel of the normal output is less than one.

This also happens to be the only way to draw something like a heat haze effect, where you have many particles drawn on top of each other, without sorting. In Leadwerks I draw all transparency this way.

To prevent objects in the foreground from appearing in the blurred transparent background, you have to use a depth-aware blur / downsample shader. The trick is to just grab a sample from the highest mipmap if the pixel you're looking at is closer than the Z-distance of the glass surface. This does a good job of filtering out the bad foreground pixels.

More info here: https://www.leadwerks.com/community/blogs/blog/1-development-blog/

MichaelKlint

MODERATOR OF

TROPHY CASE

MichaelKlint

MODERATOR OF

TROPHY CASE

Welcome to Reddit,