Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 21 Oct 2011
Offline Last Active Yesterday, 02:08 AM

Posts I've Made

In Topic: Problem with lighting artifacts from hidden faces in my scene.

28 July 2015 - 06:02 AM

One "workaround" I came up with was to simply delete the side faces of the model entirely, and the issue goes away. This isn't ideal though and I'd much rather have a programmatic solution.


On the contrary, that IS ideal, because you are sending less data to the graphics card. You should only draw the sides of a tile when there is no adjacent tile on that side.


Anything I've read about z-fighting previously usually refers to 2 faces along the same plane having the issue


In your case, the z-fighting happens between the white side-face of a tile in the back, and the red front-face of the adjacent tile drawn in front of it. The reason is that the z-values (or "depth values") that are computed at the position of those white pixels for the two faces are equal. This is because the Z-values are stored as floating-point values in the Z-buffer, and the floating point rounding precision causes the two depth values to be the same.


The issue might also go away if you draw all of the front faces first, then all the sides, but you probably also have to enable enable Z-bias (also called "depth bias") for it to work. But as I said before, there is no point in drawing hidden faces, unless you also want to enable some kind of transparency later on, in which case you will have other issues to deal with.


You could also try increasing the Z-buffer precision if you can (from 16-bit to 32-bit floating points), but that will only decrease the amount of z-fighting - it will not fix it permanently.


And you should also make sure that the near and far planes of your viewing frustum are not too far apart. The Z-coordinates that span the range from the near plane to the far one are all compressed into the [0.0, 1.0] interval when placed in the Z-buffer. So the farther away you put the far plane from the near one, the more "depth" has to be represented in the same amount of floating-point precision in the Z-buffer, leading to more Z-fighting errors.

In Topic: Problem with lighting artifacts from hidden faces in my scene.

24 July 2015 - 01:46 AM

What L. Spiro said. I've seen this a lot before, especially when people try to align cubes. Instead of rounding the positions like L Spiro said, you could also compute the floating point value for the position of the two touching sides of two adjacent tiles only once, like when computing the positions to draw a line-grid. This means that you will have to stretch your wall-tile model to a grid square/cube, instead of just placing it at a fixed position.


But if your problem is caused by z-fighting, you'll have to find another solution, like not drawing the hidden sides of the walls at all, or changing the order in which you draw them, coupled with z-bias.

In Topic: Problem with lighting artifacts from hidden faces in my scene.

23 July 2015 - 06:55 AM

If it's because of the backfaces being lit (you've ruled out anti-aliasing?), this would only happen when you place the lights exactly on the same plane as your wall tiles (or behind the wall), due to floating-point precision errors. So you should instead place your lights at a small distance in front of the wall.

In Topic: Some Maya normal issues

14 July 2015 - 04:25 AM

In your vertex shader, your normal should be multiplied by the World matrix (or the WorldView matrix if you want to do lighting in View space, i.e., relative to the camera position), not the inverse transpose of the World matrix. And you have to make sure that all the vectors you use for lighting are in the same space - World or WorldView.


> First why some exporters multiply the normals with the inverse and transpose world matrix before exporting ? Shouldn't normals be exported as local direction vectors for every vertex and be multiplied later at shader level ?


Multiplication with the inverse transpose World matrix gives you local coordinates from world coordinates (and I think the transpose swaps x and z or x and y around, so it matches the DirectX left-handed coordinate system), so maybe Maya provides those exporters with world normals?

In Topic: Why is my constructor/Renderer class being called twice?

13 July 2015 - 04:09 AM

    super(context, attrs);

Is it possible that a MyGLRenderer is already initialized once during this call fom the MyGLSurfaceView constructor?