# view frustum culling particle effects?

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

## Recommended Posts

I am wondering can you use view frustrum culling on particle effects such as fire,smoke etc, i am rendering them using point_list but cant figure out how to not render the effects when the camera is not viewing them

##### Share on other sites

Here are some hints:

1. Don't cull single particles, if you have enqueued a particle just let the gpu render them, the gpu will cull it on its own.

2. Cull particle emitters, so stop emitting particles once they are out of view

3. When a particle emitter is in view again, don't just restart it , but simulate the last X seconds too (save the last stop time), so that the effects dont plop-in.

Edited by Ashaman73

##### Share on other sites

so i need to put a box or sphere around the emiter world position correct?

what if the fire particle moves tho like its spreading, you cant really set a radius for that so how would you block them from rendering if there out of view?

Edited by Anddos

##### Share on other sites

Just handle a particle emitter like a normal game object (in my game engine they are an optional part of a game object). Then cull them like standard game objects while rendering, just take care of a short pre-simulation after it gets visible again.

##### Share on other sites

thats the problem if there points how would you calculate there bounding volume

Edited by Anddos

##### Share on other sites

Check each point and grab the min/max, center is (min + max) * 0.5

Better yet approximate size so you don't need to recalculate every frame.

Edited by belfegor

##### Share on other sites

If you know you particle spread rate and the maximum lifetime of a particle, you can calculate a conservative bounds for the entire system and use that for culling purposes.

##### Share on other sites

#1: Don’t cull emitters. LOD them based on distance from the camera. Farther away = slower emission rate.
#2: Don’t cull individual particles.
-> When the first particle is spawned create an AABB around it.
-> When following particles are spawned, check for distance from the existing AABB. If it is inside an existing AABB, add it to that AABB. If it is close enough to an AABB, add it to that AABB and stretch the AABB to fit the new particle. Otherwise, create a new AABB for the particle.
#3: All AABB’s are updated to fit the particles inside them each frame. This could be done on logical updates, making it less expensive.
#4: Cull the AABB’s. If an AABB is not in view, draw none of its particles. If it is, draw all of its particles with a single draw call.

An AABB can hold anywhere from 10 to 1,000 particles depending on how densely they are emitted.

thats the problem if there points how would you calculate there bounding volume

This question doesn’t make sense. Handle them exactly the same way as any other AABB. There is literally no difference, and I don’t understand why you are asking this. This is a non-question.

An AABB is simply a volume of space. Inside that volume can be spheres, boxes, points, anything. Why do you think points can’t be inside a volume? In fact, most AABB’s are constructed via points inside a mesh.

	/**
* Class CAabb
* \brief A min-max axis-aligned bounding box.
*
* Description: A min-max axis-aligned bounding box.
*/
class CAabb {
public :
// == Functions.
/**
* Compute an AABB from a set of points given in the form of an array of CVector3's.
*
* \param _vPoints The array of points to enclose.
* \param _uiTotal The number of points in the array to which _vPoints points.
*/
LSVOID LSE_CALL			ComputeAabbFromPointArray( const CVector3 * _pvPoints, LSUINT32 _uiTotal );

// == Members.
/** The minimum X-, Y-, and Z- axis values. */
CVector3			m_vMin;

/** The maximum X-, Y-, and Z- axis values. */
CVector3			m_vMax;
};

/**
* Compute an AABB from a set of points given in the form of an array of CVector3's.
*
* \param _vPoints The array of points to enclose.
* \param _uiTotal The number of points in the array to which _vPoints points.
*/
LSVOID LSE_CALL CAabb::ComputeAabbFromPointArray( const CVector3 * _pvPoints, LSUINT32 _uiTotal ) {
m_vMin.x = m_vMin.y = m_vMin.z = LSM_INFINITY;
m_vMax.x = m_vMax.y = m_vMax.z = -LSM_INFINITY;
for ( LSUINT32 I = _uiTotal; I--; ) {
m_vMin.x = CStd::Min( m_vMin.x, _pvPoints->x );
m_vMin.y = CStd::Min( m_vMin.y, _pvPoints->y );
m_vMin.z = CStd::Min( m_vMin.z, _pvPoints->z );

m_vMax.x = CStd::Max( m_vMax.x, _pvPoints->x );
m_vMax.y = CStd::Max( m_vMax.y, _pvPoints->y );
m_vMax.z = CStd::Max( m_vMax.z, _pvPoints->z );
_pvPoints++;
}
}

You need to clarify your question—asking, “What if they are points without a radius?”, makes no sense. That’s exactly how AABB’s are created.
That’s like asking, “I want to paint my house orange. What should I do it I onlyhave orange paint?”.

L. Spiro

Edited by L. Spiro

##### Share on other sites
#1: Don’t cull emitters. LOD them based on distance from the camera. Farther away = slower emission rate.
#2: Don’t cull individual particles.
-> When the first particle is spawned create an AABB around it.
-> When following particles are spawned, check for distance from the existing AABB. If it is inside an existing AABB, add it to that AABB. If it is close enough to an AABB, add it to that AABB and stretch the AABB to fit the new particle. Otherwise, create a new AABB for the particle.
#3: All AABB’s are updated to fit the particles inside them each frame. This could be done on logical updates, making it less expensive.
#4: Cull the AABB’s. If an AABB is not in view, draw none of its particles. If it is, draw all of its particles with a single draw call.

An AABB can hold anywhere from 10 to 1,000 particles depending on how densely they are emitted.

An interesting approach, thought it seems to be tailored to smooth camera movement through a level (first/third camera movement). It will have issues in other game genres like a RTS where you have 1000s of emitters, instant camera movement (porting) etc. Seeing this, then my approach is more tailored to the latter case.

Eventually a particle system should be optimized/tailred for a certain game (camera) setup.

Edited by Ashaman73

• 34
• 12
• 10
• 9
• 9
• ### Forum Statistics

• Total Topics
631354
• Total Posts
2999507
×