is this a problem On btDbvt::collideOCL?

Patrizio
Posts: 5
Joined: Tue May 14, 2013 10:34 pm

is this a problem On btDbvt::collideOCL?

Post by Patrizio »

Ok i got my frustum culler on, using Dx11.1 but there is a little problem... it works only if i use btDbvt::collideKDOP...
when i switch to collideOCL it goes through a memmove operation in the function and goes in an assert trying to access a position of the array that doesn't exist :shock:

Seems like a bug to me....


this is what i do when i call the functions:

Code: Select all


m_objectsInFrustum.clear();
	m_objectsInFrustum.resize(0);	// clear() is probably slower


	btDbvtBroadphase*	dbvtBroadphase = (btDbvtBroadphase *)EngineMainWorldHandler.mPhysicsCache;
	
	// Left Frustum Plane
    // Add first column of the matrix to the fourth column
	D3DXPLANE FrustumPlane[6];
	
	FrustumPlane[0].a = cm->view._14 + cm->view._11; 
	FrustumPlane[0].b = cm->view._24 + cm->view._21;
	FrustumPlane[0].c = cm->view._34 + cm->view._31;
	FrustumPlane[0].d = cm->view._44 + cm->view._41;

	// Right Frustum Plane
    // Subtract first column of matrix from the fourth column
	FrustumPlane[1].a = cm->view._14 - cm->view._11; 
	FrustumPlane[1].b = cm->view._24 - cm->view._21;
	FrustumPlane[1].c = cm->view._34 - cm->view._31;
	FrustumPlane[1].d = cm->view._44 - cm->view._41;

	// Top Frustum Plane
    // Subtract second column of matrix from the fourth column
	FrustumPlane[2].a = cm->view._14 - cm->view._12; 
	FrustumPlane[2].b = cm->view._24 - cm->view._22;
	FrustumPlane[2].c = cm->view._34 - cm->view._32;
	FrustumPlane[2].d = cm->view._44 - cm->view._42;

	// Bottom Frustum Plane
    // Add second column of the matrix to the fourth column
	FrustumPlane[3].a = cm->view._14 + cm->view._12;
	FrustumPlane[3].b = cm->view._24 + cm->view._22;
	FrustumPlane[3].c = cm->view._34 + cm->view._32;
	FrustumPlane[3].d = cm->view._44 + cm->view._42;

	// Near Frustum Plane
    // We could add the third column to the fourth column to get the near plane,
    // but we don't have to do this because the third column IS the near plane
	FrustumPlane[4].a = cm->view._13;
	FrustumPlane[4].b = cm->view._23;
	FrustumPlane[4].c = cm->view._33;
	FrustumPlane[4].d = cm->view._43;

	// Far Frustum Plane
    // Subtract third column of matrix from the fourth column
	FrustumPlane[5].a = cm->view._14 - cm->view._13; 
	FrustumPlane[5].b = cm->view._24 - cm->view._23;
	FrustumPlane[5].c = cm->view._34 - cm->view._33;
	FrustumPlane[5].d = cm->view._44 - cm->view._43;

	btVector3 planes_n[6];
	btScalar planes_o[6];

	for(int i = 0; i < 6;i++)
	{
		D3DXPlaneNormalize(&FrustumPlane[i],&FrustumPlane[i]);
		planes_n[i].setX(FrustumPlane[i].a);
		planes_n[i].setY(FrustumPlane[i].b);
		planes_n[i].setZ(FrustumPlane[i].c);
		planes_n[i].setW(1.0f);
 		planes_o[i] = 1.0f;
	}

	btVector3 dir(cm->cameraDirNormalized.x,cm->cameraDirNormalized.y,cm->cameraDirNormalized.z);
	dir.setW(1.0f);

	g_DBFC.m_pCollisionObjectArray = &m_objectsInFrustum;	
	g_DBFC.m_collisionFilterMask = btBroadphaseProxy::AllFilter & ~btBroadphaseProxy::SensorTrigger;//btBroadphaseProxy::AllFilter & ~btBroadphaseProxy::SensorTrigger;	// This won't display sensors...
	g_DBFC.m_additionalCollisionObjectToExclude = NULL;//btCamera;
	btDbvt::collideOCL(dbvtBroadphase->m_sets[1].m_root,planes_n,planes_o,dir,5,g_DBFC);
	btDbvt::collideOCL(dbvtBroadphase->m_sets[0].m_root,planes_n,planes_o,dir,5,g_DBFC);

	//btDbvt::collideKDOP(dbvtBroadphase->m_sets[1].m_root,planes_n,planes_o,5,g_DBFC);
	//btDbvt::collideKDOP(dbvtBroadphase->m_sets[0].m_root,planes_n,planes_o,5,g_DBFC);


here is the "buggy" (Pheraps :lol: ) code in btDbvt.h (lines 1203 - 1206)

Code: Select all


j=nearest(&stack[0],&stock[0],nes[1-q].value,j,stack.size());
							stack.push_back(0);
#if DBVT_USE_MEMMOVE
							memmove(&stack[j+1],&stack[j],sizeof(int)*(stack.size()-j-1));

j returns to be 2 and the stack size is 3 so the memmove access j+1 = (2+1) = third position of an array of size 3 :!:

Maybe that's me doing something weird but still want some clarifications as parameters passed to the function seem all correct to me (and collideKDOP works fine..)
Patrizio
Posts: 5
Joined: Tue May 14, 2013 10:34 pm

Re: is this a problem On btDbvt::collideOCL?

Post by Patrizio »

And another Question :o am i setting up normals and ofset correclty in your opinion? :D
Patrizio
Posts: 5
Joined: Tue May 14, 2013 10:34 pm

Re: is this a problem On btDbvt::collideOCL?

Post by Patrizio »

noone? :(
Patrizio
Posts: 5
Joined: Tue May 14, 2013 10:34 pm

Re: is this a problem On btDbvt::collideOCL?

Post by Patrizio »

I add that my CDTestFramework is not running occlusion culling(crashes as i click on the option...) so it seems like a general problem to me... I'm using version 2.81 revision: 2613