Deferred Renderer Example Question

Jul 18, 2013 at 10:16 PM
Edited Jul 18, 2013 at 10:25 PM
Ive seen in your deferred Renderer Example:
void ViewDeferredRenderer::QueuePreTasks( RendererDX11* pRenderer )
{
    // Call the super class's predraw in order to queue it in the renderer.  The
    // views are processed in a LIFO order, so this will be executed last in both
    // single- or multi-threaded mode.

    if ( m_pEntity != NULL )
    {
        Matrix4f view = m_pEntity->GetView();
        SetViewMatrix( view );
    }

    // Queue this view into the renderer for processing.
    pRenderer->QueueTask( this );

    if ( m_pScene )
    {
        // Run through the graph and pre-render the entities
        m_pScene->GetRoot()->PreRender( pRenderer, VT_PERSPECTIVE );
    }

    // Next we call the predraw method of each of the supporting views.

    SetupViews();
    m_pLightsView->QueuePreTasks( pRenderer );
    m_pGBufferView->QueuePreTasks( pRenderer );
}
My question is, are the lines
if ( m_pScene )
{
    // Run through the graph and pre-render the entities
    m_pScene->GetRoot()->PreRender( pRenderer, VT_PERSPECTIVE );
}
necessary? I think they are redundant. Or not?


A second question i have is:
m_pLightsView->QueuePreTasks( pRenderer );
m_pGBufferView->QueuePreTasks( pRenderer );
The execute order i dont understand:

The QueuePreTasks order is:
  1. LightsView::QueuePreTasks();
  2. GBufferView::QueuePreTasks();
followed by the Render order:
  1. GBufferView::ExecuteTask();
  2. LightsView::ExecuteTask();
so the order of the rendering is wrong!? Confused.

I see that you have inverted the order from the LightsView and GBufferView, when QueuePreTasks them, so that the render order is correct in the end... but why i have to make all QueuePreTasks inverted?
Coordinator
Jul 19, 2013 at 12:57 PM
For the first question, it is indeed necessary to allow any entity that has a SceneRenderTask attached to it to process it in addition to rendering itself in the current SceneRenderTask. The primary example for this is a reflective object that has a dual paraboloid environment map that must be processed prior to its final rendering in the actual scene, so that the object has access to the updated environment maps.

For Q2: The choice of order is done as a stack basis to simplify thinking about what will be processed next. When you have a semi-complicated scene and several ScenRenderTasks sprinkled through it, there is some fairly complex chains of action that I found to be easier to think about in a stack based manner. It is inspired by a depth first traversal of a graph of SceneRenderTasks!

The key thing to remember is that there are multiple types of SceneRenderTasks - the main ones from the camera, and also some private ones that only get initiated by an entity. Sorry for any confusion!

Does that clear things up?
Jul 19, 2013 at 4:50 PM
All right.