Vulkan - Nuklear

Started by ealrann, November 19, 2018, 12:00:21

Previous topic - Next topic



I'm trying to use the Nuklear binding, and I have few questions:
- In the
// null texture setup
int nullTexID = glGenTextures();

With vulkan, no glGenTextures. What should I put into the field ID (int)? I thought of an Image ID, but it's a long.

- Hard to find any code about Nuklear and Vulkan, but there is this one: He's using nk_font_atlas, but I don't see anything like that in the LWJGL binding, maybe I missed something?



I'm not sure about the null texture.

LWJGL builds nuklear without NK_INCLUDE_FONT_BAKING, which means that the nk_font_atlas functionality is not available. Including it would bundle stb_truetype & stb_rect_pack with nuklear, but those are already available in LWJGL's stb bindings. See the GLFWDemo (lines 141-240) for an example of how you can implement the same functionality.


Hello Spasi,

Yeah, actually I try to convert the GLFWDemo you speak about. But same question with the default_font: line 238:
.texture(it -> it

fontTexID comes from:
int fontTexID = glGenTextures();

In Vulkan World, no glGenTextures, and IDs are long, not int; so I'm not sure what to use for this field.

So, for now I replace that by:
.texture(it -> it

Still have a black screen for now haha.


Right, nk_handle is a union, you can use either id or ptr to store a handle. So, ptr is fine for a Vulkan image id.

As for why you get a black screen, note that Nuklear does not perform any rendering. You iterate the generated list of NkDrawCommand and it's up to you do the right OpenGL or Vulkan calls. For example, at line 606 of the existing demo, there's a glBindTexture(GL_TEXTURE_2D, cmd.texture().id()) call. In a Vulkan renderer, you'd use cmd.texture().ptr() instead.


Thanks for your answer.

Yep, I saw that. I already have a functional vulkan pipeline, and I converted the opengl calls into vulkan ones. I just missed something I guess.

I'll share the code if I make it works.


I finally made it work. Here the code around that if somebody is interested (but there is an heavy abstraction behind that).

The main point with vulkan is: you need to know what texture you will have to use before drawing, to prepare your descriptorSets. You cannot just bind what nuklearCmd.texture() returns during the draw (as you would do in OpenGL).
What I finally understood, is that the nuklearCmd.texture() are simply the nullTexture, and the fontTexture (maybe more for images, but I don't use them for now), so I just built these two descriptors when I allocate the graphic pipeline.

I have to say, if you could unlock the bake part of nuklear, it would be great  ;D. But I understand that you don't want the stb's nuklear dependencies in LWJGL (and I prefer LWJGL stays light).