[SOLVED][Ogre 2.0] scene_pass first/last render queue

[al2950]

There is some behaviour in the cull phase which caught me out, so I was wondering if it is expected behaviour or not.

Lets say I have the following scene passes defined;

Code: Select all

.....
pass render_scene
{
	//Render Main scene objects only
	overlays			off
	rq_first			50
	rq_last			60
}
....
pass render_scene
{
	lod_update_list	off

	//Render Overlays
	rq_first			96
}
......

The problem occurs if I have no overlays (or anything in render queue 96 and above), basically the cull phases has an optimisation which manipulates the requested render queues (SceneManager::_cullPhase01). If I only have objects added to say queue 50 in the above example, queue 50 will be rendered twice, once in the first pass and again in the second.

Admittedly why do I have a pass scene trying to render a queue that does not have any contents.... However thats not the point, I dont think Ogre should be manipulating the requested render queue numbers in this way. From an end user point of view its going to cause some confusion.

Any thoughts!?

[dark_sylinc]

If that script is rendering RQ 50 twice, then it's a bug.

I think you're referring to this piece of code:

Code: Select all

// Quick way of reducing overhead/stress on VisibleObjectsBoundsInfo
// calculation (lastRq can be up to 255)
uint8 realFirstRq= firstRq;
uint8 realLastRq = 0;
{
    ObjectMemoryManagerVec::const_iterator itor = mEntitiesMemoryManagerCulledList.begin();
    ObjectMemoryManagerVec::const_iterator end  = mEntitiesMemoryManagerCulledList.end();
    while( itor != end )
    {
        realFirstRq = std::min<uint8>( realFirstRq, (*itor)->_getTotalRenderQueues() );
        realLastRq  = std::max<uint8>( realLastRq, (*itor)->_getTotalRenderQueues() );
        ++itor;
    }
    realLastRq = std::min( realLastRq, lastRq );
}

and it is indeed, an optimization; which shouldn't alter the end result (IIRC also prevents an out of bounds condition?). Otherwise there's a bug.

The idea is that if you've got an RQ in the range [0; 10) then your requests [50; 60) and [96; max) become [10; 10)
If your RQ is in the range [55; 90) then your requests [50; 60) and [96; max) become [55; 60) and [90; 90) respectively.


I think there's a missing:

Code: Select all

    realFirstRq= std::max( realFirstRq, firstRq ); //<-- Missing line
    realLastRq = std::min( realLastRq, lastRq );
}

Could you confirm if that fixes it?

[al2950]

I am afraid that does not work, I get an assertion because the lastRq < firstRQ. I am not convinced by this logic, as it will still end up trying to render a render queue you have not asked. I agree that doing an intersection between the requested queues and valid queues is a good idea, however with the current logic if no intersection is found it will use the nearest valid queue, which might not be in the range you have requested. So if no intersection is found it should skip the pass.

I appreciate this is an edge case, and users should not be requesting to render RQ's that dont exist, but it will confuse people when they try!!

I will have a closer look into it tomorrow, I got carried away at dissecting the actual render logic including the queues which is more complicated that I thought! I also got hung up on some missing functionality, eg 'scene_depth_range' which is missing for non shadow camera passes. Ill add that back into my fork this week.

[dark_sylinc]

I am afraid that does not work, I get an assertion because the lastRq < firstRQ. I am not convinced by this logic, as it will still end up trying to render a render queue you have not asked. I agree that doing an intersection between the requested queues and valid queues is a good idea, however with the current logic if no intersection is found it will use the nearest valid queue, which might not be in the range you have requested. So if no intersection is found it should skip the pass.

The idea is that firstRq = lastRq skips rendering because it's an empty set: [start, start).
If you hit an assert when firstRq = lastRq, let me know which one is happening.

I appreciate this is an edge case, and users should not be requesting to render RQ's that dont exist, but it will confuse people when they try!!

The compositor should definitely handle this. You just hit a bug.

I will have a closer look into it tomorrow, I got carried away at dissecting the actual render logic including the queues which is more complicated that I thought! I also got hung up on some missing functionality, eg 'scene_depth_range' which is missing for non shadow camera passes. Ill add that back into my fork this week.

Weird. shadow_scene_depth_range works for shadow textures from non-shadow passes, scene_depth_range should work for non shadow passes and shadow passes alike.
I may have broken it inadvertently (there were lots of subtle bugs in 1.x's implementation causing artifacts during shadow mapping).

[al2950]

The idea is that firstRq = lastRq skips rendering because it's an empty set: [start, start).

Ah ok, I was assuming that if you had a RQ set [50:50], then it would render RQ 50. I assumed that already knowing that rq_last is non-inclusive !

So you are trying to clamp the requested RQ's to the valid RQ's range. I have updated the code to do this, see the following commit;
https://bitbucket.org/al2950/ogre-2.0-u ... aed51d64b6
Let me know if thats not what you are trying to do! Your previous fix caused firstRQ > lastRQ in certain cases.

Weird. shadow_scene_depth_range works for shadow textures from non-shadow passes, scene_depth_range should work for non shadow passes and shadow passes alike.
I may have broken it inadvertently (there were lots of subtle bugs in 1.x's implementation causing artifacts during shadow mapping).

I started another post for this issue here;
http://ogre3d.org/forums/viewtopic.php? ... 11#p510711