LearnOpenGL

Frustum-Culling.html (26244B)

---

     <div id="content">
     <h1 id="content-title">Frustum Culling</h1>
 <h1 id="content-url" style='display:none;'>Guest-Articles/2021/Scene/Frustum-Culling</h1>
 <p>
         Now we know how to create a Scene graph and organize your object in a scene, we are going to see how to limit your GPU usage thanks to a technical name's the frustum culling.
         This technique is simple to understand.
         Instead of sending all information to your GPU, you will sort visible and invisible elements and render only visible elements.
         Thanks to this technique, you will earn GPU compute time.
         You need to know that when information travels toward another unit in your computer, it takes a long time.
         For example, information from your GPU to your ram takes time.
         It's the same if you want to send information from your CPU to your GPU like a model matrice.
         It's for this reason that the "draw instance" is so powerful.
         You send a large block to your GPU instead of sending elements one by one.
         But this technique isn’t free.
         To sort your element, you need to create a physical scene to compute some stuff with math.
         This chapter will start with an introduction to the mathematical concept that will allow us to understand how frustum culling works.
         Next, we are going to implement it.
         Finally, we are going to study possible optimizations and talk about the balance of the technical.
     </p>
 
     <video width="850" controls>
       <source src="/img\guest\2021\Frustum_culling\frustumExample.mp4" type="video/mp4">
         Your browser does not support the video tag.
     </video>
 
       <p>
     In this video illustrating frustum culling in a forest, the yellow and red shape on the left side is the bounding volume that contains the mesh.
     Red color means that the mesh is not visible and not sent to the GPU.
     Yellow means that the mesh is rendered.
     As you can see lots of things are rendered and few are visible for the player.
       </p>
 
     <h2>Mathematical concept</h2>
 
     <p>
         Let's start the mathematical parts from top to bottom.
         Firstly, what is a frustum?
         As we can see in <a href="https://en.wikipedia.org/wiki/Frustum" target="_blank"> Wikipedia</a>, frustum is a portion of a solid like a cone or pyramid.
         The frustum is usually used in game engine to speak about the camera frustum.
         Camera frustum represents the zone of vision of a camera.
         Without limit, we have a pyramid but with near and far we have a frustum. 
     </p>
 
       <img src="/img/guest/2021/Frustum_culling/VisualCameraFrustum.png" alt="Camera frustum shape"/>
 
     <p>
         How to mathematically represent a frustum?
         Thanks to 6 plans: near, far, right, left top and bottom plans.
         So, an object is visible if it is forward or on the 6 plans.
         Mathematically a plan is represented with a normal vector and distance to the origin.
         A plan doesn't have any size or limit as a quad. 
     </p>
 
       <img src="/img/guest/2021/Frustum_culling/plan.png"  width="600" alt="Plan representation"/>
 
     <p>
         So, create a struct to represent a plan:
     </p>
     <pre><code>
 struct Plan
 {
     // unit vector
     glm::vec3 normal = { 0.f, 1.f, 0.f };
 
     // distance from origin to the nearest point in the plan
     float     distance = 0.f;             
 
     [...]
 };
     </code></pre>
 
     <p>
      We can now create <fun>Frustum</fun> structure:
     </p>
 
     <pre><code>
 struct Frustum
 {
     Plan topFace;
     Plan bottomFace;
 
     Plan rightFace;
     Plan leftFace;
 
     Plan farFace;
     Plan nearFace;
 };
     </code></pre>
 
     <p>
         Reminder: a plan can be built with a point and a normal. 
         For the near, the normal is the front vector of the camera. 
         For the far plan, it's the opposite. 
         The normal of the right face we will need to do a cross product.
         The cross product is the second wonderful tool for the programmer who likes vectors.
         It allows you to get a perpendicular vector to a plan created with two vectors.
         To go forward, we need to do the cross product of the right axis per up.
         We will use it like that:
     </p>
 
       <img src="/img/guest/2021/Frustum_culling/RightNormal.png" alt="Plan representation"/>
 
     <p>
         But to know the direction of each vector from the camera to the far plan we will know the side length of the far quad:
     </p>
       <img src="/img/guest/2021/Frustum_culling/hAndVSide.png" alt="Plan representation"/>
 
     <p>
         hSide and vSide are the far quad limited by the other plans of the camera frustum.
         To compute its edge, we will need of trigonometry.
         As you can see in the image above, we have two rectangle triangles and we can apply the trigonometric functions.
         So, we would like to obtain vSide which is the opposite side and we have zFar that is the adjacent side of the camera.
         Tan of fovY is equal to the opposite side (vSide) divided by the adjacent side (zFar).
         In conclusion, if I move the adjacent side on the left on our equation, tan of fovY multiplied by the zFar is equal to the vSide.
         We now need to compute hSide.
         Thanks to the aspect that is a ratio of the width by the height, we can easily obtain it.
         So, hSide is equal to the vSide multiplied by the aspect as you can see on the right side of the image above.
         We can now implement our function:
     </p>
 
     <pre><code>
 Frustum createFrustumFromCamera(const Camera& cam, float aspect, float fovY,
                                                                 float zNear, float zFar)
 {
     Frustum     frustum;
     const float halfVSide = zFar * tanf(fovY * .5f);
     const float halfHSide = halfVSide * aspect;
     const glm::vec3 frontMultFar = zFar * cam.Front;
 
     frustum.nearFace = { cam.Position + zNear * cam.Front, cam.Front };
     frustum.farFace = { cam.Position + frontMultFar, -cam.Front };
     frustum.rightFace = { cam.Position,
                             <function id='61'>glm::cross</function>(cam.Up,frontMultFar + cam.Right * halfHSide) };
     frustum.leftFace = { cam.Position,
                             <function id='61'>glm::cross</function>(frontMultFar - cam.Right * halfHSide, cam.Up) };
     frustum.topFace = { cam.Position,
                             <function id='61'>glm::cross</function>(cam.Right, frontMultFar - cam.Up * halfVSide) };
     frustum.bottomFace = { cam.Position,
                             <function id='61'>glm::cross</function>(frontMultFar + cam.Up * halfVSide, cam.Right) };
 
     return frustum;
 }
 </code></pre>
 <note>
     In this example, the camera doesn't know the near, aspect but I encourage you to include this variable inside your Camera class.
 </note>
 
     <h3>Bounding volume</h3>
 
     <p>
         Let's take a minute to imagine an algorithm that can detect collisions with your mesh (with all types of polygons in general) and a plan.
         You will start to say that image is an algorithm that checks if a triangle is on or outside the plane.
         This algorithm looks pretty and fast! But now imagine that you have hundreds of mesh with thousands of triangles each one.
         Your algorithm will sign the death of your frame rate fastly.
         Another method is to wrap your objects in another geometrical object with simplest properties such as a sphere, a box, a capsule...
         Now our algorithm looks possible without creating a framerate black hole.
         Its shape is called bounding volume and allows us to create a simpler shape than our mesh to simplify the process.
         All shapes have their own properties and can correspond plus or minus to our mesh. 
     </p>
       <img src="/img/guest/2021/Frustum_culling/boundingVolumeQuality.png" alt="Bounding volume quality vs computation speed"/>
 
     <p>
         All shapes also have their own compute complexity.
         The <a href="https://en.wikipedia.org/wiki/Bounding_volume" target="_blank">article</a> on Wikipedia is very nice and describes some bounding volumes with their balance and application.
         In this article, we are going to see 2 bounding volumes: the sphere and the AABB.
         Let's create a simple abstract struct Volume that represent all our bounding volumes: 
     </p>
 
     <pre><code>
 struct Volume
 {
     virtual bool isOnFrustum(const Frustum& camFrustum,
                                             const Transform& modelTransform) const = 0;
 };
     </code></pre>
 
     <h4>Sphere</h4>
 
       <img src="/img/guest/2021/Frustum_culling/boundingSphere.png" alt="Bounding sphere example"/>
 
     <p>
         The bounding sphere is the simplest shape to represent a bounding volume.
         It is represented by center and radius.
         A sphere is ideal to encapsulate mesh with any rotation.
         It must be adjusted with the scale and position of the object.
         We can create struct Sphere that inheritance from volume struct:
     </p>
 
     <pre><code>
 struct Sphere : public Volume
 {
     glm::vec3 center{ 0.f, 0.f, 0.f };
     float radius{ 0.f };
 
     [...]
 }
     </code></pre>
 
     <p>
         This struct doesn't compile because we haven't defined the function isOnFrustum.
         Let's make it.
         Remember that our bounding volume is processed thanks to our meshes.
         That assumes that we will need to apply a transform to our bounding volume to apply it.
         As we have seen in the previous chapter, we will apply the transformation to a scene graph.
     </p>
 
     <pre><code>
 bool isOnFrustum(const Frustum& camFrustum, const Transform& transform) const final
 {
     //Get global scale is computed by doing the magnitude of
     //X, Y and Z model matrix's column.
     const glm::vec3 globalScale = transform.getGlobalScale();
 
     //Get our global center with process it with the global model matrix of our transform
     const glm::vec3 globalCenter{ transform.getModelMatrix() * glm::vec4(center, 1.f) };
 
     //To wrap correctly our shape, we need the maximum scale scalar.
     const float maxScale = std::max(std::max(globalScale.x, globalScale.y), globalScale.z);
 
     //Max scale is assuming for the diameter. So, we need the half to apply it to our radius
     Sphere globalSphere(globalCenter, radius * (maxScale * 0.5f));
 
     //Check Firstly the result that have the most chance
     //to faillure to avoid to call all functions.
     return (globalSphere.isOnOrForwardPlan(camFrustum.leftFace) &&
         globalSphere.isOnOrForwardPlan(camFrustum.rightFace) &&
         globalSphere.isOnOrForwardPlan(camFrustum.farFace) &&
         globalSphere.isOnOrForwardPlan(camFrustum.nearFace) &&
         globalSphere.isOnOrForwardPlan(camFrustum.topFace) &&
         globalSphere.isOnOrForwardPlan(camFrustum.bottomFace));
 };
     </code></pre>
     <note>
         To compute the globalCenter we can’t only add the current center with the global position because we need to apply translation caused by rotation and scale.
         This is the reason why we use the model matrix. 
     </note>
 
     <p>
         As you can see, we used a function undefined for now called <fun>isOnOrForwardPlan</fun>.
         This implementation method is called top/down programming and consists to create a high-level function to determine which kind of function need to be implemented.
         It avoids to implement too many unused functions that can be the case in "bottom/up".
         So to understand how this function works, let's make a drawing :
     </p>
 
       <img src="/img/guest/2021/Frustum_culling/SpherePlanDetection.png" width="400" height="400" alt="Sphere plan collision shema"/>
 
     <p>
         We can see 3 possible cases: Sphere is inside the plan, back or forward.
         To detect when a sphere is colliding with a plan we need to compute the nearest distance from the center of the sphere to the plan.
         When we have this distance, we need to compare this distance with radius.
     </p>
 
     <pre><code>
 bool isOnOrForwardPlan(const Plan& plan) const
 {
     return plan.getSignedDistanceToPlan(center) > -radius;
 }
     </code></pre>
 
     <note>
         We can see the problem in the other way and create a function called <fun>isOnBackwardPlan</fun>.
         To use it we simply need to check if bounding volume IS NOT on the backward plan
     </note>
 
     <p>
         Now we need to create the function <fun>getSignedDistanceToPlan</fun> in the </un>Plan</fun> structure.
         Let me realize my most beautiful paint for you :
     </p>
 
 <img src="/img/guest/2021/Frustum_culling/SignedDistanceDraw.png" width="400" height="400" alt="Signed distance to plan shema"/>
     
     <p>
         Signed distance is a positive distance from a point if this point is forward the plan.
         Otherwise this distance will be negative.
         To obtain it, we will need to call a friend: The dot product.
         Dot product allows us to obtain the projection from a vector to another.
         The result of the dot product is a scale and this scalar is a distance.
         If both vectors go oppositely, the dot product will be negative.
         Thanks to it, we will obtain the horizontal scale component of a vector in the same direction as the normal of the plan.
         Next, we will need to subtract this dot product by the nearest distance from the plan to the origin.
         Hereafter you will find the implementation of this function :
     </p>
 
     <pre><code>
 float getSignedDistanceToPlan(const glm::vec3& point) const
 {
     return glm::dot(normal, point) - distance;
 }
     </code></pre>
 
     <h4>AABB</h4>
 <img src="/img/guest/2021/Frustum_culling/boundingAABB.png" alt="Bounding AABB example"/>
 
     <p>
         AABB is the acronym of Axis aligned bounding box.
         It means that this volume has the same orientation as the world.
         It can be constructed as different can be we generally create it with its center and its half extension.
         The half extension is a distance from center to the edge in the direction of an axis.
         The half extension can be called Ii, Ij, Ik. In this chapter, we will call it Ix, Iy, Iz.
     </p>
 
 <img src="/img/guest/2021/Frustum_culling/AABBRepresentation.png" width="400" alt="AABB representation"/>
 
     <p>
         Let's make the base of this structure with few constructors to made its creation the simplest
     </p>
 
     <pre><code>
 struct AABB : public BoundingVolume
 {
     glm::vec3 center{ 0.f, 0.f, 0.f };
     glm::vec3 extents{ 0.f, 0.f, 0.f };
 
     AABB(const glm::vec3& min, const glm::vec3& max)
         : BoundingVolume{},
         center{ (max + min) * 0.5f },
         extents{ max.x - center.x, max.y - center.y, max.z - center.z }
     {}
 
     AABB(const glm::vec3& inCenter, float iI, float iJ, float iK)
         : BoundingVolume{}, center{ inCenter }, extents{ iI, iJ, iK }
     {}
 
     [...]
 };
     </code></pre>
 
     <p>
         We now need to add the function <fun>isOnFrustum</fun> and <fun>isOnOrForwardPlan</fun>.
         The problem is not easy as a bounding sphere because if I rotate my mesh, the AABB will need to be adjusted.
         An image talks much than a text :
     </p>
 
 <img src="/img/guest/2021/Frustum_culling/AABBProblem.png" alt="AABB rotation probleme"/>
 
     <p>
         To solve this problem lets draw it :
     </p>
 
 <img src="/img/guest/2021/Frustum_culling/AABB orientation.png" alt="AABB orientation problem explication"/>
 
     <p>
         Crazy guys want to rotate our beautiful Eiffel tower but we can see that after its rotation, the AABB is not the same.
         To make the Shema more readable, assume that referential is not a unit and represented the half extension with the orientation of the mesh.
         To adjust it, we can see in the third picture that the new extension is the sum of the dot product with the world axis and the scaled referential of our mesh.
         The problem is seen in 2D but in 3D it's the same thing. Let's implement the function to do it. 
     </p>
 
     <pre><code>
 bool isOnFrustum(const Frustum& camFrustum, const Transform& transform) const final
 {
     //Get global scale thanks to our transform
     const glm::vec3 globalCenter{ transform.getModelMatrix() * glm::vec4(center, 1.f) };
 
     // Scaled orientation
     const glm::vec3 right = transform.getRight() * extents.x;
     const glm::vec3 up = transform.getUp() * extents.y;
     const glm::vec3 forward = transform.getForward() * extents.z;
 
     const float newIi = std::abs(glm::dot(glm::vec3{ 1.f, 0.f, 0.f }, right)) +
         std::abs(glm::dot(glm::vec3{ 1.f, 0.f, 0.f }, up)) +
         std::abs(glm::dot(glm::vec3{ 1.f, 0.f, 0.f }, forward));
 
     const float newIj = std::abs(glm::dot(glm::vec3{ 0.f, 1.f, 0.f }, right)) +
         std::abs(glm::dot(glm::vec3{ 0.f, 1.f, 0.f }, up)) +
         std::abs(glm::dot(glm::vec3{ 0.f, 1.f, 0.f }, forward));
 
     const float newIk = std::abs(glm::dot(glm::vec3{ 0.f, 0.f, 1.f }, right)) +
         std::abs(glm::dot(glm::vec3{ 0.f, 0.f, 1.f }, up)) +
         std::abs(glm::dot(glm::vec3{ 0.f, 0.f, 1.f }, forward));
 
     //We not need to divise scale because it's based on the half extention of the AABB
     const AABB globalAABB(globalCenter, newIi, newIj, newIk);
 
     return (globalAABB.isOnOrForwardPlan(camFrustum.leftFace) &&
         globalAABB.isOnOrForwardPlan(camFrustum.rightFace) &&
         globalAABB.isOnOrForwardPlan(camFrustum.topFace) &&
         globalAABB.isOnOrForwardPlan(camFrustum.bottomFace) &&
         globalAABB.isOnOrForwardPlan(camFrustum.nearFace) &&
         globalAABB.isOnOrForwardPlan(camFrustum.farFace));
 };
     </code></pre>
 
     <p>
         For the function <fun>isOnOrForwardPlan</fun>, I have taken an algorithm that I found in a wonderful <a href="https://gdbooks.gitbooks.io/3dcollisions/content/Chapter2/static_aabb_plan.html" target="_blank">article</a>.
         I invite you to have a look at it if you want to understand how it works.
         I just modify the result of its algorithm to check if the AABB is on or forward my plan.
     </p>
 
     <pre><code>
 bool isOnOrForwardPlan(const Plan& plan) const
 {
     // Compute the projection interval radius of b onto L(t) = b.c + t * p.n
     const float r = extents.x * std::abs(plan.normal.x) +
             extents.y * std::abs(plan.normal.y) + extents.z * std::abs(plan.normal.z);
 
     return -r <= plan.getSignedDistanceToPlan(center);
 }
     </code></pre>
 
     <p>
         To check if our algorithm works, we need to check that every object disappeared in front of our camera when we moved.
         Then, we can add a counter that is incremented if an object is displayed and another for the total displayed in our console.
     </p>
 
     <pre><code>
 // in main.cpp main lopp
 unsigned int total = 0, display = 0;
 ourEntity.drawSelfAndChild(camFrustum, ourShader, display, total);
 std::cout << "Total process in CPU : " << total;
 std::cout << " / Total send to GPU : " << display << std::endl;
 
 // In the drawSelfAndChild function of entity
 void drawSelfAndChild(const Frustum& frustum, Shader& ourShader,
                                             unsigned int& display, unsigned int& total)
 {
     if (boundingVolume->isOnFrustum(frustum, transform))
     {
         ourShader.setMat4("model", transform.getModelMatrix());
         pModel->Draw(ourShader);
         display++;
     }
     total++;
 
     for (auto&& child : children)
     {
         child->drawSelfAndChild(frustum, ourShader, display, total);
     }
 }
     </code></pre>
 
 <img src="/img/guest/2021/Frustum_culling/result.png" alt="Result"/>
 
     <p>
         Ta-dah ! The average of objects sent to our GPUrepresents now about 15% of the total and is only divided by 6.
         A wonderful result if your GPU process is the bottleneck because of your shader or number of polygons.
         You can find the code <a href="https://learnopengl.com/code_viewer_gh.php?code=src/8.guest/2021/1.scene/2.frustum_culling/frustum_culling.cpp" target="_blank">here</a>.
     </p>
 
     <h2>Optimization</h2>
     <p>
         Now you know how to make your frustum culling.
         Frustum culling can be useful to avoid computation of things that are not visible.
         You can use it to not compute the animation state of your entity, simplify its AI...
         For this reason, I advise you to add a IsInFrustum flag in your entity and do a frustum culling pass that fills this variable.
     </p>
     <h3>Space partitionning</h3>
     <p>
         In our example, frustum culling is a good balance with a small number of entities in the CPU.
         If you want to optimize your detection, you now will need to partition your space. 
         To do it, a lot of algorithms exist and each has interesting properties which depend on your usage :
         - BSH (Bounding sphere hierarchy or tree) : 
             Different kinds exist. The simplest implementation is to wrap both nearest objects in a sphere.
             Wrap this sphere with another group or objetc etc...
       <img src="/img/guest/2021/Frustum_culling/BSH.png"  width="400" height="400" alt="BSH example"/>
     </p>
     <note>
         In this example, only 2 checks allow us to know that 3 objects are in frustum instead of 6 because if the bounding sphere is totally inside the frustum all its content is also inside.
         If the bounding sphere is not inside when needed to inter and check its content.
     </note>
     <p>
         - <a href="https://en.wikipedia.org/wiki/Quadtree" target="_blank">Quadtree</a> : 
             The main idea is that you will split space into 4 zones that can be split into four zones etc... until an object wasn't wrapped alone.
             Your object will be the leaf of this diagram.
             The quadtree is very nice to partition 2D spaces but also if you don't need to partition height. It can be very useful in strategy games like 4x (like age of empire, war selection...) because you don't need height partitioning.
       <img src="/img/guest/2021/Frustum_culling/quadtree.png" width="400" height="400" alt="Quatree example"/>
         - <a href="https://en.wikipedia.org/wiki/Octree" target="_blank">Octree</a> : 
             It's like a quadtree but with 8 nodes. It's nice if you have a 3D game with elements in different height levels.
       <img src="/img/guest/2021/Frustum_culling/octree.png"  width="500" alt="Octree example"/>
         - <a href="https://en.wikipedia.org/wiki/Binary_space_partitioning" target="_blank">BSP (binary space partitioning)</a> : 
             It's a very fast algorithm that allows you to split space with segments. You will define a segment and the algorithm will sort if an object is in front of this segment or behind.
             It's very useful with a map, city, dungeon... The segments can be created at the same time if you generate a map and can be fast forward.
       <img src="/img/guest/2021/Frustum_culling/BSP.png" alt="BSP example"/>
         - Lot of other methods exist, be curious.
         I don't implement each of these methods, I just learn it to know that they exist if one day I need specific space partitioning.
         Some algorithm is great to parallelize like octree of quadtree if you use multithread and must also balance on your decision.
     </p>
 
     <h3>Compute shader</h3>
     <p>
         Compute shader allows you to process computation on shader.
         This technique must be used only if you have a high parallelized task like check collision with a simple list of bounds.
         I never implemented this technique for the frustum culling but it can be used in this case to avoid updating space partitioning if you have a lot of objects that move.
     </p>
 
     <h2>Additional resources</h2>
     <ul>
 		<li><a href="http://www.cs.otago.ac.nz/postgrads/alexis/planExtraction.pdf" target="_blank">
 			Article about camera frustum extraction</a>: Fast Extraction of Viewing Frustum Plans from the WorldView-Projection Matrix by Gil Gribb and Klaus Hartmann</li>    
 
         <li><a href="https://gdbooks.gitbooks.io/3dcollisions/content/Chapter1/aabb.html" target="_blank">
             Article about collisions detection</a>: A wonderful resource for collision detection and another approach about volume, culling and mathematic concept</li>   
             
         <li><a href="https://www.gamedev.net/tutorials/programming/general-and-gameplay-programming/frustum-culling-r4613/" target="_blank">
             Article to go further</a>: A good article to go further on GPU culling process, multithreading and OBB</li>
         </ul>
 
 	
       <author>
 			<strong>Article by: </strong>Six Jonathan<br>
 			<strong>Contact: </strong><a href="Six-Jonathan@orange.fr" target="_blank">e-mail</a><br>
 			<strong>Date: </strong> 09/2021<br>
 			<div>
 				<a href="https://github.com/Renardjojo">
 					<svg height="32" aria-hidden="true" viewBox="0 0 16 16" version="1.1" width="32" data-view-component="true" class="octicon octicon-mark-github v-align-middle">
 						<path fill-rule="evenodd" d="M8 0C3.58 0 0 3.58 0 8c0 3.54 2.29 6.53 5.47 7.59.4.07.55-.17.55-.38 0-.19-.01-.82-.01-1.49-2.01.37-2.53-.49-2.69-.94-.09-.23-.48-.94-.82-1.13-.28-.15-.68-.52-.01-.53.63-.01 1.08.58 1.23.82.72 1.21 1.87.87 2.33.66.07-.52.28-.87.51-1.07-1.78-.2-3.64-.89-3.64-3.95 0-.87.31-1.59.82-2.15-.08-.2-.36-1.02.08-2.12 0 0 .67-.21 2.2.82.64-.18 1.32-.27 2-.27.68 0 1.36.09 2 .27 1.53-1.04 2.2-.82 2.2-.82.44 1.1.16 1.92.08 2.12.51.56.82 1.27.82 2.15 0 3.07-1.87 3.75-3.65 3.95.29.25.54.73.54 1.48 0 1.07-.01 1.93-.01 2.2 0 .21.15.46.55.38A8.013 8.013 0 0016 8c0-4.42-3.58-8-8-8z"></path>
 					</svg>
 				</a>
 				<a href="https://www.linkedin.com/in/jonathan-six-4553611a9/">
 					<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 34 34" class="global-nav__logo">
 						<path d="M34,2.5v29A2.5,2.5,0,0,1,31.5,34H2.5A2.5,2.5,0,0,1,0,31.5V2.5A2.5,2.5,0,0,1,2.5,0h29A2.5,2.5,0,0,1,34,2.5ZM10,13H5V29h5Zm.45-5.5A2.88,2.88,0,0,0,7.59,4.6H7.5a2.9,2.9,0,0,0,0,5.8h0a2.88,2.88,0,0,0,2.95-2.81ZM29,19.28c0-4.81-3.06-6.68-6.1-6.68a5.7,5.7,0,0,0-5.06,2.58H17.7V13H13V29h5V20.49a3.32,3.32,0,0,1,3-3.58h.19c1.59,0,2.77,1,2.77,3.52V29h5Z" fill="currentColor"></path>
 					</svg>
 				</a>
 			</div>
       </author>       
 
     </div>