# Tag Info

5

The block should total up to 8320 bytes. No, it shouldn't. You use a uint[16] array. Well, std140 layout makes it clear that the array stride for any array is always rounded up to the stride of a vec4. So that array takes up 256 bytes. You should instead use a uvec4[4] instead, which you would index from like a multidimensional array.

4

There is no such thing as a core profile in GLSL 1.30. The concept of API profiles was introduced with OpenGL 3.2 which happened after GLSL 1.30 was released. The syntax for the version specification in GLSL 1.30 is #version <number> Apart from that, I highly recommend that you check to confirm that GLSL 1.30 really is the maximum version you're ...

4

IEEE-754 defines the isNaN property, which determines if a value is NaN. However, it is also defined to be a non-signaling operation; calling isNaN on an sNaN will never result in a signaled failure. By contrast, equality testing may signal when given sNaN values. Now, GLSL explicitly states that signaling doesn't matter: Support for signaling NaNs is ...

3

Operating systems cancel GPU program executions if they take too long. On Windows it is generally two seconds and on Linux it is five seconds most of the time, but it can vary. This is to detect GPU programs that are stuck and cancel them. There are different methods to get around this timeout, but they all require admin/root privileges, which is not always ...

3

No, g++/gcc are not involved. In OpenGL (prior to Vulkan), GLSL code is submitted to the driver as source code strings via a glShaderSource call. The driver is fully responsible for compilation, i.e. the driver must provide a built-in GLSL compiler for that GPU architecture. This would typically happen on startup of an app, or during level loading for a ...

2

If you want to prevent cracks between the tessellated lines in a single curve, what you need to know is how to miter the quads correctly. Your GS's extrusion is presumably based on taking the 2D perpendicular to the line direction and extending the quad in that direction. Well, don't do that. Instead, have the TES compute the perpendicular direction for ...

2

It looks like you're drawing with pre-multiplied alpha. This means that the red, green, and blue channels have been multiplied by the alpha channel. So your shader should look more like this: precision mediump float; uniform sampler2D uSampler; varying vec2 vTextureCoord; void main() { vec4 originalColor = texture2D(uSampler, vTextureCoord); vec4 ...

2

When creating a OpenGL context you have to specify a profile mask, which is a way of telling the driver whether you want to use compatibility ("legacy") features or not. Drivers are required to implement all core profile features, but compatibility profile is optional - creating a compatibility context can fail even if the driver supports the version you've ...

2

Suballocating from a larger buffer is absolutely the way to go, with caveats. I'm coming more from a DirectX/Vulkan side of things, but this should apply equally to OpenGL (I just won't have direct API calls here in this answer). The things to consider are the following: Do you need to index into the larger buffer, or are you OK with binding the resource to ...

2

The simplest solution would be just a multiplication, which would give black edges: combinedColor = sceneColor * edgeRGB.r; For more control I would suggest something very similar to what @PaulHK proposed in the comments: float opacity = maxEdgeOpacity * (1. - edgeRGB.r); combinedColor = mix(sceneColor, edgeColor, opacity); edgeColor is the desired edge ...

1

Turns out I needed to be looking at the former normal as a unit vector $(\hat{r}, \hat{\theta},\hat{\varphi})$, and then use a rotation matrix as outlined here to find $(\hat{x},\hat{y},\hat{z})$.

1

Turns out it had to do with the V vector working differently in deferred rendering than it does in forward rendering, something that I overlooked and seems obvious now. Specifically, I passed the view direction calculated in the camera class to the lighting pass fragment shader then negated it like so vec3 V = normalize(-(cameraPosition - v_pos));. Things ...

1

I finally found the problem. My precalculation was done with pixel coordinates from 0 to res[0] - 1 (i.e. the resolution width): for (int i = 0; i < res[0]; i++) { for (int j = 0; j < res[1]; j++) { reinterpret_cast<float*>(img->data(i, j))[0] = i / res[0]; reinterpret_cast<float*>(img->data(i, j))[1] = j / ...

1

This question is a bit too broad to answer, but I'll try. Right now you have a screenshot and you are not really sure whether it's correct or not, and if it turns out it is not, it will be difficult to know what is incorrect about it. I would recommend to split your problem into smaller, isolated, problems that can be validated separately. For example, is ...

1

Because you are working on screen space, the view ray points towards the eye (being Z the camera space depth). In order to create an orthonormal base, the vectors must be perpendicular to each other. To do this, you set the coordinate z to 0 for the tangents and bitangets, which ensures these vectors will live in the plane perpendicular to the view ray. ...

Only top voted, non community-wiki answers of a minimum length are eligible