|
|
Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
#395436
02/23/12 15:26
02/23/12 15:26
|
Joined: Jun 2004
Posts: 655
to your left
BoH_Havoc
OP
User
|
OP
User
Joined: Jun 2004
Posts: 655
to your left
|
Yeah well it's that time of the year again: Me asking stupid questions  Before i start with the questioning, little info on what i'm doing: I created a deferred renderer with "full" BRDF support. Local lighting is done by rendering light volumes, directional lighting is applied in a fullscreen quad. To speed up performance i re-use the zbuffer from the gBuffer generation phase for my light volumes. Also, to be able to efficiently do the BRDF stuff i added support for volume textures. I pass a volume texture which contains brdf data to the light shader. By using a material ID from the gBuffer i then access the volume texture and pick the correct lighting model. I have a few questions/problems now: 1.) ENABLE_VIEW vs all other material events: To keep the ZBuffer from the gBuffer stage i use PROCESS_SCREEN/NO_SKY for my light view. Because of that i have to manually clear the view each frame. I do that in a view event like so:
void testMat2Event()
{
if(sc_screen_default == NULL) return; //check if shade-c view is set
switch(render_view)
{
case sc_screen_default.views.deferredLighting:
IDirect3DDevice9* pd3dDevice = (IDirect3DDevice9*)(pd3ddev);
pd3dDevice->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_ARGB(0, 0, 0, 0), 0.0, 0);
//pd3dDevice->Clear(0, NULL, D3DCLEAR_ZBUFFER, D3DCOLOR_ARGB(0, 0, 0, 0), 0.0, 0);
break;
default:
break;
}
}
MATERIAL* testMat2 =
{
flags = ENABLE_VIEW;
event = testMat2Event;
effect = "
technique t1
{
pass p0
{
}
}
";
}
This works very well and i get a nice performance boost out of it. However when using ENABLE_VIEW, my gBuffer gets fucked up. Specifically the material skills for SOME (NOT ALL!) Entities aren't set anymore (like max depth, material ID, etc). It doesn't matter whats inside testMat2Event: As soon as i apply an (empty) event to testMat2, all my materials are buggy. It's always the same entities that are buggy, some only at specific camera angles/position. If i add some more entities to the scene, the buggy entities from before are mostly not buggy anymore but others are instead. I know from my past experience with A6 and A7 that ENABLE_VIEW always caused me nothing but trouble and i always tried to not use it at all. However in order to be able to use pd3dDevice->Clear(..) i have to use it. Question is, what has to be fixed to get this right? Or are there alternative ways to clear the screen? I would really like to understand how ENABLE_VIEW works though as after all these years of using Acknex i still have no idea what really happens when using ENABLE_VIEW and i might have to use it some more in the future to set things up for my deferred renderer. 2.) Using render_d3dxeffect AFTER assigning a different material in a view material event This doesn't work, the volume texture isn't assigned to the shader:
var sc_deferredLighting_mtlRenderEvent()
{
if(my)
{
if(my.alpha < 100)
{
mtl = someOtherMaterial;
LPD3DXEFFECT pEffect = (LPD3DXEFFECT)render_d3dxeffect;
if(pEffect != NULL)
{
pEffect->SetTexture("texBRDFLut", sc_deferredLighting_texBRDFData); //assign volumetric brdf data
pEffect->SetFloat("someVar", someVar); //assign some var to the shader
}
}
}
return 0;
}
This does work:
var sc_deferredLighting_mtlRenderEvent()
{
if(my)
{
if(my.alpha < 100)
{
LPD3DXEFFECT pEffect = (LPD3DXEFFECT)render_d3dxeffect;
if(pEffect != NULL)
{
pEffect->SetTexture("texBRDFLut", sc_deferredLighting_texBRDFData); //assign volumetric brdf data
pEffect->SetFloat("someVar", someVar); //assign some var to the shader
}
}
}
return 0;
}
How can i assign the texture/var to the shader AFTER changing the material? 3.) Re-Using RenderTargets I've red numerous time now that it is common practice to re-use rendertargets between effects to lower video ram overhead. E.g.: User has a general rendertarget with (screen_size.x/2, screen_size.y/2) resolution. The idea is to use the same rendertarget for blurring bloom and then for bluring dof. There would be only temporal data in the rendertarget. The actual compositing wis be done in other rendertargets . The way i would to it is again in a view event like so:
BMAP* genericRT;
.
.
.
var mtlChangeRTsEvent()
{
if(render_view == bloomBlur)
{
bloomBlur.bmap = genericRT;
}
if(render_view == dofBlur)
{
dofBlur.bmap = genericRT;
}
return 0;
}
MATERIAL* mtlChangeRTs =
{
flags = ENABLE_VIEW;
event = mtlChangeRTsEvent;
effect = "
technique t1
{
pass p0
{
}
}
";
}
I haven't tested this yet (due to my problems with ENABLE_VIEW) but this is how i would do it. Is this the right way? Ok that's all the questions i can think of now. Really looking forward to the answers
|
|
|
Re: Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
[Re: BoH_Havoc]
#395764
02/27/12 14:39
02/27/12 14:39
|
Joined: Jul 2000
Posts: 27,986
Frankfurt
jcl
Chief Engineer
|
Chief Engineer
Joined: Jul 2000
Posts: 27,986
Frankfurt
|
http://manual.3dgamestudio.net/material-flags.htmENABLE_VIEW is just a simple flag that lets your event run before view rendering. It should not affect your entity materials or make them buggy. But as far as I see, you've not set a return value in your event function - this might cause randomly some strange behavior of your application, and can be the reason of your problem. Or it's something that you're doing in the event - DX functions often have side effects. In your second code you seem to use the wrong effect pointer. The individual effect pointer of a material is not render_d3dxeffect, but mtl->d3deffect. As to sharing render targets, yes, when the targets have the same size and format, there is no reason why this should not work.
|
|
|
Re: Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
[Re: jcl]
#395823
02/27/12 23:39
02/27/12 23:39
|
Joined: Jun 2004
Posts: 655
to your left
BoH_Havoc
OP
User
|
OP
User
Joined: Jun 2004
Posts: 655
to your left
|
http://manual.3dgamestudio.net/material-flags.htmENABLE_VIEW is just a simple flag that lets your event run before view rendering. It should not affect your entity materials or make them buggy. But as far as I see, you've not set a return value in your event function - this might cause randomly some strange behavior of your application, and can be the reason of your problem. Or it's something that you're doing in the event - DX functions often have side effects. I uploaded a VERY basic test which showcases the problem. I'm not doing anything fancy in that test (no DX stuff, no fancy shader, actually not much other than loading a level and applying a material to a view). Please have a look at it: http://www.project-havoc.com/upload/enable_view_problem.rarthis is how it looks (note the one marine.mdl not being tinted red, this is the bug when setting ENABLE_VIEW)  this is how it should look  In your second code you seem to use the wrong effect pointer. The individual effect pointer of a material is not render_d3dxeffect, but mtl->d3deffect. This isn't supported in A7 (which i'm still using as i can't afford the update from A7 Pro to A8 Pro, plus my teammates from CSiS would also have to get the Upgrade. Sadly this is way above our budget (which is almost 0€)). Are there other ways of accessing the current effect (directly via dx maybe?). Can't think of an other easy way when skimming through atypes.h/avars.h ... If i have to i would also be willing to create a dll for this if it's not TOO much of a hack with 1000s lines of code. The only non-dll solution i see at the moment is implementing my own render loop which i absolutely don't want to. I guess i'd have to implement all the culling stuff myself then (among other things)? Any other hints on how to access the current effect? As to sharing render targets, yes, when the targets have the same size and format, there is no reason why this should not work. Good to know! I'll give it a go once/if i get the above two (main) problems solved. While tinkering some more i got another problem which might not be solvable but i want to make sure: To further boost performance of the deferred lighting part i want to use mixed resolution rendering / inferred lighting. Basically lighting is computed at a lower resolution and then scaled to full size again using bilateral upsampling. Now this was working nice in my old light pre-pass renderer, but i wasn't making use of the zbuffer then. The problem is that the zbuffer won't be rescaled if i render to a view 1/2 screen_size and the zbuffer was generated at full screen_size. Question: Can one rescale the zbuffer to match the new screen_size of a view.stage while keeping the zbuffer's content? I don't think this is possible, but i want to make sure as this would be another nice (optional) performance boost. Thanks for your answers so far! I sure hope to get this sorted out as the current architecture seems really promising. It's way faster than the old light pre-pass renderer while looking a lot better due to different lighting models now possible (Cook Torrance, Oren-Nayar, Ward, etc. All that without any shader branching due to S.T.A.L.K.E.R.-style LUTs).
|
|
|
Re: Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
[Re: BoH_Havoc]
#395838
02/28/12 08:59
02/28/12 08:59
|
Joined: Jul 2000
Posts: 27,986
Frankfurt
jcl
Chief Engineer
|
Chief Engineer
Joined: Jul 2000
Posts: 27,986
Frankfurt
|
Thanks for uploading the sample - I'll look into it in the next days.
The mtl->d3deffect pointer exists also in A7, although it's not documented. Not having A8 is some sort of problem though, as we can only test and fix bugs in the current version, not in old versions. However, although the A8 renderer is different to A7, the ENABLE_VIEW event should to the same, so if there is a bug it should also happen with A8.
|
|
|
Re: Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
[Re: jcl]
#396013
03/01/12 14:16
03/01/12 14:16
|
Joined: Jun 2004
Posts: 655
to your left
BoH_Havoc
OP
User
|
OP
User
Joined: Jun 2004
Posts: 655
to your left
|
Some more info on the ENABLE_VIEW event thing: The bug (if it really is one) only appears when using mtl.skillx. If i manually set values by pEffect->SetFloat there are no problems. Which leads me to my next problem: I would use pEffect->Set... instead of mtl.skillx but i can't get mtl->d3deffect to work in A7 (tried updating the MATERIAL struct in atypes.h (copy paste from A8), but that didn't work). How can i access mtl->d3deffect in A7 or a dll? Also there seems to be a problem with ev->render_map[x] or i'm doing something wrong. This is my dll function (called in ENABLE_RENDER event as shown in the manual):
DLLFUNC HRESULT sc_dll_renderGBuffer(void)
{
// open the scene and get the active D3D device
LPDIRECT3DDEVICE9 pd3dDev = (LPDIRECT3DDEVICE9)draw_begin();
if (!pd3dDev) return error("pd3dDev not available!");
//pd3dDev->Clear(0, NULL, D3DCLEAR_TARGET, D3DCOLOR_ARGB(0, 128, 0, 0), 1.0, 0);
ENTITY* pEntity = (ENTITY*)(ev->me);
BMAP* entSkin1 = (BMAP*)(ev->render_map[0]);
BMAP* entSkin2 = (BMAP*)(ev->render_map[1]);
BMAP* entSkin3 = (BMAP*)(ev->render_map[2]);
BMAP* entSkin4 = (BMAP*)(ev->render_map[3]);
LPD3DXMESH pMesh = (LPD3DXMESH)(ev->render_mesh);
D3DMATERIAL9* pMaterial = (D3DMATERIAL9*)(ev->render_d3dmaterial);
LPD3DXEFFECT pEffect = (LPD3DXEFFECT)(ev->render_d3dxeffect);
//pass texture to shader
//pEffect->SetTexture("texBRDFLut", brdfLUT);
//pEffect->SetTexture("mySkin2",(LPDIRECT3DBASETEXTURE9)(inTexture->d3dtex));
//get first valid technique from effect file
D3DXHANDLE hTech;
pEffect->FindNextValidTechnique(NULL,&hTech);
if (SUCCEEDED(pEffect->SetTechnique(hTech)))
{
//set matrices
pEffect->SetMatrix("matWorld", (D3DXMATRIX*)(ev->matWorld));
pEffect->SetMatrix("matView", (D3DXMATRIX*)(ev->matView));
pEffect->SetMatrix("matProj", (D3DXMATRIX*)(ev->matProj));
//set textures
if(entSkin1) pEffect->SetTexture("entSkin1", (LPDIRECT3DBASETEXTURE9)(entSkin1->d3dtex));
if(entSkin2) pEffect->SetTexture("entSkin2", (LPDIRECT3DBASETEXTURE9)(entSkin2->d3dtex));
if(entSkin3) pEffect->SetTexture("entSkin3", (LPDIRECT3DBASETEXTURE9)(entSkin3->d3dtex));
if(entSkin4) pEffect->SetTexture("entSkin4", (LPDIRECT3DBASETEXTURE9)(entSkin4->d3dtex));
//render the scene using the hlsl effect
UINT cPasses, iPass;
pEffect->Begin(&cPasses, 0);
for (iPass = 0; iPass < cPasses; iPass++)
{
pEffect->BeginPass(iPass);
// Only call CommitChanges if any state changes have happened
// after BeginPass is called
//pEffect->CommitChanges();
// Render the mesh with the applied technique
pMesh->DrawSubset(0);
pEffect->EndPass();
}
pEffect->End();
}
return 0;
}
I can only get entSkin1 to show up in the shader. 2,3 and 4 aren't working. Now if i open up the .mdl in MED and apply the exact same texture from skin1 to skin2, i can access both in the shader. What am i doing wrong here? I do understand that you can't/won't fix bugs in A7 anymore. But maybe there are workarounds for the mentioned points.
|
|
|
Re: Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
[Re: BoH_Havoc]
#396296
03/05/12 13:09
03/05/12 13:09
|
Joined: Jul 2000
Posts: 27,986
Frankfurt
jcl
Chief Engineer
|
Chief Engineer
Joined: Jul 2000
Posts: 27,986
Frankfurt
|
Ok, I looked up the material struct in A7 and the d3deffect was indeed at a different position there. Only in A8 it got a fixed position and was documented. In the last A7 version, d3deffect was 8 bytes after its current position in A8. It could have been at other positions in different A7 versions. As to the ENABLE_VIEW issue, I tested your sample, but the problem does not happen in A8. So it was indeed something A7 specific. As to the entskin problem, I believe they must be really entity skins. For arbitrary images, either define a _bmap texture in the shader: http://manual.3dgamestudio.net/Shader-bmap.htmor use a self-defined texture when you set up effect parameters anyway.
|
|
|
Re: Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
[Re: jcl]
#397381
03/18/12 16:30
03/18/12 16:30
|
Joined: Jun 2004
Posts: 655
to your left
BoH_Havoc
OP
User
|
OP
User
Joined: Jun 2004
Posts: 655
to your left
|
Ok, I looked up the material struct in A7 and the d3deffect was indeed at a different position there. Only in A8 it got a fixed position and was documented. In the last A7 version, d3deffect was 8 bytes after its current position in A8. It could have been at other positions in different A7 versions. I'm using the final A7 version, could you post an example on how to access d3deffect? I guess i just have to change the MATERIAL struct the right way and that should be it (moving the d3deffect pointer one or two positions further to the end in the struct...?)
As to the ENABLE_VIEW issue, I tested your sample, but the problem does not happen in A8. So it was indeed something A7 specific.
Thanks for the info. I created a workaround and now don't have any problems with ENABLE_VIEW anymore. It's a little more user-unfriendly now, but should still be ok to work with for the end user of Shade-C. [edit] Also wanted to mention that the rendertarget sharing works like a charm
Last edited by BoH_Havoc; 03/18/12 16:40.
|
|
|
Re: Some questions: ZBuffer, PROCESS_SCREEN, ENABLE_VIEW
[Re: jcl]
#398023
03/26/12 15:32
03/26/12 15:32
|
Joined: Dec 2008
Posts: 1,218
Germany
Rackscha
Serious User
|
Serious User
Joined: Dec 2008
Posts: 1,218
Germany
|
@JCL i thought the struct definitions like material, entity are there just for documentation and are hard implemented into the compiler o.O(so changing the struct wont change much)
MY Website with news of my projects: (for example my current Muliplayer Bomberman, GenesisPrecompiler for LiteC and TileMaster, an easy to use Tile editor) Sparetime-Development
|
|
|
|
