<p>Regarding optimizations:</p>

<p>Could you calculate the min and max corners in modelspace beforehand? Then you could check on the CPU-side the NDCs of these two points and skip the processing of the whole mesh if it is outside of the desired range. This needs only two matrix-vector multiplications on cpu side. And since for rigid bodies these two points do not change over time, you don't have to iterate the meshes in each frame.</p>

CC BY-SA 3.0
2016-02-08T18:09:17.637Z
I can not calculate min max corner in modelspace as after multiplying with view and projection matrices, min and max corner does not remains the same. that is why I am iterating over all the vertices.Previously I thought just using bounding box would suffice but looks like it is changing in clip coordinate space.
debonair
CC BY-SA 3.0
2016-02-09T00:48:54.703Z
when I checked NDC coordinates at the end in both ways, I get very different numbers. with iteration over vertices I get vertex cooridinates in range of minus thousands to plus thousands whereas with bounding boxes they are in range of -10 plus 10 approx.
debonair
CC BY-SA 3.0
2016-02-06T17:36:28.740Z
2016-02-06T21:04:52.903Z
2016-02-06T21:04:52.903Z
Dragonseel
<p>I am implementing foveated rendering. My <a href="https://en.wikipedia.org/wiki/Framebuffer_Object" rel="nofollow noreferrer" title="Framebuffer Object">FBO</a> is divided into 2 layers which are concentric. The first layer covers 1/3 of the Framebuffer whereas the second one covers the rest of the screen. Now I want to avoid rendering meshes in the outer layer which are already in the inner layer.</p>

<p>I have implemented the following culling algorithm which is only concerned with culling between the layers:</p>

<ol>
<li>I create rectangles with min and max corners from the radii of the 2 layers. Now these coordinates are in <a href="https://www.ncl.ucar.edu/Document/Graphics/ndc.shtml" rel="nofollow noreferrer" title="Normalized Device Coordinates">NDC</a>. </li>
<li><p>I have the min and max corner of each mesh in the local coordinate system. So I transform them into NDC using:</p>

<pre><code>vec4 min = mvp * vec4(min_corner, 1.0);
min = min.xyzw / min.w;
</code></pre></li>
<li><p>I create a bounding box using min and max corners.</p></li>
<li>I check whether 2 rectangles overlap or not.</li>
</ol>

<p>Now, when I transform into clip space, the x or y coordinates of the min are sometimes greater than the max corner. The same issue occurs when I divide them by w. What's going wrong here?</p>

<p>EDIT:
Okay. I found the problem. Now I iterate over all the vertices, transform each of them into NDC using <a href="https://stackoverflow.com/questions/5550620/the-purpose-of-model-view-projection-matrix" title="Model View Projection matrix">MVP</a> and then calculate the min and max corners which works perfect. But this is much more overhead for each frame. Is there any optimization I can do here?</p>

CC BY-SA 3.0
2016-02-04T23:53:47.483Z
@trichoplax which part of it you did not understand?
debonair
CC BY-SA 3.0
2016-02-05T04:56:14.470Z
`transform bounding sphere radius and center of sphere in 0-1` doesn't make clear whether you want the radius normalised to 1, or transformed to some value between 0 and 1 (in which case, how is that value determined?). The same for the centre - is it to be moved to the origin or translated to somewhere within a distance 1 from the origin or something else?
trichoplax is on Codidact now
CC BY-SA 3.0
2016-02-05T05:00:12.693Z
`somebody pointed out to me that its not possible to transform radius into 0-1` From the comments on your [initial question](http://computergraphics.stackexchange.com/questions/1996/calculate-bounding-sphere-radius-in-normalized-space) it doesn't appear that anyone is saying that it is not possible to transform the radius. We just need to know what you mean by "0-1".
trichoplax is on Codidact now
CC BY-SA 3.0
2016-02-05T05:35:09.910Z
@trichoplax okay. I changed my algorithm. Can you check it
debonair
CC BY-SA 3.0
2016-02-06T13:18:48.847Z
This seems clearer now. I've edited to add in links and hovertext for the acronyms. If this changes your intention please edit to correct this.
trichoplax is on Codidact now
<opengl><algorithm><3d><transformations><bounding-volume-hierarchy>
culling meshes across mulitple layers
debonair
# culling meshes across mulitple layers

(Asked by: username_0 on 2016-02-03)

I am implementing foveated rendering. My [FBO](https://en.wikipedia.org/wiki/Framebuffer_Object "Framebuffer Object") is divided into 2 layers which are concentric. The first layer covers 1/3 of the Framebuffer whereas the second one covers the rest of the screen. Now I want to avoid rendering meshes in the outer layer which are already in the inner layer.

I have implemented the following culling algorithm which is only concerned with culling between the layers:

1. I create rectangles with min and max corners from the radii of the 2 layers. Now these coordinates are in [NDC](https://www.ncl.ucar.edu/Document/Graphics/ndc.shtml "Normalized Device Coordinates").
2. I have the min and max corner of each mesh in the local coordinate system. So I transform them into NDC using:

   ```
   vec4 min = mvp * vec4(min_corner, 1.0);
   min = min.xyzw / min.w;

   ```
3. I create a bounding box using min and max corners.
4. I check whether 2 rectangles overlap or not.

Now, when I transform into clip space, the x or y coordinates of the min are sometimes greater than the max corner. The same issue occurs when I divide them by w. What's going wrong here?

EDIT:
Okay. I found the problem. Now I iterate over all the vertices, transform each of them into NDC using [MVP](https://stackoverflow.com/questions/5550620/the-purpose-of-model-view-projection-matrix "Model View Projection matrix") and then calculate the min and max corners which works perfect. But this is much more overhead for each frame. Is there any optimization I can do here?

**Tags:** opengl, algorithm, 3d, transformations, bounding-volume-hierarchy

> **Comments:**
> **username_0**: @username_1 which part of it you did not understand?  
> **username_1**: `transform bounding sphere radius and center of sphere in 0-1` doesn't make clear whether you want the radius normalised to 1, or transformed to some value between 0 and 1 (in which case, how is that value determined?). The same for the centre - is it to be moved to the origin or translated to somewhere within a distance 1 from the origin or something else?  
> **username_1**: `somebody pointed out to me that its not possible to transform radius into 0-1` From the comments on your [initial question](http://computergraphics.stackexchange.com/questions/1996/calculate-bounding-sphere-radius-in-normalized-space) it doesn't appear that anyone is saying that it is not possible to transform the radius. We just need to know what you mean by "0-1".  
> **username_0**: @username_1 okay. I changed my algorithm. Can you check it  
> **username_1**: This seems clearer now. I've edited to add in links and hovertext for the acronyms. If this changes your intention please edit to correct this.  

---

## 1 answers

### Answer by username_2 on 2016-02-06. Score: 1

Regarding optimizations:

Could you calculate the min and max corners in modelspace beforehand? Then you could check on the CPU-side the NDCs of these two points and skip the processing of the whole mesh if it is outside of the desired range. This needs only two matrix-vector multiplications on cpu side. And since for rigid bodies these two points do not change over time, you don't have to iterate the meshes in each frame.

> **Comments:**
> **username_0**: I can not calculate min max corner in modelspace as after multiplying with view and projection matrices, min and max corner does not remains the same. that is why I am iterating over all the vertices.Previously I thought just using bounding box would suffice but looks like it is changing in clip coordinate space.  
> **username_0**: when I checked NDC coordinates at the end in both ways, I get very different numbers. with iteration over vertices I get vertex cooridinates in range of minus thousands to plus thousands whereas with bounding boxes they are in range of -10 plus 10 approx.  

---

