Not sure if this is a bug or how D3D works, but my code copies a section of the backbuffer, after DrawAll is called, to a texture, and it works fine until an animated mesh object has shadows enabled.
It then fails in this call of my code:
hRes = pID3DDevice->StretchRect( pBackBuffer, &m_RectSrc, pDestSurface, &m_RectDst, D3DTEXF_NONE );
if ( hRes != D3D_OK )
goto returnFALSE; // If any shadow enabled, returns error is -2005530516
There is an MSDN comment, below, that mentions stencil surfaces, and restricts the use of StretchRect.
Does anyone know how enabling shadows affects the backbuffer such that this might fail, and if there is a workaround?
Additional Restrictions for Depth and Stencil Surfaces
•The source and destination surfaces must be plain depth stencil surfaces (not textures) (see IDirect3DDevice9::CreateDepthStencilSurface).
•Neither of the surfaces can be discardable.
•The entire surface must be copied (that is: sub-rectangle copies are not allowed).
•Format conversion, stretching, and shrinking are not supported.
•StretchRect cannot be called inside of a BeginScene/EndScene pair.
http://msdn.microsoft.com/en-us/library ... s.85).aspx
StretchRect failing when any scene node has shadow enabled
Re: StretchRect failing when any scene node has shadow enabl
The failure is happening only when one of the drawall render passes has an animated mesh with shadow node, and the material set to a z-buffer shader, then restored to the original material render by setting (EMT_SOLID) etc, ignoring the node´s shadow condition, before calling drawall again.
I guess that having called addShadowVolumeSceneNode, rendering is changed such that setting the mesh´s material renderer does not work as normal.
Can anyone give some idea how this should be processed? I.e. To be able to have a shadow animated mesh, then render it with a z-buffer renderer, and then set it back to the same mode it was in after the shadow volume node had been added?
I guess that having called addShadowVolumeSceneNode, rendering is changed such that setting the mesh´s material renderer does not work as normal.
Can anyone give some idea how this should be processed? I.e. To be able to have a shadow animated mesh, then render it with a z-buffer renderer, and then set it back to the same mode it was in after the shadow volume node had been added?
Re: StretchRect failing when any scene node has shadow enabl
Found a solution by modifying DrawAll, so that on rendering to different viewports in different modes, shadow rendering was disabled for all modes part from standard rendering.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Re: StretchRect failing when any scene node has shadow enabl
Can you post the failing example and the fix?
Re: StretchRect failing when any scene node has shadow enabl
Couldn't that be done with a Lighting manager?
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: StretchRect failing when any scene node has shadow enabl
yes, a lighting manager, there is one posted by the links are out, would do enable shadow control.
the problem seemed to be caused by the multiple calls to drawall in one begin-end session, in order to produce a quad view, with one view using a grey-scale shader, and then reverting the objects backs to the previous material render settings.
after a few sets of calls, or frames, that rendered okay, all drawing of shadow-enabled objects messed up, causing the nodes not to render, and a splatter of "shadows" to be rendered - or that's how it looks.
by adding a dword bit-flag to drawAll, and disabling shadows if flag == 0x010, and then only drawing shadows on the full-colour render (render material settings normal), the problem was solved.
for multi-view port rendering, having the flag would allow shadow drawing to be skipped for non-standard renders.
I guess its not a problem for normal use.
I also added another flag, 0x01, to drawAll, to disable the OnAnimate call, as also for multi-port renderings, only one call to onanimate is needed each frame, and calling it multiple times can cause problems under several conditions, dependent on implementation.
the problem seemed to be caused by the multiple calls to drawall in one begin-end session, in order to produce a quad view, with one view using a grey-scale shader, and then reverting the objects backs to the previous material render settings.
after a few sets of calls, or frames, that rendered okay, all drawing of shadow-enabled objects messed up, causing the nodes not to render, and a splatter of "shadows" to be rendered - or that's how it looks.
by adding a dword bit-flag to drawAll, and disabling shadows if flag == 0x010, and then only drawing shadows on the full-colour render (render material settings normal), the problem was solved.
for multi-view port rendering, having the flag would allow shadow drawing to be skipped for non-standard renders.
I guess its not a problem for normal use.
I also added another flag, 0x01, to drawAll, to disable the OnAnimate call, as also for multi-port renderings, only one call to onanimate is needed each frame, and calling it multiple times can cause problems under several conditions, dependent on implementation.