# OpenGL GPU voxelization - Conservative rasterization issue.

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

## Recommended Posts

While implementing the technique outlined in Crassins / Greens work found in OpenGL insights I've run into some issues.

To get proper voxel coverage I need to dilate the triangles before they are sent off to rasterization. As written in the article they are using an older technique found in GPU Gems 2 on conservative rasterization.

My issue is that the my geometry shader projects the triangles using orthographic projections where the conservative rasterization technique only works when using perspective. As far as I can tell.

##### Share on other sites

I don't see why you shouldn't be able to use conservative rasterization with an orthographic projection - the only difference is that you accept all pixels which are ever-so-slightly covered by a triangle (conservative estimate) instead of discarding those with less than 50% coverage. Though obviously the math will be different. In fact, it will probably be simpler since the projection is not as complicated, for instance I would start by getting the triangle's screen-space dimensions. Since this is an orthographic projection, this is trivial and you can just use the post-transformation (x, y) coordinates of each vertex.

At this point you have all the information you need to apply the corrective algorithms (42.2) in the GPU Gems article, obtain the new optimal vertex coordinates, and invert the transformation to get your corrected vertices back into world space (if you need this for rendering - the rasterization step doesn't care and just wants clip space coordinates).

Most of the math at the end of this article concerns how to correct depth as well, since this is important in perspective rendering. However, that's not the case for orthographic projections, as there is no depth to worry about then, so it seems to me that you can ignore all of that.

At least that's my take on it - I've never implemented any of this, just going on mathematical principles and logic here.

##### Share on other sites

I agree that having orthographic projects makes alot of stuff easiere as I can just extend the clipspace vertices directly. The problem lies in HOW much to extend. The article outlines that you'll need to extend along the worst-case semidiagonal. The author uses the fact that a line in clipspace can be represented as a plane through the camera (0,0,0) in projected space and then dilutes along the plane normal - Then to find the new vertex positions they do a plane - plane intersection using a cross product.

I just don't think this works for orthographic projects as all points on a direction vector from the origin doesn't project to a single point.

For reference here my geometry code for the impl.

	// Triangle bounding box.
vec4 f4AABB;

// Compute v0.
vec4 f4CSV0 = m4ViewProj * RF_WORLD * gl_in[0].gl_Position;
f4AABB.xy = f4CSV0.xy;
f4AABB.zw = f4CSV0.xy;

// Compute v1.
vec4 f4CSV1 = m4ViewProj * RF_WORLD * gl_in[1].gl_Position;
f4AABB.xy = min(f4AABB.xy, f4CSV1.xy);
f4AABB.zw = max(f4AABB.zw, f4CSV1.xy);

// Compute v2.
vec4 f4CSV2 = m4ViewProj * RF_WORLD * gl_in[2].gl_Position;
f4AABB.xy = min(f4AABB.xy, f4CSV2.xy);
f4AABB.zw = max(f4AABB.zw, f4CSV2.xy);

// Extend and set AABB.
f4AABB.xy -= vec2(fHalfPixel);
f4AABB.zw += vec2(fHalfPixel);
OUT.f4AABB = f4AABB;

// Compute dialated edges.
vec3 f3Plane[3];
f3Plane[0] = cross(f4CSV0.xyw - f4CSV2.xyw, f4CSV2.xyw);
f3Plane[1] = cross(f4CSV1.xyw - f4CSV0.xyw, f4CSV0.xyw);
f3Plane[2] = cross(f4CSV2.xyw - f4CSV1.xyw, f4CSV1.xyw);
f3Plane[0].z -= dot(vec2(fHalfPixel), abs(f3Plane[0].xy));
f3Plane[1].z -= dot(vec2(fHalfPixel), abs(f3Plane[1].xy));
f3Plane[2].z -= dot(vec2(fHalfPixel), abs(f3Plane[2].xy));

// Compute plane intersections.
f4CSV0.xyw = cross(f3Plane[0], f3Plane[1]);
f4CSV1.xyw = cross(f3Plane[1], f3Plane[2]);
f4CSV2.xyw = cross(f3Plane[2], f3Plane[0]);

// Emit vertex data.
OUT.f3CSPosition = m3Rotation * (f4CSV0.xyz / f4CSV0.w);
OUT.f3Color = f3Color;
gl_Position = f4CSV0;
EmitVertex();

OUT.f3CSPosition = m3Rotation * (f4CSV1.xyz / f4CSV1.w);
OUT.f3Color = f3Color;
gl_Position = f4CSV1;
EmitVertex();

OUT.f3CSPosition = m3Rotation * (f4CSV2.xyz / f4CSV2.w);
OUT.f3Color = f3Color;
gl_Position = f4CSV2;
EmitVertex();

EndPrimitive();

##### Share on other sites

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

## Create an account

Register a new account

• ### Similar Content

• By xhcao
Does sync be needed to read texture content after access texture image in compute shader?
My simple code is as below,
glUseProgram(program.get());
glBindImageTexture(0, texture[0], 0, GL_FALSE, 3, GL_READ_ONLY, GL_R32UI);
glBindImageTexture(1, texture[1], 0, GL_FALSE, 4, GL_WRITE_ONLY, GL_R32UI);
glDispatchCompute(1, 1, 1);
// Does sync be needed here?
glUseProgram(0);
GL_TEXTURE_CUBE_MAP_POSITIVE_X + face, texture[1], 0);
glReadPixels(0, 0, kWidth, kHeight, GL_RED_INTEGER, GL_UNSIGNED_INT, outputValues);

Compute shader is very simple, imageLoad content from texture[0], and imageStore content to texture[1]. Does need to sync after dispatchCompute?

• My question: is it possible to transform multiple angular velocities so that they can be reinserted as one? My research is below:

• I have this code below in both my vertex and fragment shader, however when I request glGetUniformLocation("Lights[0].diffuse") or "Lights[0].attenuation", it returns -1. It will only give me a valid uniform location if I actually use the diffuse/attenuation variables in the VERTEX shader. Because I use position in the vertex shader, it always returns a valid uniform location. I've read that I can share uniforms across both vertex and fragment, but I'm confused what this is even compiling to if this is the case.

#define NUM_LIGHTS 2
struct Light
{
vec3 position;
vec3 diffuse;
float attenuation;
};
uniform Light Lights[NUM_LIGHTS];

• By pr033r
Hello,
I have a Bachelor project on topic "Implenet 3D Boid's algorithm in OpenGL". All OpenGL issues works fine for me, all rendering etc. But when I started implement the boid's algorithm it was getting worse and worse. I read article (http://natureofcode.com/book/chapter-6-autonomous-agents/) inspirate from another code (here: https://github.com/jyanar/Boids/tree/master/src) but it still doesn't work like in tutorials and videos. For example the main problem: when I apply Cohesion (one of three main laws of boids) it makes some "cycling knot". Second, when some flock touch to another it scary change the coordination or respawn in origin (x: 0, y:0. z:0). Just some streng things.
I followed many tutorials, change a try everything but it isn't so smooth, without lags like in another videos. I really need your help.
My code (optimalizing branch): https://github.com/pr033r/BachelorProject/tree/Optimalizing
Exe file (if you want to look) and models folder (for those who will download the sources):
http://leteckaposta.cz/367190436
Thanks for any help...

• By Andrija
I am currently trying to implement shadow mapping into my project , but although i can render my depth map to the screen and it looks okay , when i sample it with shadowCoords there is no shadow.
Here is my light space matrix calculation
mat4x4 lightViewMatrix; vec3 sun_pos = {SUN_OFFSET * the_sun->direction[0], SUN_OFFSET * the_sun->direction[1], SUN_OFFSET * the_sun->direction[2]}; mat4x4_look_at(lightViewMatrix,sun_pos,player->pos,up); mat4x4_mul(lightSpaceMatrix,lightProjMatrix,lightViewMatrix); I will tweak the values for the size and frustum of the shadow map, but for now i just want to draw shadows around the player position
the_sun->direction is a normalized vector so i multiply it by a constant to get the position.
player->pos is the camera position in world space
the light projection matrix is calculated like this:
uniform mat4 light_space_matrix; void main() { gl_Position = light_space_matrix * transfMatrix * vec4(position, 1.0f); } Shadow fragment shader:
out float fragDepth; void main() { fragDepth = gl_FragCoord.z; } I am using deferred rendering so i have all my world positions in the g_positions buffer