New answers tagged glsl
1
Unless you are pre-transforming all of your vertex data, vertices should come into the vertex shader in object/model space. This is typically where the vertices are converted into screen space by transforming the vertex by the world, view, and projection matrices. If you want to perform operations on the vertices in world space, then either pass through the ...
2
This is solved in diffrent ways, some solve it by using #ifdefs, some solve it by branching And some solve it by having input values that updates per every object so you store an overall painting scheeme for the defualt shader.
and when it comes to scale of the game, it´s actualy no way around this. You will need more shaders for diffrent materials and ...
2
How do I use the engine's vertex shader while still allowing the programmer to provide his/her own vertex shader for other calculations in their game? What is the normal approach here?
There is no normal approach because engines generally don't let you do that.
Generally speaking, engines take one of two approaches: either the user provides none of a ...
2
Higher-end engines typically use a higher-level abstraction than an individual shader.
Simpler games just allow each model/material to specify shaders and then to use HLSL includes or the like to allow all common code to be easily reused. You'll need a bit of discipline in applying the shader includes properly and it can be a bit repetitive sometimes, but ...
0
For refraction, you need to render the background to an offscreen buffer. Then draw it on screen. Finally you draw the water on top and pass the background texture into the water shader.
In GLSL you can use gl_FragCoord to get the onscreen coordinate of the pixel. You will have to divide by the background texture size to get the uv for the texture lookup.
...
0
Any idea or help about this shader effect ? I found a couple of idea but I don'r know if they are great : GPUGems - Refraction
1
This is just using regular old sine and cosine to step around the circumference of a circle and place points. You just need to know the center of the circle, the radius and how many points you want. The following pseudo code will output a set of points that make up the positions of dots you need to make a circle of points:
circleXY(Vector3f center, float ...
0
The problem is the texture coordinates. Ogre store the data in attribute vec4 uv0; So in the vertex shader:
gl_Position = mvp_matrix*position;
texCoord = uv0.st;
Solve the problem
5
You can't do it with just that information. You need more.
For example, I assume you also actually have a the world, view, and projection transformation matrices available to you. In that case, you can compute the vertex's position in view space by multiplying it by the world matrix and then by the view matrix.
Since you're in view space, the eye is at (0, ...
0
You can achieve what you wish, but not the way you're thinking of doing it.
If you want to output a common depth for all fragments belonging to a primitive, you can add an extra vertex attribute - say, the midpoint of the primitive - which can be a per-instance attribute (if using instancing) or an extra per-vertex attribute (or even set via a ...
1
As Lewis said, fragments are processed in parrallel, each fragment shader is executed once per fragment. In GLSL there are three ways to communicate between your application and your shaders:
uniform variables: variables that are set from user code, but only are allowed to change between different glDraw* calls. Uniforms can be queried and set by the ...
5
If you mean: Can I compute a variable in the first fragment and pass it around? No, not like that. The fragments are processed in parallel.
If you need to do that, compute the variable CPU side and pass it in as a uniform. If you needed to do a lot of computation you could output to a texture or a buffer and then read it back, but you only need one float ...
0
I'm not really sure what exactly you hope to achieve, the proposition sounds sketchy.
In any case, I'm pretty sure you get your error for trying to calculate the dot product between a vec4 and a vec3. The mathematical dot product is only defined for vectors with the same number of dimensions, most programming languages mirror this.
2
As you already have a delta time in seconds, and also the 'speed' of the texture in whatever units you use per second, then you simply need to move the texture by the speed (0.001) multiplied by the delta in seconds. Say if you have a delta of 0.5 seconds, the movement would be 0.0005, which is what you want.
To implement it in your program, change
...
1
vTime is a float, but you're passing it as an int, since you're using glUniform1i(). Adding integer values to your texcoords has no effect.
Use glUniform1f() instead.
1
To answer my own question, here's what I got working:
The scaling in the GLSL vertex shader is:
gl_PointSize = (heightOfNearPlane * pointSize) / gl_Position.w;
Where you compute your heightOfNearPlane using the viewport height and the field-of-view angle you constructed the perspective matrix with:
float fovy = 60; // degrees
int viewport[4];
...
Top 50 recent answers are included
