<p>Since the cube is a convex object, you could first find the silhouette edges of the cube, by using dot product between cube face normals &amp; view vectors. Then you can sort the edges by the smallest screen y-coordinate for each edge and rasterize the cube a scanline at the time by filling the span between two active edges for each scanline. For each scanline you progress the two edges by adding the edge slopes (x1-x0)/(y1-y0) to the current x-coordinate of the edges.</p>

CC BY-SA 3.0
2016-11-13T16:58:26.610Z
2016-11-13T17:03:28.437Z
2016-11-13T17:03:28.437Z
JarkkoL
<p>Given a cube defined as:</p>

<pre><code>struct Cube
{
    float min[3];
    float size;
};
</code></pre>

<p>What would be the fastest rasterization method? On the internet I only found methods that used polygons, but I think for only drawing a cube thats extremely ineffective. I don't need any depth information, I want the result to be a shadeless silhouette. </p>

CC BY-SA 3.0
2016-11-13T15:56:04.997Z
Is this rasterization happening on CPU or GPU? Also I'm curious if there's a reason you need it to be faster than polygons as it might help shape an answer. Thanks!
Alan Wolfe
CC BY-SA 3.0
2016-11-13T17:13:38.957Z
GPU, OpenCL. Also why shouldn't it be faster than polygons? Why should I be looking for an algorithm, that's slower than polygons? :)
l'arbre
CC BY-SA 3.0
2016-11-13T17:22:36.353Z
Faster vs just using polygons hehe.  As in... Do you have an actual usage case where you need an algorithm faster than triangles? If so, what are the details of that usage case. If it's just curiosity though, that's fine too.
Alan Wolfe
CC BY-SA 3.0
2016-11-13T17:44:16.733Z
Im trying to rewrite my voxel octree raycaster to a work without raycasting..if you know, what i mean. I dont want to use polygons since it seems stupid, rendering 12 individual triangles for the sake of rendering a cube, that by itself is only defined by 4 numbers and has itself some limitation of course, like rotation being impossible to be applied directly to the cube, which on the other hand is something i dont need for my renderer.
l'arbre
CC BY-SA 3.0
2016-11-16T01:07:35.150Z
it feels like maybe you could translate the 3d points and project them into 2d (think: x/z, y/z types of transforms), and then you could use some "convex hull" finding algorithm on the points to come up with a 2d poly, instead of starting with triangles.  The fact that it's symmetric (since it's a cube) likely means you can do less work than transforming all of it's 8 points, or even rasterizing the whole thing.  You can likely rasterize half or a quarter, and mirror it or something.
Alan Wolfe
<rasterizer>
Non-Polygonal 3D cube rasterization
l'arbre
# Non-Polygonal 3D cube rasterization

(Asked by: username_0 on 2016-11-13)

Given a cube defined as:

```
struct Cube
{
    float min[3];
    float size;
};

```

What would be the fastest rasterization method? On the internet I only found methods that used polygons, but I think for only drawing a cube thats extremely ineffective. I don't need any depth information, I want the result to be a shadeless silhouette.

**Tags:** rasterizer

> **Comments:**
> **username_1**: Is this rasterization happening on CPU or GPU? Also I'm curious if there's a reason you need it to be faster than polygons as it might help shape an answer. Thanks!  
> **username_0**: GPU, OpenCL. Also why shouldn't it be faster than polygons? Why should I be looking for an algorithm, that's slower than polygons? :)  
> **username_1**: Faster vs just using polygons hehe.  As in... Do you have an actual usage case where you need an algorithm faster than triangles? If so, what are the details of that usage case. If it's just curiosity though, that's fine too.  
> **username_0**: Im trying to rewrite my voxel octree raycaster to a work without raycasting..if you know, what i mean. I dont want to use polygons since it seems stupid, rendering 12 individual triangles for the sake of rendering a cube, that by itself is only defined by 4 numbers and has itself some limitation of course, like rotation being impossible to be applied directly to the cube, which on the other hand is something i dont need for my renderer.  
> **username_1**: it feels like maybe you could translate the 3d points and project them into 2d (think: x/z, y/z types of transforms), and then you could use some "convex hull" finding algorithm on the points to come up with a 2d poly, instead of starting with triangles.  The fact that it's symmetric (since it's a cube) likely means you can do less work than transforming all of it's 8 points, or even rasterizing the whole thing.  You can likely rasterize half or a quarter, and mirror it or something.  

---

## 1 answers

### Answer by username_2 on 2016-11-13. Score: 3

Since the cube is a convex object, you could first find the silhouette edges of the cube, by using dot product between cube face normals & view vectors. Then you can sort the edges by the smallest screen y-coordinate for each edge and rasterize the cube a scanline at the time by filling the span between two active edges for each scanline. For each scanline you progress the two edges by adding the edge slopes (x1-x0)/(y1-y0) to the current x-coordinate of the edges.


---

