Add an initial UI to Hypermine #391
Conversation
The second should do, blending always happens as if draws were executed in order. However, if we write a depth of 1 for fragments occupied by UI, the first subpass might also do just fine.
This would be a straightforward PR to yakui. Alternatively, we could migrate hypermine to dynamic rendering, which doesn't have subpasses, but that would take more work.
Transparency is a huge can of worms no matter what. I suggest we plan to avoid it entirely. Even if we do want glass, we can do just fine with opaque dust/dirt + additively-blended reflections, IMO.
Sounds like you're probably calling it too early. It probably only happens once because that's the only time yakui needs to do a transfer so far. |
I'll try the second one for now, then. Text especially benefits from anti-aliasing, and that could interact weirdly with fog, since that involves transparency. One issue with the second one is that it seems to use the alpha channel in an unusual way, with 0 being opaque and 1 being invisible in most places, which may confuse yakui. (EDIT: It didn't confuse yakui as much as I thought it would. It seems like the second subpass is totally viable, as the text looks perfectly fine to me).
I'll go ahead with the PR, as it seems easy enough (as dynamic rendering seems beyond the scope of what to work on at the moment).
This seems like something we could easily change our minds on at some point (to support water or stained glass, for example), but fog would be the least of our worries, so I agree with ignoring it entirely for now. Preparing for transparency seems like a cousin of premature optimization now that I think about it.
I had copied it from the yakui_vulkan demo, which calls |
|
Created SecondHalfGames/yakui#154 to hopefully address the subpass issue. I've tested it locally, and it fixes that issue in Hypermine. |
|
I was able to get rid of the validation error by calling
This suggests that Hypermine has up to 2 concurrent frames in flight, which makes sense in retrospect, although I don't remember how to confirm that. |
hypermine/client/src/graphics/draw.rs Lines 55 to 56 in 50cf2ff |
|
Oh, right. Thanks! |
|
Thanks for the help! Things seem to be going a lot more smoothly now, so I'll go ahead and close this draft in favor of a fresh PR when I have something ready. |
|
When I change which text displays on the screen (by switching material), sometimes, I get the following stack trace, and the game crashes (I can reliably get this to happen if I'm generating terrain at the same time): Out of all of this, these four lines seem the most relevant:
None of these validation errors appear until the game crashes. |
|
With some more experimentation, I got this validation error without crashing: |
|
I'll use this comment to document things I've tried to fix it:
|
|
I reopened this PR because otherwise, the latest changes on the "yakui-wip" branch won't show up, which would cause problems for anyone trying to help. |
|
Closing this PR again, as I now have a new PR (#395) that's ready to be upgraded from a draft to a regular PR as soon as an upstream fix to yakui is applied. Any further changes to the code will be made to that PR. |
This is currently a draft, as there are two issues:
Since Hypermine has two subpasses (the second one for fog), to ensure the UI gets drawn on top of everything and is unaffected by fog, the UI needs to be in the second subpass or possibly a third one. Currently, Yakui doesn't seem to support rendering anywhere except the first subpass. (It creates avk::GraphicsPipelineCreateInfostruct and keeps thesubpassfield in that struct as its default.)I get the following validation error on the second call to
draw::draw(but strangely, no frames before or after):Validation Error: [ VUID-vkFreeMemory-memory-00677 ] | MessageID = 0x485c8ea2 | vkFreeMemory(): can't be called on VkDeviceMemory 0xeeeba00000000288[] that is currently in use by VkBuffer 0x8f6f470000000287[]. The Vulkan spec states: All submitted commands that refer to memory (via images or buffers) must have completed execution (https://vulkan.lunarg.com/doc/view/1.3.280.0/windows/1.3-extensions/vkspec.html#VUID-vkFreeMemory-memory-00677) id=VUID-vkFreeMemory-memory-00677 number=1214025378 queue_labels= cmd_labels= objects=. The error seems to trigger when I calltransfers_finished. I haven't fully looked into the root cause yet, so it could just be a simple mistake on my part, as I've mainly been blindly following theyakui-vulkanexample.Note that long-term, I'm not sure whether we can keep putting fog in a separate subpass, since that likely wouldn't work properly if there are any transparent objects in the scene.
(Fixed)
If I ignore the fog and just render the UI after everything else in the first subpass, the letters are replaced with their bounding boxes filled in with the sky color. If I turn the fog off, everything works.I would like to keep this PR as a draft until we have the following (which I may file as a separate PR, closing this one):