Hot answers tagged

4

1) Scale the texture coordinates from [0,1]x[0,1] -> [0,3]x[0,3]. It works with higher integer scales as well. This creates an imaginary 3x3 tiles grid. st *= 3.; 2) Split the upscaled texture coordinates into the integer part and its float reminder. vec2 i_st = floor(st); //the tile coords of the fragment - an integer pair {0,1,2}x{0,1,2} vec2 f_st = ...


3

You might want to check matplotlib-cpp. You'll find a "funny-looking xkcd-styled example" in the README. I also saw xkcd related entries on matplotlib's Python documentation. So, it should be available in Python too. However, I did not use these libraries myself. I just stumbled upon matplotlib-cpp while I was looking for a plotting library for C++....


3

A texture that stores distance from the edge of the shape, like you described, is called a "distance field" (you'll find lots of results if you google that phrase). Distance fields can be calculated efficiently on the GPU using the jump flooding algorithm (JFA). This is a multi-pass algorithm that works by sampling pixels at a distance of first ½ ...


3

On current GPU architectures, at the machine level, compilation of a shader program can depend on which other pipeline stages are active, what the inputs/outputs to those shaders are, as well as what the inputs and outputs of the overall pipeline are (vertex inputs and fragment outputs, for example). There's a lot of complicated architectural reasons why ...


3

Does Vulkan have the equivalent of the OpenGL separable shader objects, or are there any plans for it? They seem just so much more flexible. It would be "so much more flexible". But Vulkan is a low-level rendering API. It's job is to give you access to the hardware as close to the metal as possible; user-convenience isn't even in the top-5 goals ...


3

The reason why ray-tracing is often used for achieving as-realistic-as-possible wet appearance is their reflective behavior. A thin liquid film on the surface reflects photons like a mirror. If you target real-time rendering, you will have to fake the reflections (or rely on RTX :) There are two ways I can quickly think of: placing reflection probes in the ...


3

You tile idea seems to be a good one to cut down on local complexity. You can't reasonably evaluate every primitive everywhere. Not if you want good performance anyway. So you need a simplified version for each tile, where you remove elements which have insignificant contribution. This is an interesting problem of its own. A simple version of this would be ...


3

I fully agree with all other replies and comments that rgba is definitely faster as it reduces the number of fetches from 16 to 4. You can even omit the per-element assignment: //I also fixed the typo in Matric[i]es m[0] = texelFetch( projMatrices , ivec2( 0 , lightIndex ) , 0 ); m[1] = texelFetch( projMatrices , ivec2( 1 , lightIndex ) , 0 ); m[2] = ...


3

It should be significantly faster to sample one RGBA value from one location in a texture than four R values from different locations in the texture.


2

The easiest way to deal with this would be to provide thickness for the edges in the continuous setting. That is, make your edges out of solid capsules/cylinders, then you would not have this issue. Technically, this is is neither a supersampling nor a filtering technique, but rather a reformulation of the problem in the continuous setting. Another ...


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

Flood filling is not a very GPU-friendly operation to begin with, and the algorithm described in the paper is not a very good way to go about flood-filling on the GPU either. It might be possible to make it happen with some heroic efforts and compute shaders, but if flood-filling is what you want to do, I would use a different approach altogether. For ...


2

Your actual result is correct in terms of what you can achieve in a single-pass with a fragment shader. It calculates the distance of the fragment's world position to the line segment. That distance is different for each fragment so the stretched black ellipsoid is the correct output. A fragment shader has only local information about the current fragment ...


1

Here is a (mostly) minimal version of an SDF for a line segment using a signed distance field as suggested in the comments. I take no credit for this code, it is your function pieced together with IQ's SDF function done in the style you listed above. Be sure to go to IQ's website, it is one of the best learning resource out there for this material. Though it ...


1

Consider #include. We use the tools provided by Khronos to make our own compiler that is part of a larger tool providing lots of specific functionality. Like handing out binding numbers, compiling spirv into linkable objects (with the restriction noted above), and others to numerous to mention here. If linking smaller SPIRV code snippets into a larger SPIRV ...


1

What you want is generally not possible for OpenGL's SPIR-V support. SPIR-V compiles to shader objects, and shader objects theoretically allow you to link multiple objects of the same stage in a program. However, OpenGL's usage of SPIR-V requires that each SPIR-V shader be a complete shader stage with its entrypoint function. So the requirement of shaderc ...


1

Ok. So Finally, I have solved the problem. This problem I been working on for a couple of weeks. Had to go through several books in math, gamedev etc. Went through all my code, to see if I had something I did missunderstand. Finally I found the problem! I was trying to store normals in the texture, with values between [-1, 1], I did not think about the ...


1

You're not correctly inverting the mapping you used to store the depth value. When storing it you use: vDepth = -(vPos.z - NearPlane) / ( FarPlane - NearPlane); Then you reconstruct it as: const float depth = normalDepth.w * (FarPlane - NearPlane); but this misses both the offset by NearPlane, and the negative sign to flip the Z axis (since it points out ...


1

This can be caused by the compiler creating unsigned bytecode. For the compiler to sign the bytecode, you have to have a copy of dxil.dll in the same folder as the dxcompiler.dll at runtime. See Using the GitHub dxcompiler.dll for some more info. The dxil.dll is available in the official DXC releases.


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