Hey guys,

If I project a cube, its outline is given by 6 edges from 6 points. These can change based on either the position of the cube in the screen or the cubes rotation in object space. Is there a quick way of computing the 6 edges or figuring out which of the 6 points form the outline of the cube in screen space? Also, if I subdivide the cube into 8, would the same relative points for the smaller cubes also form an outline for each smaller cubes? Thanks in advance!

i dont know i dont understand but if you manage to know cube point in worldspace then

you multimply each: (model_matrix*view_matrix)*projection_matrix * vertex = VERT - this gives you NDC coordinates which are between -1..1

if you want to compute actual pixel you need to do PixelX = VERT.x * 0.5 + 0.5; //same for y which is your y pixel. i am not quite sure what z was (it gives you the depth, and i forgot alos that you could div all (xyz elements) by w component but i forgot what for.

i dont know i dont understand but if you manage to know cube point in worldspace then

you multimply each: (model_matrix*view_matrix)*projection_matrix * vertex = VERT - this gives you NDC coordinates which are between -1..1

if you want to compute actual pixel you need to do PixelX = VERT.x * 0.5 + 0.5; //same for y which is your y pixel. i am not quite sure what z was (it gives you the depth, and i forgot alos that you could div all (xyz elements) by w component but i forgot what for.

Hmm here let me try to draw it out. I have a cube that I want to project but I want to figure out the 6 edges that make its outline in screen space:

So in this picture, I have 6 edges that I want to find of my projected cube. There are some inner edges when you project a cube but only the 6 that are selected in the picture are necessary to figure out the outline of the projected cube. Is there a way to quickly compute those 6 edges when the cube could be in a arbitrary rotation and a arbitrary position on screen?

Is there a way to quickly compute those 6 edges ... ?

Not knowing how fast "quick" is, IMHO, the answer is "no," as it could require depth-testing/visibility checks, a series of line intersection tests, etc. There are a lot of ways to determine a polygon outline - google for terms like "compute" or "calculate polygon outline" or similar.

However, there may be a better solution to what you're trying to do. I.e., can you describe what problem you're trying to solve, rather than how you're trying to solve it? Depending on your needs, a graphical solution (though not necessarily "quick" or simple) may work.

Sounds like silhouette calculation. For each face of the cube you can calculate whether it is facing toward the camera or away from the camera. Then for each edge of the cube you can calculate if it connects a face that's pointing away and a face that's pointing toward the camera. If so, then it forms part of the silhouette.

Tricky to implement though, because you need to deal with floating point precision issues, and once you've figured out the silhouette edges, working out the correct ordering you want might be fiddly.

"Also, if I subdivide the cube into 8, would the same relative points for the smaller cubes also form an outline for each smaller cubes?" - With an orthographic view, I think yes. With a projection view, I think no.

Is there a way to quickly compute those 6 edges ... ?

Not knowing how fast "quick" is, IMHO, the answer is "no," as it could require depth-testing/visibility checks, a series of line intersection tests, etc. There are a lot of ways to determine a polygon outline - google for terms like "compute" or "calculate polygon outline" or similar.

However, there may be a better solution to what you're trying to do. I.e., can you describe what problem you're trying to solve, rather than how you're trying to solve it? Depending on your needs, a graphical solution (though not necessarily "quick" or simple) may work.

So I'm doing software voxel rendering and I'm storing my voxels as octrees. My idea was to project the root to get the 6 silouhette edges and then for each subdivision, I would extrapolate the childrens 6 edges from the roots. I would traverse front to back and render each visible child and not render occluded nodes and their children. Its similar to this paper here but it doesn't go into how to calculate the cubes silouhette: https://www.cs.princeton.edu/courses/archive/spring01/cs598b/papers/greene96.pdf

I'm not sure how to deal with intersecting polygons though, its not well described in the paper.

Sounds like silhouette calculation. For each face of the cube you can calculate whether it is facing toward the camera or away from the camera. Then for each edge of the cube you can calculate if it connects a face that's pointing away and a face that's pointing toward the camera. If so, then it forms part of the silhouette.

Tricky to implement though, because you need to deal with floating point precision issues, and once you've figured out the silhouette edges, working out the correct ordering you want might be fiddly.

"Also, if I subdivide the cube into 8, would the same relative points for the smaller cubes also form an outline for each smaller cubes?" - With an orthographic view, I think yes. With a projection view, I think no.

For a projective view, I assumed there was a property of projective space where given 2 points and their depth, I can get a mid point but it would require a bit more calculation. I think it would require an extra divide or something due to the 1/z. I have a paper on projective space that I have to read but I'm very sure there is a way of doing it just that its not as simple as a midpoint between two points.

Hmm, okay I get it how that works. That seems tricky to implement but I'll google around for calculating silhouettes. I was previously googling edge computing but that didn't bring up what I was looking for.

The way I thought of doing it currently is cube specific which is fine for my application but I thought that I could calculate the 8 points distance from the cube's center and remove the 2 points which are closest to the cube. So for example:

In the above picture the 2 points which are closest to the center (the ones with the dark blue arrows pointing towards them) would be removed and then I would have the 6 points that form the outer edges. I'm less sure on how to get the edges order from that so that each half place is on the proper side. I was thinking that if I have the points in a array sorted by index and just remove the 2 closest ones, if I made edges by stepping through this array then I would get my proper edges but that might not work under certain rotations.

I think the biggest problem is getting the point order to have my half plane functions set up properly.

So I was rethinking the problem and I think I found a faster way of going about this that still uses the idea of C0lumbo. So I'm using an octree and I figured that the node which is closest to the camera intersects with all of the visible nodes of my cube. Here are some examples:

Using this, I can almost instantly get the 3 faces which are visible to the camera. The problem however are off cases where 2 or 1 face are visible. The issue here is I don't have a quick and dirty way of getting which of these faces are visible so I might have to settle with rasterizing them or maybe using another property but I'm not sure. Below is an image illustrating 2 of these cases:

If anyone has any other idea's, please write a post. I'm going to begin implementing this algo and will post the code later.

This could help: http://www.cg.tuwien.ac.at/research/publications/1999/Fuhr-1999-Conc/TR-186-2-99-05Paper.pdf

so is the topic answered? no? with that mvp*vertex you compute the vector on the screen space whioch is your edge i dont know what could be even faster

This could help: http://www.cg.tuwien.ac.at/research/publications/1999/Fuhr-1999-Conc/TR-186-2-99-05Paper.pdf

so is the topic answered? no? with that mvp*vertex you compute the vector on the screen space whioch is your edge i dont know what could be even faster