• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
lipsryme

Is my frustum culling slow ?

45 posts in this topic

Doing frustum culling on 10.000 objects it takes about 0.85ms...is that slow/fast ?

 

I'm using AABBs to frustum cull my objects.

See code here:

 

bool RendererD3D11::FrustumCull(SceneEntityDescription* entity,
								XMFLOAT4* frustumPlanes)
{
	// If there even was a rejection last time
	if(entity->lastRejectedFrustumPlane != 999999)
	{
		// Check last rejected planeId first
		XMVECTOR planeNormal = XMVectorSet(frustumPlanes[entity->lastRejectedFrustumPlane].x, frustumPlanes[entity->lastRejectedFrustumPlane].y,
			frustumPlanes[entity->lastRejectedFrustumPlane].z, 0.0f);

		float planeConstant = frustumPlanes[entity->lastRejectedFrustumPlane].w;

		// Check each axis (x, y, z) to get the AABB vertex furthest away from the direction
		// the plane is facing (plane normal)
		XMFLOAT3 axisVert;
		XMFLOAT3 aabb_min = this->contentManager->GetPrimitiveFromPool(entity->ID)->GetBoundingVolume()->Min();
		XMFLOAT3 aabb_max = this->contentManager->GetPrimitiveFromPool(entity->ID)->GetBoundingVolume()->Max();
		XMFLOAT3 objPos = entity->worldPosition;

		// x-axis
		if(frustumPlanes[entity->lastRejectedFrustumPlane].x < 0.0f)
		{
			axisVert.x = aabb_min.x + objPos.x; // min x + obj position's x
		}
		else
		{
			axisVert.x = aabb_max.x + objPos.x; // max x + obj position's x
		}

		// y-axis
		if(frustumPlanes[entity->lastRejectedFrustumPlane].y < 0.0f)
		{
			axisVert.y = aabb_min.y + objPos.y; // min y + obj position's y
		}
		else
		{
			axisVert.y = aabb_max.y + objPos.y; // max y + obj position's y
		}

		// z-axis
		if(frustumPlanes[entity->lastRejectedFrustumPlane].z < 0.0f)
		{
			axisVert.z = aabb_min.z + objPos.z; // min z + obj position's z
		}
		else
		{
			axisVert.z = aabb_max.z + objPos.z; // min z + obj position's z
		}

		// Now we get the signed distance from the AABB's vertex that's furthest down the frustum planes normal,
		// and if the signed distance is negative, then the entire bounding box is behind the frustum plane, which means
		// that it should be culled
		if(XMVectorGetX(XMVector3Dot(planeNormal, XMLoadFloat3(&axisVert))) + planeConstant < 0.0f)
		{
			return true;
		}
	}
	

	// Loop through each frustum plane
	for(int planeID = 0; planeID < 6; ++planeID)
	{
		if(entity->lastRejectedFrustumPlane != 999999)
		{
			if(planeID == entity->lastRejectedFrustumPlane)
			{
				// skip last rejected frustum plane since we've checked it before this loop
				continue;
			}
		}


		XMVECTOR planeNormal = XMVectorSet(frustumPlanes[planeID].x, frustumPlanes[planeID].y,
										   frustumPlanes[planeID].z, 0.0f);

		float planeConstant = frustumPlanes[planeID].w;

		// Check each axis (x, y, z) to get the AABB vertex furthest away from the direction
		// the plane is facing (plane normal)
		XMFLOAT3 axisVert;
		XMFLOAT3 aabb_min = this->contentManager->GetPrimitiveFromPool(entity->ID)->GetBoundingVolume()->Min();
		XMFLOAT3 aabb_max = this->contentManager->GetPrimitiveFromPool(entity->ID)->GetBoundingVolume()->Max();
		XMFLOAT3 objPos = entity->worldPosition;

		// x-axis
		if(frustumPlanes[planeID].x < 0.0f)
		{
			axisVert.x = aabb_min.x + objPos.x; // min x + obj position's x
		}
		else
		{
			axisVert.x = aabb_max.x + objPos.x; // max x + obj position's x
		}

		// y-axis
		if(frustumPlanes[planeID].y < 0.0f)
		{
			axisVert.y = aabb_min.y + objPos.y; // min y + obj position's y
		}
		else
		{
			axisVert.y = aabb_max.y + objPos.y; // max y + obj position's y
		}

		// z-axis
		if(frustumPlanes[planeID].z < 0.0f)
		{
			axisVert.z = aabb_min.z + objPos.z; // min z + obj position's z
		}
		else
		{
			axisVert.z = aabb_max.z + objPos.z; // min z + obj position's z
		}

		// Now we get the signed distance from the AABB's vertex that's furthest down the frustum planes normal,
		// and if the signed distance is negative, then the entire bounding box is behind the frustum plane, which means
		// that it should be culled
		if(XMVectorGetX(XMVector3Dot(planeNormal, XMLoadFloat3(&axisVert))) + planeConstant < 0.0f)
		{
			entity->lastRejectedFrustumPlane = planeID; // store rejected frustum plane ID for the next frames
			return true;
		}
	}

	return false;
}

 

 

Keep in mind these 10.000 objects are all inside the view frustum so they'll all go through all 6 planes and pass (worst case scenario I know).

I've commented out the draw call itself so the rendering itself has no influence on these numbers.

Edited by lipsryme
1

Share this post


Link to post
Share on other sites

Sounds resonable, at least my frustum culling implementation I implemented today takes approximately 0,53 ms to cull 10000 objects that are all visible. I didn't implement the last rejection optimization though. Thats is my code:

 

bool Plane::Inside(const BoundingBox& box) const
{
	D3DXVECTOR3 vMin(box.m_vCenter.x - box.m_size, box.m_vCenter.y - box.m_size, box.m_vCenter.z - box.m_size), vMax(box.m_vCenter.x + box.m_size, box.m_vCenter.y + box.m_size, box.m_vCenter.z + box.m_size);
	D3DXVECTOR4 vPos;
	if(m_vNormal.x >= 0.0f)  
	{ 
		vPos.x=vMax.x; 
	}
    else 
	{ 
		vPos.x=vMin.x; 
	}
    if(m_vNormal.y >= 0.0f)  
	{ 
		vPos.y=vMax.y; 
	}
    else 
	{ 
		vPos.y=vMin.y; 
	}
    if(m_vNormal.z >= 0.0f)  
	{ 
		vPos.z=vMax.z; 
	}
    else 
	{ 
		vPos.z=vMin.z; 
	}

	vPos.w = 1.0f;

	float posDot = D3DXPlaneDot(&m_plane, &vPos);

	if(posDot < 0.0f)
		return false;
	else
		return true;
}

bool Frustum::TestBox(const BoundingBox& box) const
{
	for ( int i = 0; i < 6; i++ )
    {
        if ( !m_frustums[i].Inside(box) )
			return false;
    }
    return true;
}
1

Share this post


Link to post
Share on other sites

The question miss details for a good answer. 10K box culled by a frustum in 0.5ms on PS3 is probably good, on a high end CPU is probably not :) If your final scene is below 10K primitives, it is good, if your final scene will contains millions of primitives, it will not be. If you can run the culling on a thread and doing something long enough before needing the result, even if it would last for 3ms, it is not a problem.  You may even run the frustum culling on GPU and do some draw indexed indirect without cpu sync.

 

 The only thing i can tell is that your code is far from optimal by itself when considering batching a same process for a lot of entry ! Everything will depend on the data layout. Two paradigm exist, Array of structure (each box in the array is made of two points each made of x, y and z coordinate) and Structure of Array ( a container of N box split in 6 arrays of float ). By choosing the second one, you can do some SIMD programing, and divide the frustum test count by 4 for almost free. You can also try to remove branching with some value masking, ...

 

The C++ way with a Plane API to test a single point distance looks nice, but most of the times, if you want to test one point, you wants to test N points and there is certainly part of the computation mergeable.

 

Good luck :)

0

Share this post


Link to post
Share on other sites
Well it's just for the pc, so x86 architecture. And I don't think I'll ever have even close to that many entities in my scene. I guess particles would be culled differently?
0

Share this post


Link to post
Share on other sites

Well it's just for the pc, so x86 architecture. And I don't think I'll ever have even close to that many entities in my scene. I guess particles would be culled differently?

If doing cpu simulated particles it is quite fast to cull them using some sort of sphere frustum test. The the test is just couple of dots and sometimes you can skip near and far planes.
I implemented this for all my particles and this give me substantial performance gain with ios. And code is not yet even using any SIMD's.
0

Share this post


Link to post
Share on other sites

Great article. I'm gonna have a look at that.

Edited by lipsryme
0

Share this post


Link to post
Share on other sites

I've got it implemented now but somehow my "negativeMask" always results to 0.

Do I have to transform center and extent to world space first ? I tried doing that using += objPos but still 0. Or do I need to do a multiply by the world matrix ?

 

UPDATE: Ah got it working! Of course I should not have added the world position to the extent rolleyes.gif

Well its down to ~0.4ms cool.png

bool RendererD3D11::FrustumCull(SceneEntityDescription* entity,
								_Plane* frustumPlanes,
								_Plane* absFrustumPlanes)
{
	_Vector3f center = static_cast<AABB*>(this->contentManager->GetPrimitiveFromPool(entity->ID)->GetBoundingVolume())->Volume().center;
	_Vector3f extent = static_cast<AABB*>(this->contentManager->GetPrimitiveFromPool(entity->ID)->GetBoundingVolume())->Volume().extent;
	_Vector3f objPos;
	objPos.x = entity->worldPosition.x;
	objPos.y = entity->worldPosition.y;
	objPos.z = entity->worldPosition.z;

	center.x += objPos.x;
	center.y += objPos.y;
	center.z += objPos.z;

        // this was wrong...
        //**************************
	//* extent.x += objPos.x;
	//* extent.y += objPos.y;
	//* extent.z += objPos.z;
        //**************************

	__m128 xmm_aabbCenter_x = _mm_load_ss(&center.x);
	__m128 xmm_aabbCenter_y = _mm_load_ss(&center.y);
	__m128 xmm_aabbCenter_z = _mm_load_ss(&center.z);
	__m128 xmm_aabbExtent_x = _mm_load_ss(&extent.x);
	__m128 xmm_aabbExtent_y = _mm_load_ss(&extent.y);
	__m128 xmm_aabbExtent_z = _mm_load_ss(&extent.z);
	
	for(unsigned int iPlane = 0;iPlane < 6;++iPlane)
	{
		__m128 xmm_frustumPlane_Component = _mm_load_ss(&frustumPlanes[iPlane].nx);
		__m128 xmm_d = _mm_mul_ss(xmm_aabbCenter_x, xmm_frustumPlane_Component);

		xmm_frustumPlane_Component = _mm_load_ss(&frustumPlanes[iPlane].ny);
		xmm_d = _mm_add_ss(xmm_d, _mm_mul_ss(xmm_aabbCenter_y, xmm_frustumPlane_Component));

		xmm_frustumPlane_Component = _mm_load_ss(&frustumPlanes[iPlane].nz);
		xmm_d = _mm_add_ss(xmm_d, _mm_mul_ss(xmm_aabbCenter_z, xmm_frustumPlane_Component));

		__m128 xmm_absFrustumPlane_Component = _mm_load_ss(&absFrustumPlanes[iPlane].nx);
		__m128 xmm_r = _mm_mul_ss(xmm_aabbExtent_x, xmm_absFrustumPlane_Component);

		xmm_absFrustumPlane_Component = _mm_load_ss(&absFrustumPlanes[iPlane].ny);
		xmm_r = _mm_add_ss(xmm_r, _mm_mul_ss(xmm_aabbExtent_y, xmm_absFrustumPlane_Component));

		xmm_absFrustumPlane_Component = _mm_load_ss(&absFrustumPlanes[iPlane].nz);
		xmm_r = _mm_add_ss(xmm_r, _mm_mul_ss(xmm_aabbExtent_z, xmm_absFrustumPlane_Component));

		__m128 xmm_frustumPlane_d = _mm_load_ss(&frustumPlanes[iPlane].d);
		__m128 xmm_d_p_r = _mm_add_ss(_mm_add_ss(xmm_d, xmm_r), xmm_frustumPlane_d);
		__m128 xmm_d_m_r = _mm_add_ss(_mm_add_ss(xmm_d, xmm_r), xmm_frustumPlane_d);

		// Shuffle d_p_r and d_m_r in order to perform only one _mm_movmask_ps
		__m128 xmm_d_p_r__d_m_r = _mm_shuffle_ps(xmm_d_p_r, xmm_d_m_r, _MM_SHUFFLE(0, 0, 0, 0));
		int negativeMask = _mm_movemask_ps(xmm_d_p_r__d_m_r);

		// Bit 0 holds the sign of d + r and bit 2 holds the sign of d - r
		if(negativeMask & 0x01)
		{
			return true; // Outside
		}
		else if(negativeMask & 0x04)
		{
			return false; // Intersect
		}
	}


	return false;
}
Edited by lipsryme
0

Share this post


Link to post
Share on other sites

As said before, store all the boxes in a continuous array, and output an array of visibility. Try avoiding going from scalar registers and simd ones too and process everything in a single api call. You will for example be able to move the frustum planes load outside the loop ( very important when you loop over thousands of boxes ). your happy 0.4ms will look sad after that :)

0

Share this post


Link to post
Share on other sites

You can further accelerate it by integrating the frustum culling in the collision detection, so a large amount of stuff will be spared tests versus the frustum, due to the broad phase, altho things might get weird.

0

Share this post


Link to post
Share on other sites

@galop1n you mean going through every object first and culling 4 boxes at once ?
But if I were to do that I'd need 2 loops through every object since I need to go through it again right after to actually draw them...
What I do right now is go through every object, check if it should be culled and then either draw it or continue to the next.
Also I was trying to avoid making separate containers since doing 10k push_backs doesn't work that great.

I could use a boolean maybe...would still have to go through all entities again but I wouldn't have the overhead of push_back.

Edited by lipsryme
0

Share this post


Link to post
Share on other sites

@Hellraizer

On the plus side, the last piece of code in the post (4 boxes at a time) does it correctly

 

Now i am confused as in 4box version says:

// NOTE: This loop is identical to the CullAABBList_SSE_1() loop. Not shown in order to keep this snippet small.

 

where that part of code is that you mentioned.

 

Also, for some reason it fails on Debug mode (VS 2012) with "Unhandled exception...reading location 0x0"

 

debugging.jpg

 

while working fine in Release?

0

Share this post


Link to post
Share on other sites

@galop1n

I don't understand why is it not already aligned? I have array of planes

struct _Plane
{
    float nx;
    float ny;
    float nz;
    float d;
};
 
std::array<_Plane, 6> vFrustum;

 

Does it need to force alignment or something?

0

Share this post


Link to post
Share on other sites

Ive added this

 

__declspec(align(16))
struct _Plane
{
    float nx;
    float ny;
    float nz;
    float d;
};

 

and now it works in Debug. But i don't understand why isn't it already 16byte aligned as data is 4 floats ?

 

sizeof(float) * 4 == sizeof(_Plane)
Edited by belfegor
1

Share this post


Link to post
Share on other sites

class and type sizes are unrelated to instance adresses.

 

Excuse my stupidity i still don't understand.

You mean instances of a _Plane in an std::array or vector might not be contiguous in memory (with their default allocator)?

Edited by belfegor
0

Share this post


Link to post
Share on other sites

But i don't understand why isn't it already 16byte aligned as data is 4 floats ?

It's made up of primitives, each of which only requires 4-byte alignment to work correctly, so the struct will work as long as it's 4-byte aligned. It doesn't need to be 8 or 16 byte aligned in order to function correctly, only 4-byte aligned (and this is assuming that floats actually need to be 4 byte aligned).
 
 


class and type sizes are unrelated to instance adresses.

Excuse my stupidity i still don't understand.
You mean instances of a _Plane in an std::array or vector might not be contiguous in memory (with their default allocator)?


As far as I know:
  • std::allocator<T>::allocate (which is used by the std containers) or "new T" will return a block of memory that is correctly aligned for the type "T" (i.e. the address is a multiple of [tt]alignof(T)[/tt])
  • malloc( sizeof(T) ) wont.
Edited by Hodgman
2

Share this post


Link to post
Share on other sites

As far as I know:

std::allocator::allocate (which is used by the std containers) or "new T" will return a block of memory that is correctly aligned for the type "T".
malloc( sizeof(T) ) wont.

 

Sadly, the standard do not consider simd types, the largest native alignment use by the default std::alocator is the one for a long long, that is only 8 bytes.

0

Share this post


Link to post
Share on other sites

Am i getting this right:

__declspec(align(16))
struct Foo
{
    float x;
    float y;
    float z;
};

 

storage space for each element would be 16 bytes?

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0