Floor renders slower than ceiling

This topic is 3984 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

The floor actually renders slower than all other textures combined in a (extremely simple) scene. Even though its so simple, this one polygon (2 triangles, and approximately the same size as the ceiling and walls) should not be 10-15 frames slower than the other 14 or so faces combined (10-15 frames is significant because the whole scene renders about 30 frames per second) I'm absolutely perplexed by this.. I've done everything to try to make them render at around the same rate to see what the problem is, including simplifying the shader so that it basically only outputs the diffuse texture, change the tangent/bitangent/normals to a constant value, changing the diffuse texture, changing the normal texture.. nothing works! I can't figure it out... so i'm looking for some help. What should I try to see what is causing this? Any ideas? What should I post, code? screenshots? I'll start with some rendering code (deferred shader by the way).. to render the bsp:
	D3DXMATRIX matWorldViewProj = ren->m_worldMatrix * ren->m_viewMatrix * ren->m_projMatrix;

s_pD3DDevice->SetStreamSource( 0, m_pVertexBuffer, 0, sizeof(BSPDXVERTEX) );
s_pD3DDevice->SetFVF( NULL );
s_pD3DDevice->SetVertexDeclaration( m_pVertDecl );

D3DXVECTOR4 eyePos ( ren->m_viewPos[ 0 ], ren->m_viewPos[ 1 ], ren->m_viewPos[ 2 ], 1.0f );
m_pRenEffect->SetVector( "eyePos", &eyePos );

UINT nPasses;

for( int i = 0; i < m_nTextureCount; i++ )
{
bool lastVisible = false;
int start = 0, primCount = 0;

if( !m_pTexIndexBuffer[ i ].m_pIndexBuffer || !m_pTextureBuffer[ i ].texture )
continue;

s_pD3DDevice->SetIndices( m_pTexIndexBuffer[ i ].m_pIndexBuffer );

m_pRenEffect->SetTexture( "diffuseTexture", m_pTextureBuffer[ i ].texture );
if( m_pTextureBuffer[ i ].flags & 2 )
{
m_pRenEffect->SetTechnique( "BSPtoMRT_NormalMap" );
m_pRenEffect->SetTexture( "normalTexture", m_pTextureBuffer[ i ].normalmap );
}
else
{
m_pRenEffect->SetTechnique( "BSPtoMRT_NoNormalMap" );
}

m_pRenEffect->SetInt( "iStencRef", ren->iStencCount );
m_pRenEffect->Begin( &nPasses, 0 );
for( UINT p = 0; p < nPasses; p++ )
{
m_pRenEffect->BeginPass( p );

for( int j = 0; j < m_nClusterCount; j++ )
{
if( m_pTexIndexBuffer[ i ].nPrimCount[ j ] == 0 )
continue;

bool thisVisible = true;

if( thisVisible )
{
if( !lastVisible )
{
start = m_pTexIndexBuffer[ i ].nStartIndex[ j ];
}
primCount += m_pTexIndexBuffer[ i ].nPrimCount[ j ];
}
else
{
if( lastVisible )
{
s_pD3DDevice->DrawIndexedPrimitive( D3DPT_TRIANGLELIST, 0, 0, m_nVertexCount, start, primCount );
}
primCount = 0;
}
lastVisible = thisVisible;
}
if( lastVisible )
{
s_pD3DDevice->DrawIndexedPrimitive( D3DPT_TRIANGLELIST, 0, 0, m_nVertexCount, start, primCount );
}

m_pRenEffect->EndPass( );
}
m_pRenEffect->End( );

}


struct VS_INPUT {
float4 vPos : POSITION;
float3 vNorm : NORMAL;
float2 vTex : TEXCOORD0;
float3 vTan : TEXCOORD1;
float3 vBin : TEXCOORD2;
};

struct VS_OUTPUT2 {
float4 pPos : POSITION;
float4 pPos2 : TEXCOORD0;
float2 pTex : TEXCOORD1;
float3 pTan : TEXCOORD2;
float3 pBin : TEXCOORD3;
float3 pNorm : TEXCOORD4;
float3 pEyevec : TEXCOORD5;
};

struct PS_MRT_OUTPUT {
float4 Color0 : COLOR0;
float4 Color1 : COLOR1;
float4 Color2 : COLOR2;
float4 Color3 : COLOR3;
};

VS_OUTPUT2 VS_NormalMap( VS_INPUT In )
{
VS_OUTPUT2 Out;
float4 tPos = mul( In.vPos, matWorldViewProj );
Out.pPos = tPos;
Out.pPos2 = In.vPos;

Out.pEyevec = In.vPos.xyz - eyePos.xyz;

Out.pTan = In.vTan;
Out.pBin = In.vBin;
Out.pNorm = In.vNorm;

Out.pTex = In.vTex;
return Out;
}

PS_MRT_OUTPUT PS_NormalMap( VS_OUTPUT2 In )
{
PS_MRT_OUTPUT Out;

half4 diffuseTex = tex2D( diffuseSampler, In.pTex );

half3 eyeVec = normalize( In.pEyevec );
half2 offset;
offset.x = dot( eyeVec, In.pTan );
offset.y = dot( eyeVec, In.pBin );
offset = offset * diffuseTex.w * 0.03125;

diffuseTex = tex2D( diffuseSampler, In.pTex + offset );
half3 normalTex = tex2D( normalSampler, In.pTex + offset ) * 2.0 - 1.0;

float3x3 TBN;
TBN[ 0 ] = In.pTan;
TBN[ 1 ] = In.pBin;
TBN[ 2 ] = In.pNorm;
half3 norm = mul( normalTex, TBN );

Out.Color0 = diffuseTex; //albedo
Out.Color1 = float4( norm * 0.5 + 0.5, 0.0 ); //normal
Out.Color2 = float4( In.pPos2.z, 0.0, 0.0, 0.0 ); //position(z)
Out.Color3 = float4( In.pPos2.x, In.pPos2.y, 0.0, 0.0 ); //position(x,y)
return Out;
}


Edit: Here's a picture. The top ones are the original problem bsp. The bottom right is the one I just made and is nearly identical (crate and white wall were taken out) which has no slowdown. Bottom left is a totally different BSP with huge huge slowdown. Any ideas would be great [Edited by - MilfredCubicleX on March 22, 2007 1:13:15 PM]

Share on other sites
Well, without looking at the code, it occurs to me to wonder whether you have V-synch enabled, based on the numbers that you give. It could be that your frame rate is, with the ceiling rendering in place, dropping below the threshold for the next V-synch step down, and being set to around 15fps instead of 30fps, when it could possibly, if I'm correct, be running at a higher rate with V-synch off.

Share on other sites
Sorry for not mentioning, vsync is disabled. I disabled it, also thinking it could be part of the problem. I just find it weird that it's this one face, and the others are fine.

Share on other sites
In which case I don't know, I'm afraid - my apologies.

Share on other sites
Perhaps it is to do with clipping. Try moving the viewpoint around.

Share on other sites
I've tried it moving around, but as long as the floor is in the field of view, it lags very noticeably more than when its not in the field of view.

Share on other sites
What's your texture resolution on the floor? I could see some possible slowdowns if you were using something big, like a 2048x2048 texture (tiled).

Share on other sites
Every texture is 256x256 and the wall, ceiling, and floor texture are textured about 3 times each.

I feel like this could be some sort of cache trashing I don't know about.

Share on other sites

How does performance change if you take the other stuff out and then look at the floor?

Share on other sites
did you try using the exact same texture (say from the ceiling) for all surfaces?

Share on other sites
Quote:
 Original post by jbarcz1How does performance change if you take the other stuff out and then look at the floor?

The floor, rendered by itself, is slower than all other faces rendered together.

Quote:
 Original post by lonesockdid you try using the exact same texture (say from the ceiling) for all surfaces?

Yep, to no avail.

I just made another bsp real quick, almost identical to the one that is exhibiting the problem but even simpler (floor, ceiling, four walls) and the floor problem is gone. However, I have another bsp which is much different from these two, but it exhibits the floor problem.

Here's a picture. The top ones are the original problem bsp. The bottom right is the one I just made which has no slowdown. Bottom left is a totally different BSP with huge huge slowdown.

[Edited by - MilfredCubicleX on March 22, 2007 1:41:02 PM]

Share on other sites
That behaviour would seem to suggest some issue with your bsp rendering code.
Maybe it is not properly handling complex bsp situations; could it be rendering the floor plane more than once per frame?

I once had an analogous problem with my Portal Engine, where the render pass would end up doing cycles for some situations and end up rendering stuff more than once...

Share on other sites
Quote:
 Original post by haphazardlynamedThat behaviour would seem to suggest some issue with your bsp rendering code.Maybe it is not properly handling complex bsp situations; could it be rendering the floor plane more than once per frame?I once had an analogous problem with my Portal Engine, where the render pass would end up doing cycles for some situations and end up rendering stuff more than once...

Hmm, you may be right, the primitive counts seem way off... I will check this out (after physics class)

Yeah.. 100 vertices... something strange.

Ok, i added a light and spawn point to the new scene that didn't have slowdown (but did have an obscene amount of vertices) and the vertices were reduced to 24. However the other bsps have lights and I'm get an obscene amount of vertices for both. Even with only 24 vertices i'm getting the strange floor effect.

It seems that the visible clusters contain duplicate vertices, hence the overdraw..

[Edited by - MilfredCubicleX on March 22, 2007 11:57:01 PM]

Share on other sites
Alright, for the extra simple scene, I sent all the vertices to the debug output. To render, there is one index buffer per texture, and the buffer is sorted by visible clusters. The problem is that each cluster holds the same vertex information as the rest of the clusters..

Here are the vertices:
Vertices: 24texture: 0 cluster: 0--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 0--184, -64, 184184, -64, -184184, -64, 184texture: 0 cluster: 1--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 1--184, -64, 184184, -64, -184184, -64, 184texture: 0 cluster: 2--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 2--184, -64, 184184, -64, -184184, -64, 184texture: 0 cluster: 3--184, -64, -184184, -64, -184-184, -64, 184texture: 0 cluster: 3--184, -64, 184184, -64, -184184, -64, 184texture: 1 cluster: 0--184, 128, -184-184, -64, -184-184, 128, 184texture: 1 cluster: 0--184, 128, 184-184, -64, -184-184, -64, 184texture: 1 cluster: 0-184, -64, 184184, 128, 184-184, -64, 184texture: 1 cluster: 0--184, -64, 184184, 128, 184-184, 128, 184texture: 1 cluster: 1--184, 128, -184-184, -64, -184-184, 128, 184texture: 1 cluster: 1--184, 128, 184-184, -64, -184-184, -64, 184texture: 1 cluster: 1--184, 128, -184184, 128, -184-184, -64, -184texture: 1 cluster: 1--184, -64, -184184, 128, -184184, -64, -184texture: 1 cluster: 2-184, -64, -184184, 128, -184184, -64, 184texture: 1 cluster: 2-184, -64, 184184, 128, -184184, 128, 184texture: 1 cluster: 2-184, -64, 184184, 128, 184-184, -64, 184texture: 1 cluster: 2--184, -64, 184184, 128, 184-184, 128, 184texture: 1 cluster: 3-184, -64, -184184, 128, -184184, -64, 184texture: 1 cluster: 3-184, -64, 184184, 128, -184184, 128, 184texture: 1 cluster: 3--184, 128, -184184, 128, -184-184, -64, -184texture: 1 cluster: 3--184, -64, -184184, 128, -184184, -64, -184texture: 2 cluster: 0-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 0--184, 128, 184184, 128, -184-184, 128, -184texture: 2 cluster: 1-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 1--184, 128, 184184, 128, -184-184, 128, -184texture: 2 cluster: 2-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 2--184, 128, 184184, 128, -184-184, 128, -184texture: 2 cluster: 3-184, 128, 184184, 128, -184-184, 128, 184texture: 2 cluster: 3--184, 128, 184184, 128, -184-184, 128, -184

You can see that the vertices are duplicated over each cluster.. but i don't know why this is. Maybe someone who has run into this duplicate vertices problem can help me.

Share on other sites
No Clue
You've lost us, thats getting way too far into the specifics of your code.
Not even sure what you're building...

Share on other sites
Quote:
 Original post by haphazardlynamedNo ClueYou've lost us, thats getting way too far into the specifics of your code.Not even sure what you're building...

oh well, i'll figure it out eventually

Share on other sites
What I mean is.
That in your prior post you've only posted a list of debug output from your program.

We can't tell you anything about what that means, because we don't know anything about the program that outputted it.

Maybe you could try describing what the program does...
then that list of vertices and clusters(whats a cluster?) might mean something to everyone else here...

Share on other sites
Uhh sorry, the only part of the program i'm trying to debug is the renderer. The part that is behaving strangely is the bsp rendering. The debug output was from where the program takes BSP information from a quake 3 bsp file, and turns it into a format DirectX can use. I outputted all of the vertex information (namely, the vertices that make up all faces in the BSP) sorted by texture and cluster. To determine visibility, BSP faces are grouped into clusters. There is then a lookup table in the BSP to determine what clusters are visible at other clusters. Much to my dismay, there are many duplicate vertices (and therefore duplicate triangles) in the BSP file. I guess my possibilities are a) the BSP isn't getting compiled correctly (doubt it, i'm using q3radiant, which was what IDSoftware used) b) I'm not loading the information correctly or c) I don't fully understand the file format

Whoops, turns out the answer was c) I don't fully understand the file format.
"Because a face may protrude out of the leaf, the same face may be in multiple leaves." I thought they were tessellated. Problem solved..

[Edited by - MilfredCubicleX on March 26, 2007 2:09:19 PM]