Skip to content

feat: implements support for specifying depth order of drawing commands #33

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

simsaens
Copy link
Contributor

@simsaens simsaens commented Aug 7, 2024

We use vg-renderer extensively in our project and have found the need to specify a depth order (which gets passed through to bgfx::submit as depth). This is used to, for example, render text on top of UI components or just layer different shapes in a specified ordering

This PR attempts to add a public API to vg-renderer to specify the depth ordering state of the renderer. I'm unsure about some things:

  • Should the function be called depthOrder or setDepthOrder (I went with the former, opting for brevity)
  • Should it be a state of DrawCommand, or is it sufficient to keep the depth order in State? Again, I went with the former
  • If depthOrder does live in DrawCommand, then do we need to m_ForceNewDrawCommand when ctxPopState runs if the depth order is different?
  • If depthOrder should live exclusively in State, then is it OK to getState(ctx) from the end(...) function in order to read the depthOrder for bgfx::submit?

I am happy to change anything (naming, etc) to match convention here

@jdryg
Copy link
Owner

jdryg commented Aug 8, 2024

Thanks for the PR and sorry for the delayed reply.

Unfortunately I cannot merge this PR atm because I feel this should be a feature implemented in a different way.
Regarding your questions:

  1. Between the two naming choices you mentioned I'd prefer setDepthOrder().
  2. Both. The current depth order should be kept in State (so it'll be affected by push/pop) and copied into the DrawCommand's struct. The user does not know (and should not care) when a new DrawCommand is created.
  3. Yes.
  4. I didn't understand the question.

In other words, I'd implement it similar to how the scissor rect is currently handled.

May I ask how depth order can help with the "text on top of UI widget" case? Is your whole UI a single layer (background + text)? If it has multiple layers (e.g. overlapping windows), do you plan to increase the depth order for every UI layer?

My approach to this would be a bit different (and a bit more complicated). IMO the API should be something like:

vg::beginLayer(1)
// Draw shapes to layer 1 here
vg::endLayer() // Automatically revert to layer 0
// Draw shapes to layer 0 here
vg::beginLayer(2)
// Draw shapes to layer 2 here
vg::endLayer()

AFAIR, I tried implementing something like that in the layers branch but I never finished it. Unfortunately I don't remember the details.

Having said all that, I don't currently use this version of the library in my own projects. I use a stripped down version based on c99 branch. AFAIK @bkaradzic plans on integrating vg-renderer into bgfx at some point so it might be better if you tried porting your changes to his branch once it's ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants