Ogre Version: 2.2.5
Operating System: Windows 10
Render System: GL3Plus
I'm rendering some lines with OT_LINE_LIST in one item and some other lines (with other materials) in another item, but some of them are on top of the other item's lines. So as a result I get flickering lines (probably what you call z-fighting). Now I'd like to have one item always get rendered after the other so that the final appearance of the line is definite.
I found out there are different render queue groups and the groups are rendered one after another. I can set the render queue group ID for my items. But there is no hint on what IDs to use. In earlier versions of Ogre there was a RenderQueueGroupId enum, which is gone in Ogre Next. There is also no hint on what is the default group ID.
I have found a thread where new default groups are suggested and they have been accepted so I assume now the default group is 10, but I think this should be available in a variable somewhere.
And finally: it didn't work. I tried group 20, but nothing changed. Group 100 crashed my application in the render loop. Is it supposed to work this way at all? Would it be a problem if the scene node of the item with the higher group ID were the child of the scene node of the item with the default group?
[2.2.5] Rendering Lines later than other Lines, but are Render Queue Groups still there?
-
- Gnoblar
- Posts: 9
- Joined: Fri Nov 26, 2021 10:52 am
- x 1
-
- Gnoll
- Posts: 619
- Joined: Wed Mar 18, 2009 3:03 am
- x 355
Re: [2.2.5] Rendering Lines later than other Lines, but are Render Queue Groups still there?
I don't think rendering something like that at a separate stage actually does anything in case your material is writing to the depth buffer.
In that case it does not matter if you render a wall in front of a barrel compared to the other way around, the exact same result will happen for both directions of rendering them (when using the depth buffer, which all normal solid objects use).
Though if you render it with depth_write off, then you can probably render them in the order you want them in order to show up in top of each other.
Otherwise, if you want to sort different objects to each other you can use Depth Bias in their material for each line you render. Though I have no idea how to do that in Ogre 2.0+. In Ogre 1.2 it is simply by setting it in the material like this:
https://ogrecave.github.io/ogre/api/lat ... h_005fbias
Also, see this post:
viewtopic.php?t=94099
In that case it does not matter if you render a wall in front of a barrel compared to the other way around, the exact same result will happen for both directions of rendering them (when using the depth buffer, which all normal solid objects use).
Though if you render it with depth_write off, then you can probably render them in the order you want them in order to show up in top of each other.
Otherwise, if you want to sort different objects to each other you can use Depth Bias in their material for each line you render. Though I have no idea how to do that in Ogre 2.0+. In Ogre 1.2 it is simply by setting it in the material like this:
https://ogrecave.github.io/ogre/api/lat ... h_005fbias
Also, see this post:
viewtopic.php?t=94099
My project: https://imagindar.com/
-
- Gnoblar
- Posts: 9
- Joined: Fri Nov 26, 2021 10:52 am
- x 1
Re: [2.2.5] Rendering Lines later than other Lines, but are Render Queue Groups still there?
Thanks for clarifying. Makes sense that rendering order does not affect the fragment order on the depth axis because of the depth buffer.
I found out I can set both the depth bias and the depth write flag in the macroblock of my material.
However, the depth bias values seem to have no effect. I tried values in the range [-1000; 1000] for both the bias constant and the bias slope scale. Maybe it doesn't work with Unlit materials or lines.
The depth write and depth check flags have an effect. It appears I could set up my manual ordering through render queue groups with the depth buffer write or check disabled for some items.
I found out I can set both the depth bias and the depth write flag in the macroblock of my material.
However, the depth bias values seem to have no effect. I tried values in the range [-1000; 1000] for both the bias constant and the bias slope scale. Maybe it doesn't work with Unlit materials or lines.
The depth write and depth check flags have an effect. It appears I could set up my manual ordering through render queue groups with the depth buffer write or check disabled for some items.
-
- Halfling
- Posts: 48
- Joined: Thu Feb 14, 2019 11:27 am
- x 8
Re: [2.2.5] Rendering Lines later than other Lines, but are Render Queue Groups still there?
With OpenGL it should be possible to render lines with offset. In DirectX it's not possible. Sadly that was a dealbreaker for me.
In OpenGL3+ DepthBias is implemented, but seems to be broken.Bias is not applied to any point or line primitives, except for lines drawn in wireframe mode.
https://docs.microsoft.com/en-us/window ... depth-bias
Code: Select all
void GL3PlusRenderSystem::_setDepthBias(float constantBias, float slopeScaleBias)
{
//FIXME glPolygonOffset currently is buggy in GL3+ RS but not GL RS.
...
- dark_sylinc
- OGRE Team Member
- Posts: 5299
- Joined: Sat Jul 21, 2007 4:55 pm
- Location: Buenos Aires, Argentina
- x 1279
- Contact:
Re: [2.2.5] Rendering Lines later than other Lines, but are Render Queue Groups still there?
AFAIK it should be working correctly (I'm unsure for line drawing though).Hilarius86 wrote: ↑Tue Dec 07, 2021 6:02 pm With OpenGL it should be possible to render lines with offset. In DirectX it's not possible. Sadly that was a dealbreaker for me.In OpenGL3+ DepthBias is implemented, but seems to be broken.Bias is not applied to any point or line primitives, except for lines drawn in wireframe mode.
https://docs.microsoft.com/en-us/window ... depth-bias
Code: Select all
void GL3PlusRenderSystem::_setDepthBias(float constantBias, float slopeScaleBias) { //FIXME glPolygonOffset currently is buggy in GL3+ RS but not GL RS. ...
But it's possible reverse_depth is causing depth bias to behave differently from expected.