al2950 wrote: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).