Tag Info

4

I am still not 100% sure, if I understood your question, because of this sentence: Now however with orthographic projection the far and near plane are of the same size, so we can't calculate the direction of the cursor this way. The direction is going to be equal the world's z axis. (I haven't had much sleep so I hope this makes sense). If I misunderstood ...

3

The standard solution is to reduce the amount of per-vertex data by only specifying the 4 indices that have the highest weights (and rescaling the weights to add up to 1.0). That way, you can pass 4 weights as a vec4 and 4 indices as a uvec4. Also, you should pass the weights as normalized shorts (or bytes if you can accept the quality loss) and indices as ...

3

This question and its answer, actually answer my question. I had to read its answer carefully and find my mistake. Now my fragment shader look like this: const GLchar* fragmentSource = R"glsl( #version 330 core in vec2 TexCoord; uniform sampler2D ourTexture; #define PI 3.141592653589793238462f #define TWO_PI 6....

3

The problem with your code is, that it produces a lot of degenerated triangles. The not so obvious ones are at the top and bottom. The obvious ones are at the "wrapping line". So what exactly is the problem? Each of your faces is a rectangle that consists of 2 triangles and 4 points. The 2 triangles share 2 points and each one has 1 individual point. But at ...

3

There are 2 ways to go about intersecting the triangle. Let the vertices of the triangle have positions $v_1, v_2, v_3$. Let the ray have origin $o$ and direction $d$. Let the model (4x4) matrix be $M$. To find the new vertex coordinates one extends the positions with a 1 (to allow for translations) and multiplies by the model matrix. Let \$u_i = (v_{i,x}, v_{...

2

There are a couple of issues. First you need to make sure that veBuffer has the correct type, so that probably means you need to cast it to pointer to vertex: const auto vertices = reinterpret_cast<const Vertex*>(reBuffer); Second a range-based for-loop needs to know where the range ends and giving it a raw pointer does not provide that information, ...

2

If using the new real-time ray tracing functionality is an option for you, it would be worth a try! It might be that getting it to run is less work than porting your CPU data structure into a GPU-compatible format. Furthermore, using the hardware functionality would result in much better performance since BVH traversal (and triangle intersection, if that is ...

2

Outside of GL_R11F_G11F_B10F, 3-channel formats are not allowed for image load/store. And you'll note that rgb32f is not in the list of valid format qualifiers for GLSL variables, nor are any other 3-channel formats (except r11f_g11f_b10f).

2

OpenGL 4.1's glGetProgramBinary and glProgramBinary exist for this purpose. The first one retrieves a binary that represents the compiled program in its entirety (though none of the state stored within it. It, and its implementation-defined format, can be stored and reloaded via glProgramBinary. Of course, there are limitations. Implementations are not ...

2

After trying everything possible I found my mistake: The shaders are fine, the only thing which is wrong is the frameBufferObject binding. To be honest, the texture to FBO binding. the only thing I replaced is this: glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_CUBE_MAP_POSITIVE_X, m_cubeMapTexture, 0); glFramebufferTexture2D(...

2

You can modulus by row length to retrieve the x coordinate (think about the x coordinate "wrapping around" after each line), and division by row length to get the y coordinate (inverting the multiply you have by imageWidth). We subtract one from the width and height to ensure the last pixel in the row/column maps to 1.0. Note that this isn't "...

1

What could be the purpose behind that? Have a look at the first lines and the first image in the Perspective Projection section of this link. For the answer to your question, it is not important that you used an orthographic projection, even though there is also a corresponding section in the link. The issue is how OpenGL defines its coordinate systems. ...

1

I'm assuming your scene is constructed based on right-handed coordinates. If you are using OpenGL, yes. If you are using Direct3D, no. The projection matrix maps [-n, -f] into [0, 1]. This weird property comes from the fact that the eye coordinates are right-handed, but the clip space (NDC) uses left-handed coordinates. Hence the implementation of ortho(). ...

1

Everything in this code functions as intended, until I try to translate the entire grid (grid lines) to the center of the screen by adding v_Resolution.x / 2 to uv.x. Not sure what your intention is here since the Shadertoy example you referenced generates an infinite grid. So maybe you can clarify that. However, I think I can help you with this problem: .....

1

This code below can cause an 8bit overflow. auto traceRay = [&](const point_t O, const vec3d D, const int min, const int max) -> color_t { ... return color_t{uint8_t(closest_sphere.color.r * total_light), uint8_t(closest_sphere.color.g * total_light), uint8_t(closest_sphere.color.b * total_light), 255}; Here ...

1

It looks like the parameters to your camera class are not correct const int img_ratio = 2; ... Camera<float> cam1(20.0f, img_ratio, Point3<float>(0.0f, 0.0f, 0.0f), Point3<float>(0.0f, 0.0f, -1.0f), Vec3<float>(0.0f, 1.0f, 0.0f)); In your code you set img_ratio to 2, I would expect it should be something like img_width/img_height (...

1

This looks like the VkFormat being selected for the VkSurfaceFormat, most likekly VK_FORMAT_R8G8B8A8_SRGB. Try VK_FORMAT_R8G8B8A8_UNORM for the VkFormat with a corresponding colorspace (like VK_COLOR_SPACE_SRGB_NONLINEAR_KHR). That should give the dark color you are expecting.

1

This more or less a long comment than an answer. Some other options that come to mind are the following: A little old school, but you can create an interface with one of the texture objects. You can query different mipmap levels for your needs inside the shader. Textures are one of the better cached objects in OpenGL. You can defer the lightening process ...

1

Assuming that alpha works properly in the rest of the code it can be solved on shader level: out vec4 color; in vec2 uv; uniform sampler2D tex; void main() { color = texture(tex, uv); color.a = 0.0; if (all(greaterThan(uv, vec2(0.0))) && all(lessThan(uv, vec2(1.0)))) { color.a = 1.0; } }

1

The accessor (model.accessors[accessor_index]) has its own byteOffset and count values that you need to account for here. The input and output accessors are allowed to share a bufferView, and your output is showing a dump of the same entire bufferView twice. The first five values in that dump are the input accessor with the times (in seconds, since the ...

1

I think what you want for this is to create a descriptor table which lists your textures. The individual textures would be created and uploaded as ordinary Texture2Ds. You'd set up the root signature of your shader to bind your Texture2D[] in HLSL to a contiguous range of SRV descriptors from a descriptor heap. Then, when you create the SRVs for your ...

1

I don't know, why you consider your first approach hacky, but an alternative would be to analyze the shape of your brush and how it interacts with your underlying data structure. For example for your rectangle: Let's assume the brush's sides are parallel to the sides of the image. Then you can calculate how man pixels are covered by your offset d. Let's call ...

1

The eye position (a vec3) was being bound to the wrong shader, resulting in the glUniform3 error when OpenGL (mesa) checked the validity of the uniforms. The error was due to a typo; I named my simple-mesh and animated-mesh shaders similar things. glUseProgram(smesh_shader.get()); smb.predraw(); glUniform3fv(mesh_shader.uniform("eye"), 1, &...

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