Tag Info

New answers tagged

0

You just forget to enable vertex attrib with glEnableVertexAttribArray before calling glVertexAttribPointer int vertHandle = GL15.glGenBuffers(); GL15.glBindBuffer(GL15.GL_ARRAY_BUFFER, vertHandle); GL15.glBufferData(GL15.GL_ARRAY_BUFFER, vertexBufferVAO, GL15.GL_STATIC_DRAW); **GL20.glEnableVertexAttribArray(0);** GL20.glVertexAttribPointer(0, 3, ...


0

You are most certainly trying to use your shader in SpriteBatch. SpriteBatch is setting up the shader's projection matrices, which are by convention (as MadEqua answered) called u_projTrans, not u_projectionViewMatrix (see SpriteBatch source). SpriteBatch also uses some more uniforms which you must declare (and use, so they aren't optimized away). However, ...


1

The individual invocations within a work group will be executed "in parallel". The main purpose of the distinction between work group count and local size is that the different compute shader invocations within a work group can communicate through a set of shared​ variables and special functions. Invocations in different work groups (within the same ...


1

Yes, sending your mesh data to the GL every time you render it would be very wasteful. You should only be doing that if your data has changed from one frame to another (e.g. you are computing animations in the CPU). Otherwise, you shouldn't have to re-submit data if the model/mesh was not changed. Apparently, the problem with your program is that you are ...


2

From the OpenGL wiki: The input_primitive​ type must match the primitive type used with the drawing command that renders with this shader program. Given, Unity is probably using DirectX on Windows, but the same thing should hold true. Because your shader is asking for a point, it is only taking the first point from each primitive and ignoring the rest. ...


0

Inside the trigger : then activate object renderer. Outside the trigger : then deactivate object renderer.


0

Your application is trying to find an uniform in the shader called u_projTrans to send it the projection matrix. The simplest fix is changing this shader line: "uniform mat4 u_projectionViewMatrix;\n"+ to "uniform mat4 u_projTrans;\n"+ Then the variable names should match on both the application and shader sides.


0

There is nothing wrong with the shaders. The error you're getting is due to somewhere in your program your calling a line similar to this: shader.setUniformMatrix("u_projTrans", matrix); Basically this error is thrown when either u_projTrans doesn't exist in that shader or it does exist in the shader but you don't use it. When it's not used the shader ...


1

Why would you consider the wave disappearing unexpected? The shader averages/spreads differences in the heightmap. All it does is basically damping. Each iteration it will flatten out the waves, making them a little less high and a little wider. To have a more realistic wave-propagation you might want to try to use 2 textures. Use one for heights, and one ...


0

My lighting problem was caused by two things. 1.) My input layout's TEXCOORD was set to DXGI_FORMAT_R32G32B32_FLOAT instead of DXGI_FORMAT_R32G32_FLOAT. I suspect that this was behind the weird debug output I was seeing from my shaders, but I'm not sure. and 2.) My light was facing down the negative z axis, instead of the positive z axis. Either of these ...


1

You only have a set of 16 possible textures per-shader stage, so way 1 may get out of hand quickly. You have up to 80 possible unique binding locations in GL4 (16 * 5 stages = 80) and 48 in GL3 (16 * 3), but you can only use 16 of those in a single shader invocation. In truth, bindless textures, array textures and texture atlases have all been designed to ...


0

Use this: // Bind both, the consume buffer UAV and the append buffer UAV to the CS. ID3D11UnorderedAccessView* UAVArray[2] = { mInputUAV, mOutputUAV }; UINT initialCounts[2] = { mNumElements, 0 }; md3dImmediateContext->CSSetUnorderedAccessViews( 0, 2, UAVArray, initialCounts ); just before applying the tech passes in DoComputeWork() public function.


0

This is an old question. However, in the interest of others seeking help with a similar problem, I believe I have a plausible solution: You could have a model prepared for smooth shading (without the duplicate vertices) and present an option of emulating flat shading through your pixel shader. It is possible to calculate the normal at a given pixel by ...


0

Have you tried checking the counter in the append buffer, to see if ANYTHING is being appended? ComputeBuffer argBuffer = new ComputeBuffer(4, sizeof(int), ComputeBufferType.DrawIndirect); int[] args = new int[]{ 0, 1, 0, 0 }; argBuffer.SetData(args); ComputeBuffer.CopyCount(buffer, argBuffer, 0); argBuffer.GetData(args); Then argBuffer[0] should be the ...


3

In the Unity docs under shader references. Shadow mapping macros Declaring and sampling shadow maps can be very different depending on the platform, so Unity has several macros to help with that: UNITY_DECLARE_SHADOWMAP(tex) - declares a shadowmap texture variable with name “tex”. UNITY_SAMPLE_SHADOW(tex,uv) - samples shadowmap texture “tex” at given ...


2

The best way of passing such data to the GPU, using the shaders pipeline, would probably be with a texture. Knowing that, your own question answers it: A texture with one pixel for each node of the tree.


2

Hardware has not always supported floating-point texture formats. In fact, D3D has not always supported depth textures. When you see this sort of thing, it is usually because the application is trying to support an older API or older hardware. To store depth on these systems, they must be converted to fixed-point and packed into 4 channels of a traditional ...


1

First draw your bubbles with basic shader to RenderTarget2D texture. Next draw sprites shat should be blured with custom shader and pass it as BlurMapTexture paramether. In this shader add sampler for blur map: texture BlurMapTexture; sampler2D blurMapSampler = sampler_state { Texture = (BlurMapTexture); MagFilter = Point; MinFilter = Point; ...


0

I solved the problem by using the model matrix: o.worldPos = mul(_Object2World, v.vertex).xyz;


0

Seems I found an issue - I had to change my depth stencil state to make second pass enabled, because by default second pass discarded by depth stencil state.


0

I really doubt that the depth Buffer is inaccurate, the issue is much more likely the the boxes are further than the far pane or your shader is calculating something incorrectly. Anyways XNA has built in functionality for generating a Depth Texture. RenderTarget2D shadowRenderTarget; shadowRenderTarget = new RenderTarget2D(GraphicsDevice, ...


1

The answer is spread across the following links. Due to size constraints / requirements it had to be a Buffer Texture. Overview listing of possible technologies: http://stackoverflow.com/questions/7954927/glsl-passing-a-list-of-values-to-fragment-shader OpenGL reference to Buffer Texture: https://www.opengl.org/wiki/Buffer_Texture Different question but ...


3

You're doing it wrong - very inefficiently. Instead of rendering lightsources to your "lighting framebuffer", render the lighting contribution. That would be a soft disk centered at your light source instead of a single pixel. Example disk: ... and you can render that as a sprite! (Additive blending, clamp to 1 for best results). You can now bind that ...



Top 50 recent answers are included