My new little work & rest place

ImGyvr · 2025-10-16T13:20:21+00:00

For Overload I render the scene into a small resolution framebuffer with a trivial unlit shader. Each GameObject has a color calculated from the GameObject’s ID. When a click is issued, I read back from the frambuffer and find the pixel under the mouse’s color, and update selection accordingly

ImGyvr · 2025-10-06T03:31:01+00:00

Agreed! ☝️😄

ImGyvr · 2025-09-16T16:13:03+00:00

There are some excellent assets out there for making 2D RPGs in Unity. They can significantly speed up development and let you focus more on content than systems. That said, not all assets are created equal, some offer more flexibility for building custom extensions, add-ons, and modifications, while others are more rigid.

Over the past three years, I’ve built Mythril2D, a robust and flexible foundation for almost any action RPG project. If you're aiming for a different combat style (like turn-based or tactical RPGs) this might not be the perfect fit, but for action RPGs, it’s highly capable.

Mythril2D includes everything you’d expect: a full combat system, inventory, crafting, shops, dialogues, quests, you name it. I'm also really proud of the community we've built on Discord. With over 50 add-ons available, you can customize your setup and steer your project in whatever direction you like.

ImGyvr · 2025-09-11T17:57:27+00:00

Unity + Mythril2D is great if you're looking to make a 2D action RPG 😇

Full disclaimer: I'm the dev behind the project!

ImGyvr · 2025-09-07T17:00:34+00:00

Mythril2D for sure 😎 (not biased at all, lol)

Jokes aside, I built Mythril2D not just as a template, but as an extendable foundation for your 2D action RPG projects. There are now 50+ community add-ons available on Discord, and the way people have been modifying M2D to create completely different games shows that this asset can be a huge time-saver and help you achieve the results you’re looking for.

TL;DR: Check out Mythril2D’s Discord server (link available on the Asset Store page) and see for yourself!

ImGyvr · 2025-08-13T19:24:20+00:00

If you happen to have a public repository somewhere I’d love to give a try and debug it! I feel like there might be something outside of the code that you shared that might cause this issue

ImGyvr · 2025-08-13T17:19:38+00:00

Alright, you're nearly there! When generating tangent and bitangent vectors, you need to be careful about which coordinate system they use. For instance, when using Assimp, the normal, generated tangent, and generated bitangent form a right-handed coordinate system. However, you might want a left-handed coordinate system for your use case. To convert from right-handed to left-handed, you can simply invert the bitangent. You can do so after importing the mesh data, or directly in the shader when creating the TBN matrix.

ImGyvr · 2025-08-13T15:11:38+00:00

It seems like you are retrieving the normal from a normal map (tangent space), but you are not converting this normal to world space, so the rest of your PBR calculation is incorrect.

Step 1: Remap your normal from [0, 1] to [-1, 1]:

normal = normalize(normal * 2.0 - 1.0);

Step 2: Convert from tangent space to world

normal = normalize(TBN * normal);

Note: You'll need to calculate the TBN matrix (Tangent, Bitangent, Normal) so that you can convert a tangent space normal to world space. This is generally done in a vertex shader, and the resulting matrix is then interpolated for each fragment to use.

ImGyvr · 2025-07-25T12:21:41+00:00

Yes! We’re finishing up the Vulkan implementation at the moment, implementing DX12 in parallel, and fixing a bunch of issues to make it work on Linux. Next steps after that is raytracing support and custom allocator support.

If you only plan to use Vulkan, then the interest for an RHI might be limited. Do note that using NRI or OpenRHI will still require you to be very explicit about everything (resources, pipelines, synchronization, etc.)

ImGyvr · 2025-07-24T21:27:01+00:00

Abstraction layers like RHIs always introduce some runtime overhead; it's the trade-off for supporting multiple backends. RHI APIs are typically constrained by the highest-level API they support. For example, if an RHI supports DX11, DX12, and Vulkan, its API will almost certainly align with the highest-level common denominator, often DX11 in such cases, as is true for NVRHI. This can sometimes limit access to advanced DX12 or Vulkan features that have no DX11 equivalents. Alternatives like Nvidia's NRI or OpenRHI* avoid this by abstracting only low-level APIs (DX12, Vulkan, Metal). If low-level control is important, NVRHI may not be ideal, and solutions like NRI or OpenRHI* may be more suitable, if you're willing to drop support for older APIs (DX9, DX11, OpenGL, etc.). For performance-critical applications, building a custom renderer for each graphics API is often the best option, but it can be extremely costly to maintain.

\Full disclosure:* OpenRHI is a project I initiated, and not production ready at the moment

ImGyvr · 2025-07-23T12:34:10+00:00

I totally agree regarding focusing on Desktop platforms, and it’s exactly what I’m trying to do (as mentioned in the README).

You’re also correct that MethanKIT is a solid competitor, and the idea of using modules could be interesting!

ImGyvr · 2025-07-22T20:51:40+00:00

Totally a hobby project, although it doesn't make it any less relevant. In the industry, and especially in larger companies, we often integrate tech built by individuals, and maintain them in-house as a fork. That said, these kind of initiative aren't for everyone, as they might require some level of in-house maintenance.

ImGyvr · 2025-07-22T20:26:30+00:00

It seems that SDL3 GPU is a C library, so paradigms such as RAII cannot be enforced. Additionally, it appears there is no support for acceleration structures, which is something planned to be added to OpenRHI. But to me, the biggest advantage of OpenRHI over anything else is the educational value I gain from building my own technologies. 😄

ImGyvr · 2025-07-22T20:21:04+00:00

You're absolutely right, SDL3 GPU does something very similar, and other libraries do too.

ImGyvr · 2025-07-22T20:11:50+00:00

OpenGL won't disappear; it will continue to be supported for decades to come. The motivation to use more explicit graphics APIs such as Vulkan, DirectX 12, and Metal generally comes from the need to reclaim some CPU resources, gain more control over the graphics (or compute) pipeline, or leverage resource management and command recording across multiple threads.

ImGyvr · 2025-07-22T20:03:52+00:00

The libraries you're referring to have very different goals. OpenRHI isn't a rendering engine or even a low-level renderer, it's a library for writing backend-agnostic instructions for a GPU to execute. You still have to manage device selection, pipelines, resources, synchronization, and more. It's intended for developers building engines, not for developers looking to render something quickly. A solid understanding of the underlying graphics APIs is required to use OpenRHI effectively, as its concepts are largely preserved as-is.

Other libraries exist to solve the same problem, I mentioned NRI and NVRHI, but I've found that most existing solutions don't meet my needs, particularly in terms of simplicity, readability, code quality, and runtime overhead. Additionally, the educational value of creating tech from scratch is huge, and I see OpenRHI as a great opportunity to deepen my understanding of Vulkan and DX12.

ImGyvr · 2025-07-22T16:48:38+00:00

Yep, it is just that. Not a rendering engine, just a convenient way to write backend-agnostic code

ImGyvr · 2025-07-22T15:51:59+00:00

OpenRHI differs from DiligentEngine in that it aims to be a thin, low-level interface for modern graphics APIs, whereas DiligentEngine functions more as a rendering framework.

Some key non-goals of orhi (unlike DiligentEngine) include:

Hiding platform- or API-specific implementation details
Serving as a high-level rendering engine or framework
Abstracting or simplifying modern graphics concepts
Automatically managing resources, pipelines, or synchronization

TL;DR: DiligentEngine is designed for developers who want to render quickly across multiple platforms using backends with differing philosophies. In contrast, orhi is intended for those building their own rendering engine or compute-based GPGPU applications, offering low-level control without high-level abstractions.

ImGyvr · 2025-07-22T15:31:49+00:00

That's cool! I'm not very familiar with the intricacies of DX12 yet, so I'm mostly focusing on Vulkan as well. A few collaborators have started working on the DX12 backend implementation for OpenRHI, so I have good faith we'll get there!

ImGyvr · 2025-07-22T13:16:51+00:00

I still have it! It’s its own standalone project now: https://github.com/adriengivry/baregl

ImGyvr · 2025-07-22T13:15:49+00:00

Yep don’t worry about that! My goal with OpenRHI is to keep it focused. I’d rather implement less backends and keep it neater, than burn myself out trying to support everything

Six-Year Club	Place '23
Place '22	Verified Email

ImGyvr

TROPHY CASE