Order of rendering - am I missing something?
Posted: 07 Aug 2019, 20:08
Hello,
I just recently integrated NoesisGUI into my engine, using custon OpenGL renderer which is pretty solid and works with GL4.6. I noticed that Noesis doesn't give much control over geometry at all, instead it sends full data to a mapped buffer (no control over how data is kept in memory) which is fine, as I was able to easily plug it into my ring buffers and it works fine. Then it issues draw calls via DrawBatch(). So far I only implemented simple two types of shaders - solid color and linear gradient. It works well, but today I got, I can say it, trolled by the gui, because on some runs I could only see the background gradient that I set, and sometimes I could see the other GUI elements. Here is how it looked: then with other elements (animating and dependent on each other via ChangePropertyAction): I was not sure what's going on until I got an idea - I removed the background gradient and put a gradient filled rectangle and found out that from time to time the rectangle would appear in front of my other elements, despite it being "Send to back". I'm new to XAML and maybe I'm doing something wrong - right now it seems that this is random so sometimes it would appear above, sometimes below. I also noticed that SendToBack does not add any XAML property, so maybe it's just purely Blend-based functionality that has no meaning in how it's rendered? I see there is ZIndex property - should I be using this and if so, how does that split the rendering batches, because I assume that for geometry to be rendered on top of each other, this should be split into separate, ordered draw calls?
Worth noting: I'm not sure but I could not reproduce it for solid rectangle, only gradient-filled. Maybe I was just lucky as it seems random - sometimes it always covers, sometimes it's 50/50. But I never got the solid one to appear in front... Probably due to it being separate draw call from gradient and the ordering of the calls...
Thanks for help, I really like how Noesis looks so far, looking forward to implementing it fully :)
I just recently integrated NoesisGUI into my engine, using custon OpenGL renderer which is pretty solid and works with GL4.6. I noticed that Noesis doesn't give much control over geometry at all, instead it sends full data to a mapped buffer (no control over how data is kept in memory) which is fine, as I was able to easily plug it into my ring buffers and it works fine. Then it issues draw calls via DrawBatch(). So far I only implemented simple two types of shaders - solid color and linear gradient. It works well, but today I got, I can say it, trolled by the gui, because on some runs I could only see the background gradient that I set, and sometimes I could see the other GUI elements. Here is how it looked: then with other elements (animating and dependent on each other via ChangePropertyAction): I was not sure what's going on until I got an idea - I removed the background gradient and put a gradient filled rectangle and found out that from time to time the rectangle would appear in front of my other elements, despite it being "Send to back". I'm new to XAML and maybe I'm doing something wrong - right now it seems that this is random so sometimes it would appear above, sometimes below. I also noticed that SendToBack does not add any XAML property, so maybe it's just purely Blend-based functionality that has no meaning in how it's rendered? I see there is ZIndex property - should I be using this and if so, how does that split the rendering batches, because I assume that for geometry to be rendered on top of each other, this should be split into separate, ordered draw calls?
Worth noting: I'm not sure but I could not reproduce it for solid rectangle, only gradient-filled. Maybe I was just lucky as it seems random - sometimes it always covers, sometimes it's 50/50. But I never got the solid one to appear in front... Probably due to it being separate draw call from gradient and the ordering of the calls...
Thanks for help, I really like how Noesis looks so far, looking forward to implementing it fully :)