[2.1] Are V1_LEGACY objects always rendered first, regardless of render group id? Topic is solved

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


Post Reply
Shimayama
Halfling
Posts: 74
Joined: Sat Apr 25, 2009 2:20 pm
Location: Norway
x 1

[2.1] Are V1_LEGACY objects always rendered first, regardless of render group id?

Post by Shimayama »

1. Is it correct that V1_LEGACY is always rendered first regardless of render queue group id?

2. Is it correct that V1_LEGACY z-depths do not affect V1_FAST (and FAST)?

Our application is cycling render queue group mode as group id increases (0=V1_LEGACY, 1=V1_FAST, 2=FAST, 3=V1_LEGACY, and so on), so that we have full control of draw order independent of legacy or not. Or so I thought. But I just noticed that when I tried to render a V1_LEGACY object that should be front-most, by putting it in a high V1_LEGACY group id, it was always displaying behind V1_FAST objects that had much lower group id.. I then switched to a HLMS Unlit datablock just for test, and then the object correctly displayed in front..

When looking at the implementation of RenderQueue::render, it seems like render queues with mode V1_LEGACY render immediately, while V1_FAST and FAST are added to command buffer and executed after the loop, so that V1_LEGACY objects are always rendered first?

In my test it also seems like the z-depth written by the V1_LEGACY object does not cull the V1_FAST objects that should be behind.. For example I use the following simple LLM to just draw something front most (the V1_FAST objects just use standard PBS datablocks):

Code: Select all

struct VsOut
{
    float4 position : SV_Position;
};

struct PsOut
{
    float4 color : SV_TARGET;
};

VsOut vs(float4 position : POSITION)
{
    VsOut Out;
    Out.position = float4(position.xy, 0.0, 1.0);

    return Out;
}

PsOut ps()
{
    PsOut Out;
    Out.color = float4(1.0, 0.0, 0.0, 1.0);
    return Out;
}

Code: Select all

vertex_program polygonMaskVS hlsl
{
    target vs_4_0
    source polygonMask.hlsl
    entry_point vs
}

fragment_program polygonMaskPS hlsl
{
    target ps_4_0
    source polygonMask.hlsl
    entry_point ps
}

Code: Select all

material polygonMask
{
    technique
    {
        pass
        {
	    cull_hardware none
	    cull_mode none
            depth_write on

            vertex_program_ref polygonMaskVS
            {
            }

            fragment_program_ref polygonMaskPS
            {
            }
        }
    }
}
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [2.1] Are V1_LEGACY objects always rendered first, regardless of render group id?

Post by dark_sylinc »

That is correct.

V1_LEGACY executes directly, thus it messes up with the order of the other groups, among other potential side effects.

I don't remember if the documentation was updated correctly (or if the change was reflected more clearly), but it's been years now that V1_FAST can process low level materials too!

Because of this annoying issue with V1_LEGACY that you're mentioning, it is that I implemented V1_FAST for low level materials as well. Obscure functionality from Ogre 1.x in low level materials may not be accessible though (such as "global instancing" which is a very obscure functionality, I don't think it's even documented anywhere).
The reason we now keep V1_LEGACY is if your low level material happens to need something really obscure.

So you should be able to run those materials like the one you posted in V1_FAST just fine.

If you actually require V1_LEGACY and controlling order is paramount, you can split these passes into their own pass_scene. Not elegant, not efficient, but it will do the job (that's basically the idea behind legacy... to get it to work, regardless of performance or elegance).
Shimayama wrote: Sun Mar 11, 2018 6:12 pm In my test it also seems like the z-depth written by the V1_LEGACY object does not cull the V1_FAST objects that should be behind.. For example I use the following simple LLM to just draw something front most (the V1_FAST objects just use standard PBS datablocks):
That does not sound right. Either there's an Ogre bug, a bug on your code, or you're simply misinterpreting what you're observing (i.e. check with RenderDoc).

Cheers
Shimayama
Halfling
Posts: 74
Joined: Sat Apr 25, 2009 2:20 pm
Location: Norway
x 1

Re: [2.1] Are V1_LEGACY objects always rendered first, regardless of render group id?

Post by Shimayama »

dark_sylinc wrote: Mon Mar 12, 2018 2:33 am So you should be able to run those materials like the one you posted in V1_FAST just fine.
Ok. That sounds great. Then our application probably won't need V1_LEGACY at all.

I just moved the object to a V1_FAST group and now it displays correctly in front. Thx :)
dark_sylinc wrote: Mon Mar 12, 2018 2:33 am
Shimayama wrote: Sun Mar 11, 2018 6:12 pm In my test it also seems like the z-depth written by the V1_LEGACY object does not cull the V1_FAST objects that should be behind.. For example I use the following simple LLM to just draw something front most (the V1_FAST objects just use standard PBS datablocks):
That does not sound right. Either there's an Ogre bug, a bug on your code, or you're simply misinterpreting what you're observing (i.e. check with RenderDoc).
I was surprised by that too, but quite sure of what I experienced. I guess I won't spend any time on it though now that I can do V1_FAST + LLM instead. Though, just for info:
  • I have a test with the LLM object in group 36 which is V1_LEGACY, and it displays incorrectly behind objects in lower V1_FAST groups.
  • If I do just one change; put the object in group 34 which is V1_FAST, then it displays correctly in front.
Post Reply