Hot answers tagged

72

There are two types of normal maps commonly used in game development. The way you are thinking they should work is the way one type works (model-space normal maps), but most games use another type (tangent-space normal maps) which is why you associate mostly-blue textures with normal maps. With model-space normal maps, each channel encodes the precise ...


31

Short Answer Normal maps and Normals are two different things: Normals are a geometric property of any mesh/surface its use is not exclusive for shading and lighting calculations but have actually many other uses for example in physics. Normal maps are textures that encode alternative normal vectors used in computer graphics to simulate bumps. Long Answer ...


28

You could easily find the normal by calculating two vectors, V1 = P2-P1, and V2 = P3-P1, and then find the cross product N = V1 x V2. Then you normalize N. Depending on the ordering of the vertices (clockwise or counterclockwise) you will get a normal facing front or back. You also need to make sure that three three points aren't aligned, if they are you ...


9

This isn't caused by your UVs or by your normals. The problem is triangle interpolation, and it's a very common problem for quad-based heightmaps. Here's a closeup of a small portion of your screenshot (slightly contrast-enhanced on the right, to show the problem more clearly): As you can see (slightly to the northwest of the two red dots), the problem is ...


8

The normal map mostly points outward from a surface. Assuming you go with the usual mapping of the Z component of the XYZ normal vectors being the "depth" direction and an that mapping to the B component of the RGB color space, you'll end up with most normal vectors being primarily blue. If the texture were, say, red, then that would mean that the normal ...


7

When a matrix is orthogonal, inverse and transpose are equivalent making an inverse transpose equal to the original matrix. So if your model view matrix is orthogonal, the normal matrix will be equal to it. As user41442 pointed out, in most cases modelview matrices are actually orthogonal so this can be a bit of a short hand. There's still cases where it's ...


7

vec3 norm = vec3(uViewMatrix * uModelMatrix * aNormal); The normal cannot be transformed like a point, to transform a normal you use the inverse transpose matrix. If you want the fun details of why this is here is a qoute from the OpenGL Red Book that explains it better then I ever will: Mathematically, it's better to think of normal vectors not as ...


6

For a triangle with points p0, p1, and p2, and normal n, you’ll need to compare the vectors cross(p1 - p0, p2 - p0) and n. They should either point in the same direction, or in the opposite direction, for all triangles in your mesh. Suppose your convention is that the vectors must point in the same direction. The algorithm is simple. For each triangle, ...


5

I think the following may help. You have the sphere center, box center and hopefully the details of the rectangle. Since the rectangle may be rotated we need the rectangle extents, and the orthogonal unit vectors, e.g. Now we need the closest point on the rectangle to the point c. vector d = c - r; // project d onto ux to get distance along ux from c ...


4

By looking at your picture your problem seems that you need to smooth(average) your normals. That is when a vertex is shared by multiple triangles and yet has one normal you have two options to deal with this problem: Smooth edges: You calculate the normal of each vertex for each adjacent triangle and then average them. Hard edges: You duplicate each ...


4

You are seeing interpolation artifacts. The surface normals between front and back faces are interpolated between front and back faces, leaving some of the fragments on visible faces having normals facing away from the camera. Consider this crude drawing: In this image A and B are your vertex normals while C is an interpolated surface normal between them. ...


4

Solved using teodron's suggestion. Slope is now set to float slope = length(vec2(normal.x, normal.y)); and it works perfectly. Here is the result:


4

Your problem is in your Light vector calculation. vec3 lightpos = vec3(15.0, 26.5, 0.5); vec3 L = normalize(lightpos - vVertexCoord); Here lightpos is in World space, whilst vVertexCoord in is Object space. You need all your operands in the same space. Furthermore your TBN matrix(its not TNB) is wrong., it should be as follows: mat3 TBNmatrix = transpose(...


4

A space is not just an axis though. Tangent space has 3 axes: the U tangent, the V tangent, and the normal. In your illustration you add an offset to the normal. But how do you know which direction to offset it? That's what tangent space defines. If the normal is Z, the tangent space gives you the orthogonal X and Y directions in which your offset ...


4

Essentially, the normal of the vertex would be the average of the adjacent faces' (triangles) normals. In pseudocode: for each face adjacent to vertex[n] sum = sum + face.normal normal[n] = NORMALIZE(sum / COUNT(adjacent faces)) Repeat for each vertex.


4

It's common for people to compute lighting in eye space because of how the specular component of lighting in the Phong model is calculated. Doing the calculation in view space, allows you to avoid a vector subtraction in the vertex shader, a basically negligible optimization. If you were instead to do the calculations in world space, which you absolutely ...


4

To me it looks very much like your issue here is that you are mixing world and viewspace or something similiar. Now your GBuffer normals look like they might be in viewspace in that picture, but the code in your geometry pass definitely doesn't transform them from world to view space. If they are in world space then your NBT matrix is basically oriented ...


3

The way you are computing vertex normals only considers an individual quad and not its neighbours. Thus you get the discontinuities between the somewhat flat quads. If you want smooth normals, the way to compute them is to consider the gradient of nearby vertices on your grid. If you've got points on the form a-b-c | | | d-e-f | | | g-h-i then you want ...


3

There is nothing inherently wrong with your original code when it comes to normalization. The only problem can be with meshes that do not properly share vertices, meaning your normalization code will always normalize the vertices that belong to a single Triangle. If you wish to fix such a mesh, you should either: Weld all vertices during import stage Apply ...


3

You need to edit your shader source file in order to add "Cull Off" inside, more info here If you are not writing your own shaders (and so use default provided Unity shaders) then you can look at proposed solutions here


3

I'm not sure why you say the suggestion in the comments "gets worse" - I implemented it and it performs as expected: In each of these examples we have the same cubic spline being wrapped in a tube mesh, using a calculated normal to the spline at each point to decide the orientation of each tube cross-section. I've marked the 0, 90, 180, and 270-degree ...


3

Imagine applying a force along those normals to the faces. If the normals both face in the same direction (e.g. outward), then it would have a book closing effect, the faces would get closer. If they faced in different directions, it would just rotate the whole thing. To make this a little easier to implement, you need to make it more abstract. The concept ...


2

To try and make reasonalby comple mathematical theory sort and concise: it is because the Normal is actually a co-vector rather than a vector. The difference between a covector and a vector is that a co-vector defines an opposite 'handedness' on sign reversal, while a vector defines an opposite 'direction' on sign reversal. For instance, reversing the normal ...


2

Minimal example that illustrates some details of how glNormal works with diffuse lightning. The comments of the display function explain what each triangle means. #include <stdlib.h> #include <GL/gl.h> #include <GL/glu.h> #include <GL/glut.h> /* Triangle on the x-y plane. */ static void draw_triangle() { glBegin(GL_TRIANGLES);...


2

The way you calculate your normals, you end up with this because you take the cross product of the triangle sides. Where red circles are normals pointing directly at the screen. Sideways it looks like this (both black lines are triangle faces seen from the side) Notice how for every face, the vertices that make it up are parallel to each other. Because ...


2

You can use the slopes between vertices instead of the triangle normals to average the vertex normal. This could be easily ported to the GPU if you have vertex shader texture fetch support. Gottfried Chen sums it up here with code: http://www.flipcode.com/archives/Calculating_Vertex_Normals_for_Height_Maps.shtml


2

No, you cannot mix different primitive types in the same shader / draw call. If you're drawing triangles, you can't also draw line segments. To draw face normals like this, you could do a second draw call with a geometry shader that generates the line segment for each face.


2

The performance difference will depend a lot on the hardware you're using, the only way to be sure is to test it. Technically you don't need a vertex buffer or index buffer at all - you can generate the position in the vertex shader in DX10/11, based on the integer index of the vertex. You can of course also skip the transform, by passing coordinates ...


2

You're unlikely to be bus-limited or vertex-limited on current or even recent hardware; except in extreme and unlikely scenarios, fillrate and ROP will kick in a lot sooner. If omitting normals gets your vertex size below 32 bytes that can be a win. If you still need some kind of shading, you can get normals down to 4 bytes (instead of 3 floats) by using a ...


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