Tag Info

New answers tagged

0

Fallback "VertexLit" might be hiding an issue with the primary shader, although it looks fine to me. You should probably still remove that line until you know your main shader is working correctly. My other guesses would be that the mesh colors are not being set for some reason. Are you using the .sharedMesh instead of .mesh accessor? There's a lot of ...


1

After you compile and link the shader program you should validate and check the compile and link status'. Anyway, you don't even seem to be compiling the shader sources. Do that and make the checks and it should work. The Compile() function should look more like this: public void Compile() { programId = GL.CreateProgram(); for (int i = 0; i < ...


1

So the short answer is to turn on the debug layer. Thanks to @Nathan Reed for pointing that out. I tested it out and verified that it does indeed detect when shader signatures are incompatible. I also verified that new SV inputs to a shader stage must come last in the list of inputs.


2

They are not equivalent. In the GLSL shader you use the same texture coordinate for your diffuse and normal map (gl_TexCoord[0]). In the CG shader you use separate ones (TEXCOORD0 and TEXCOORD1, which is presumably not set).


3

This effect can be achieved by drawing the blood in two layers. The bottom layer is the black border and the top layer is the red blood. Note that actual "layers" are not required, as long as the drops can draw in two phases, all black, followed by all red. Each droplet draws its shape as a black sprite. Then after all black shapes are drawn, they each draw ...


1

If you look closer - it is not border of(each) blood drops - it is a border of all blood-red area. And I think the border was added actually after rendering blood to look cartoonish. This could be post processing effect just as well as shader. It should not be difficult to implement edge-detection algorithm (plus you know the color you are looking for).


3

Another way to do this is to make a texture that maps each RGB to a colour on the palette, an image like this (from the NES colours): Then in a post processing shader you can the RGB colour from your regular image in a way like this: uniform sampler2d paletteMapping; vec3 mapColor( vec3 realColor ) { vec3 mappedColors = floor( realColor * 16 ); ...


0

This problem is called Color quantization. Basically for each pixel you want to find a closest color present in the palette. This can be done by partitioning the 3D color space into regions each of which containing exactly one palette color. The partitioning can be performed using e.g. Voronoi diagram, octree or any other spatial partitioning data structure. ...


1

To do this, you must sample your alpha texture in the depth buffer creation fragment shader, which is ShadowCasterFP in your code. When you sampled the texture, you should discard pixels below a certain alpha level, or do a clip: if( color.a<0.1 ) discard; clip( color.a<0.1?-1:1 ); //where color is your sampled texture at the current fragment ...


0

As the article states, in the shader you use the luminance value (between 0 and 1, or between black and white) to index the "fire" texture horizontally. This should give you the color that the pixel shader returns: Index the noise texture. This returns a grey color Take any component from the grey color (r, g and b should be the same) Use that value to ...


0

It really depends on what you're trying to render. For example, if you're rendering layers of clouds that are transparent to the background but not necessarily to each other, one useful trick is to draw the background, then non-transparent cloud layers, then draw the background again at 50% transparency over the other layers.


0

This has been resolved. i had the effects file set to 'Compile' instead of 'Content'


0

Shaders in 3D art applications almost never have anything to do with shaders within the game engine. The parts of the model that carry over are fundamentals like the mesh geometry. That said, fairly standard stuff like an alpha channel in the texture (to make parts of the model transparent) usually operate the same way in both places. Alpha transparency and ...


0

The only difference you would have is that you are doing texture lookup based on UV instead of direction. This would mean that each cube vertex would need a uv or you would need a routine to calculate the appropriate uv based on the view direction ... which is basically us back at using texCUBE, with the exception that texCUBE is probably going to be more ...


5

You tell the GPU how to produce triangles from the input data. You specify vertex buffers containing all your vertex data, you also specify a primitive topology (lines, triangles, et cetera) and an optional index buffer. The topology tells the GPU how many and what pattern to take the indices in (for example, in sets of three for a triangle list). The ...


0

Before you get too deep into this project I'd like to comment. It looks like you're drawing the whole cube for each block in the world. If I am wrong, then ignore this, but if I'm right you should definitely consider a more efficient approach. You do want one normal per face, which probably means drawing cubes with 24 vertices (4 vertices per face, instead ...


0

If you would do hard normals for these boxes it would eliminate your problem. For that you have to have a normal not per vertex, but per face. You could do this by having four vertices with the same normal for each face of the cube, that is 24 vertices. That way, a whole face will receive an even amount of light. You also mention that you tried to combine ...


2

Texture Coordinates are usually expressed in the range between [0,1]. Each (textured) vertex will have these coordinates. These coordinates are mapped to texels in the actual texture. [0,0] is the top left corner, [1,1] the bottom-right corner. When the coordinates are in a range that is multiple of 1, the texture will repeat itself. For example, for a ...


0

I didn't check thoroughly, but one major problem I see here is that you aren't following the OpenGL manual: This line of code is never valid: gl.glBindBuffer(GL.GL_TEXTURE0, vboTextureCoordHandle); You must use a valid buffer bind target, in this case GL_ARRAY_BUFFER. As it stands now, you're using your model coordinates as the texture coordinates also, ...


0

I figured out my "EDIT3" problem: I didn't look closely enough at the parameters of glDrawArrays(). Instead of saying gl.glDrawArrays(GL.GL_TRIANGLES, (int) vertices.get(0), vertices.capacity()); I should have been saying gl.glDrawArrays(GL.GL_TRIANGLES, 0, vertices.capacity()); because the middle parameter is the starting point. After that, the cube ...


5

The task is actually highly parallelisable on the GPU. Here is an algorithm that should work, assuming e.g. a 1024×1024 source texture ST. create a 256×256 render target, RT1 run a fragment shader that reads from ST and writes to RT1 and does the following: for each fragment in the render target get the (x,y) fragment coordinates sample 16 pixels from ...


8

Vertex and fragment shaders run concurrently, not sequentially, and the GPU automatically load-balances between them, so it's not possible to meaningfully assign specific timings like 7 ms for one and 1 ms for the other. However, you can do a simple experiment to measure where the bottleneck lies: set the view-projection matrix to all zeros for all your ...


2

mental ray is a stand-alone 3D renderer. It's primarily application domain is film and TV. As a renderer, it supports a concept of "shaders" as functions that compute lighting effects. However, these are not mechanically the same shaders that you'd use in OpenGL or D3D. They are built in their own language, tied to the mental ray lighting and renderer ...


2

It is possible that your issue may be due to the lack of use of the invariant qualifier in your shaders. Quote from the book OpenGL ES 2.0 Programming Guide: There is a keyword introduced in the OpenGL ES Shading Language invariant that can be applied to any varying output of a vertex shader... The issue is that shaders are compiled and the compiler ...


1

Have you verified that all variables used are initialed before using them? Using a variable that you have not yet assigned values to can cause flickering. For instance, if you have a variable that is created like this: vec4 secondaryColor; vec4 color = vec4(0.1, 0.1, 0.1, 1.0); void main() ...



Top 50 recent answers are included