Current design decisions for my game engine:
Uncategorized
85
Posts
1
Posters
0
Views
-
Once I have my game engine where every panel in the editor is detachable I'll get a third monitor to make it worth the effort
Hmm I wonder if it's worth checking out Qt as well as an option for editor GUI... it seems like a heavy dependency but it might be more suited for what I want to do. ImGui is great for in-game debug UI but is not really meant to be used for a full application
-
Hmm I wonder if it's worth checking out Qt as well as an option for editor GUI... it seems like a heavy dependency but it might be more suited for what I want to do. ImGui is great for in-game debug UI but is not really meant to be used for a full application
Should... should I write my own UI library? I'm gonna need one for ingame UI anyway, could do it like Godot did and make it so it's usable for an editor as well.
But I was kind of hoping my ingame UI tooling wouldn't need to be constrained by having to support regular desktop widgets and interactions, so I really should just pick a third party solution for the editor... nyeh
-
Should... should I write my own UI library? I'm gonna need one for ingame UI anyway, could do it like Godot did and make it so it's usable for an editor as well.
But I was kind of hoping my ingame UI tooling wouldn't need to be constrained by having to support regular desktop widgets and interactions, so I really should just pick a third party solution for the editor... nyeh
Ok I think I'll stop shedding the bike for now regarding editor gui and multi-window support. Just thinking about it was valuable and clarified some future requirements, but they can be implemented later. Next steps:
- Hardcode a 3D pipeline (like a cube)
- Load a gltf and render it bindlessly
- Dehardcode the pipeline -
Ok I think I'll stop shedding the bike for now regarding editor gui and multi-window support. Just thinking about it was valuable and clarified some future requirements, but they can be implemented later. Next steps:
- Hardcode a 3D pipeline (like a cube)
- Load a gltf and render it bindlessly
- Dehardcode the pipelineLast time the internal mesh data format I used was huge - it was just the vertex and index buffers dumped into a file so they could be memcopied into the GPU quickly without processing. This time I'll also add a (de)compression step, that should still be pretty fast. And use meshoptimizer during the import step.
-
Last time the internal mesh data format I used was huge - it was just the vertex and index buffers dumped into a file so they could be memcopied into the GPU quickly without processing. This time I'll also add a (de)compression step, that should still be pretty fast. And use meshoptimizer during the import step.
ok forget hardcoding a cube mesh in the shader, going straight for glTF model loading. I can copy paste parts of that from the previous iteration of the engine, while improving it at the same time.
-
ok forget hardcoding a cube mesh in the shader, going straight for glTF model loading. I can copy paste parts of that from the previous iteration of the engine, while improving it at the same time.
glTF model loading and 3D rendering with depth work! There's some strange bug when I try to load in larger models, and there are a bunch of validation errors about synchronization issues, but those are for another day
-
glTF model loading and 3D rendering with depth work! There's some strange bug when I try to load in larger models, and there are a bunch of validation errors about synchronization issues, but those are for another day
Progress of the evening: fixed the problem that prevented some models from loading (it was just a wrong variable), loading all meshes / surfaces in a glTF now, loading normals. Textures will be next!
-
Progress of the evening: fixed the problem that prevented some models from loading (it was just a wrong variable), loading all meshes / surfaces in a glTF now, loading normals. Textures will be next!
biblically accurate bindless textures
-
Engine rewrite progress update after an extended weekend:
- Bindless textures and materials
- Normal mapping
- Scene tree with transform hierarchy
- Camera and scene data in per-frame uniform buffer instead of push constants
- MSAA
- Lots of refactoring and new abstractions -
Engine rewrite progress update after an extended weekend:
- Bindless textures and materials
- Normal mapping
- Scene tree with transform hierarchy
- Camera and scene data in per-frame uniform buffer instead of push constants
- MSAA
- Lots of refactoring and new abstractionsSome stuff was mostly copy-pasted from my previous project. The really new thing is the bindless paradigm. This finally helped me understand descriptor sets - I was really confused about them last time when I followed vkguide.dev.
Not sure if I'm doing bindless "right" or if I'm bound for troubles down the road but so far it works pretty well! I only do a single vkCmdBindDescriptorSets per frame, binding global resources, and push material IDs per object in push constants.
-
Some stuff was mostly copy-pasted from my previous project. The really new thing is the bindless paradigm. This finally helped me understand descriptor sets - I was really confused about them last time when I followed vkguide.dev.
Not sure if I'm doing bindless "right" or if I'm bound for troubles down the road but so far it works pretty well! I only do a single vkCmdBindDescriptorSets per frame, binding global resources, and push material IDs per object in push constants.
I don't know yet how this will change once I add more shaders / material types though. I only have a single graphics pipeline right now, figuring out a system to expand on that will be the next big task.
Also Slang has some stuff dedicated to "bindless" but I didn't really understand it and also it seems to work without it? Might refactor the shader once I figure out the advantage of DescriptorHandle and how to use it
-
I don't know yet how this will change once I add more shaders / material types though. I only have a single graphics pipeline right now, figuring out a system to expand on that will be the next big task.
Also Slang has some stuff dedicated to "bindless" but I didn't really understand it and also it seems to work without it? Might refactor the shader once I figure out the advantage of DescriptorHandle and how to use it
Anyway, possible next steps:
- Mipmaps
- Basic lighting
- Finally start cleaning up resources correctly
- Maybe look into batching the uploads of assets the GPU -
Anyway, possible next steps:
- Mipmaps
- Basic lighting
- Finally start cleaning up resources correctly
- Maybe look into batching the uploads of assets the GPUWith the combined power of albedo, normal maps, and a simple dot product I present: basic lighting
-
With the combined power of albedo, normal maps, and a simple dot product I present: basic lighting
Got a bunch of stuff in mind for where to go next (Qt based editor, copying over more systems from the old codebase, etc) but I have to try to slow down development for at least the next month to focus on other priorities
-
Got a bunch of stuff in mind for where to go next (Qt based editor, copying over more systems from the old codebase, etc) but I have to try to slow down development for at least the next month to focus on other priorities
Despite trying to put my focus elsewhere I've done some experimentation and thinking lately regarding editor UI.
I want to use Qt since it's a mature cross-platform UI framework. But it actually consists of two frameworks: QtWidgets (traditional desktop UI, software-rendered, uses procedural C++) and QtQuick (GPU rendered, mobile support, uses declarative QML and optional JavaScript and/or C++).
QtQuick seemed more "modern" so that's what I started with.
-
Despite trying to put my focus elsewhere I've done some experimentation and thinking lately regarding editor UI.
I want to use Qt since it's a mature cross-platform UI framework. But it actually consists of two frameworks: QtWidgets (traditional desktop UI, software-rendered, uses procedural C++) and QtQuick (GPU rendered, mobile support, uses declarative QML and optional JavaScript and/or C++).
QtQuick seemed more "modern" so that's what I started with.
First major task was getting a 3D viewport rendered by my engine into a Qt window. Qt is quite flexible and there were a lot of different avenues that seemed feasible for this. There were Most of them didn't work out in the end or were intended for different use cases.
What worked for me in the end was:
-
First major task was getting a 3D viewport rendered by my engine into a Qt window. Qt is quite flexible and there were a lot of different avenues that seemed feasible for this. There were Most of them didn't work out in the end or were intended for different use cases.
What worked for me in the end was:
- Render viewport to an offscreen image
- Export the memory with "vkGetMemoryFdKHR"
- In Qt, create a VkImage and import the memory that was exported from the engine
- Extend QQuickItem and QSGTextureProvider to show the VkImage on a custom QML type window -
- Render viewport to an offscreen image
- Export the memory with "vkGetMemoryFdKHR"
- In Qt, create a VkImage and import the memory that was exported from the engine
- Extend QQuickItem and QSGTextureProvider to show the VkImage on a custom QML type windowThe reason for doing it in this roundabout way is that Qt uses its own Vulkan instance and device, and you can't just directly use images in one instance that were created by another one, even if you're in the same process.
I _could_ have told Qt to just use my Vulkan context for its own rendering, and I tried it and it technically worked, but that led to all sorts of synchronization issues and crashes.
-
The reason for doing it in this roundabout way is that Qt uses its own Vulkan instance and device, and you can't just directly use images in one instance that were created by another one, even if you're in the same process.
I _could_ have told Qt to just use my Vulkan context for its own rendering, and I tried it and it technically worked, but that led to all sorts of synchronization issues and crashes.
Right now I _still_ get validation errors, but no crashes (until I close the window, probably because I do zero clean up currently :D)
So proof of concept for the most important aspect: done ✅
Next up: finding Qt libraries for some advanced UI stuff I wanna use.
-
Right now I _still_ get validation errors, but no crashes (until I close the window, probably because I do zero clean up currently :D)
So proof of concept for the most important aspect: done ✅
Next up: finding Qt libraries for some advanced UI stuff I wanna use.
Most importantly: docking. My vision for the engine editor is that everything is a fully configurable and detachable dock. It should be able to spread over all your monitors!
Qt has built-in docking functionality, but it's restricted to QtWidgets (i.e. not available in QtQuick) and is a bit limited.
First library I looked at was Advanced Docking System for Qt: https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System
Seemed very promising but it doesn't have (and will never get) Wayland support, so not an option :/
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Che poi, spacciano per Made in Italy ciò che non lo è, ma il vero Made in Italy costa. Gli italiani, in massa, hanno perso la capacità di capire la qualità, quindi vanno di schifezze a prezzi bassissimi. Il Casentino ti dura una vita ma costa. Quando avranno capito che il low cost non esiste perché qualcuno il prezzo lo paga, la filiera italiana sarà morta e sepolta. Amen.
-
@Linkshaender
che meraviglia!
buonanotte Armin 🌌
-
•
frugando nella scatola dei ricordi 🐾«la Mimì col Trottola»
mag.1991
-
@thatgiga
La perfezione ❤️
-
@Otttoz ecco finalmente spiegato il famoso detto "abitare nel culo del mondo"!
-
@ibrahim46 @aral
L'Italia è con voi 🍉🍉
-
Il tutto sempre oltre Happy🦋, che è molto oltre il "semplice" journaling...
---
Happy🦋 è il diario della felicità che ho creato e che vorrei compilare tutti i giorni
Agevolo linkino per chi ne vuole sapere di più → https://adriananselmo.it/happy-mappa-gratitudine-felicita/Per domande sono qui!
-
Nuovo "giochino": riassumere i mesi solo con sticker. Sembra tutto così futile, eppure è liberatorio: un modo per dire cose serie in modo leggero.
