I'm building a simulation with directional lighting where multiple sprites will be rendered in the scene. The sprites will be simple geometry layered with a normal map.
I'm using this example as a starting point for my code.
The problem is that if an object is rotated, the lighting within the scene no longer reflects off the normals on the rotated sprite correctly. For instance, lighting up the right-hand side of an object that is rotated by 180° will brighten the left-hand side of the object. I tested this by rotating block1 in the above example.
No rotation.
180° rotation.
I understand why this is happening. But I'm not sure how to approach resolving it. Is it possible to allow rotated normal maps to correctly reflect light? How?
Related
In computer graphics, why do we need to know that backward face and forward face of a polygon are different?
There are several reasons why a triangle's face might be important.
Face Culling
If you draw a cube, you can only ever see at most 3 sides of it. The front three sides will block your view of the back 3 sides. And while depth testing will prevent drawing the fragments corresponding to the back sides... why bother? In order to do depth testing, you have to rasterize those triangles. That's a lot of work for triangles that won't be seen.
Therefore, we have a way to cull triangles based on their facing, before performing rasterization on them. While vertex processing will still be done on those triangles, they will be discarded before doing heavy-weight operations like rasterization.
Through face culling, you can eliminate approximately half of the triangles in a closed mesh. That's a pretty decent performance savings.
Two-Sided Rendering
A leaf is a thin object, so you might render it as one flat polygon, without face culling. However, a leaf does not look the same on both sides. The top side is usually quite a bit darker than the bottom side.
You can achieve this effect by sending two colors when rendering the leaf; one meant for the top side and one for the bottom. In your fragment shader, you can detect which side of the polygon that fragment was generated from, by looking at the built-in variable gl_FrontFacing. That boolean can be used to select which color to use.
It could even be used to select which texture to sample from, if you want to do more complex two-sided rendering.
i'm programming in WebGL (using OpenGL shaders) simple model loader. I've implemented phong shading in fragment shader. However when i load larger objects than simple monkey/cube and turn camera out of light source, meshes looks strange (aliased?). Some of them are even lightened although they should be hidden (black).
Lightened side is OK:
Other side is wrong:
I calculate normals for every vertex same way, so normals should be OK (when i turn camera on lightened side of car, everything goes right).
Thank you very much for your tips.
This looks like an single sided vs two sided lighting issue to me. In case your mesh consists of only a single "layer" of faces, those will have normals that point into only one direction. If single sided lighting is used, then the backface, i.e. if the light is on the side from which the normal points away, will look weird.
There are three ways to overcome this:
Use two sided illumination
draw the object twice with back faces culled, then flip the normals and culling the front face
Give the mesh thickness, so that there are two sides (you should enable backface culling then)
I think i found bug in my Collada Parser where i do not respect exported normals but i'm calculating new one. This causes inverted normals from time to time (this door mesh of this car for example). Anyway two sided rendering has to be implemented too.
Thank you.
I'm trying to understand the ambient occlusion technique described here, but I've trouble comprehending what exactly is the pixel shader doing.
Is the pixel shader invoked on points that belong to the surfaces of occlusion volumes? Can anyone explain on a simple scene (like a cube corner seen from inside) how pixels get their AO values?
(Crossposted from game stackexchange)
Basically Pixel Shader is responsible for reflecting the light in a object depending on what angle the poligons is facing the virtual light source. in that case AO is made possible by the help of pixel shader emulating the light and its amount in every single texture. Note: Pixel Shading is real time so if the object or the viewing point moves, the light also move and make a realistic textures.
I am trying to create an application similar in UI to Sketchup. As a first step, I need to display the ground surface stretching out in all directions. What is the best way to do this?
Options:
Create a sufficiently large regular polygon stretching out in all directions from the origin. Here there is a possibility of the user hitting the edges and falling off the surface of the earth.
Model the surface of the earth as a sphere/spheroid. Here I will be limiting my vertex co-ordinates to very large values prone to rounding off errors. (Radius of earth is 6371000000 millimeter).
Same as 1 but dynamically extend the ends of the earth as the user gets close to them.
What is the usual practice?
I guess you would do neither of these, but instead use a virtual ground.
So you just find out, what portion of the ground is visible in the viewport and then create a plane large enough to fill that. With some reasonable maxiumum, which simulates the end of the line of sight aka horizon as we know it.
I've been struggling with this for a while.
Presently, I have a grid of 100 by 100 tiles, which belong to a Map.
The Map implements IDrawable. I call Draw() and it draws itself at 0,0 which is fine.
However, I want to expand this to draw essentially a viewport. The player will be drawn on the screen in the middle, and thus I want to display say, 10 tiles in each direction (rather than the entire map).
I'm having trouble thinking up the architecture for this one. I'm in the mindset that things should draw themselves, ie I say player1.Draw() and it draws itself. This would have worked before, where it drew the player at x,y on the screen, but with a viewport it will no longer know where to draw itself.
So should the viewport be told to draw, and examine every object in the game and draw those which are visible? Should the map tiles be objects that are subjected to this? Or should the viewport intelligently draw the map by coupling both together?
I'd love to know how typical scrolling tile games accomplish this.
If it matters, I'm using XNA
Edit to add: Can you do graphics manipulation such as trying the HTML rendering approach, where you tell things to draw, and they return a graphic of themselves, and then the parent places the graphic in the correct location? I'm thinking, if I had 2 viewports side by side for splitscreen, how would I stop them drawing outside the edges?
Possible design:
There's a 2D "world" that contains object instances.
"Object instance" is a sprite reference + its coordinates in the world.
When you draw scene, you request list of visible objects that exist in given 2D area, THEN you draw them.
With such design world can be very huge.
I'm in the mindset that things should draw themselves, ie I say player1.Draw() and it draws itself.
visible things should draw themselves. Objects outside of viewport are not visible.
, how would I stop them drawing outside the edges?
Not sure about XNA, but OpenGL has "scissors test"/"glViewport" and Direct3D 9 has "SetViewport" method that allows you to use part of the screen/window for rendering. There are also clipplanes and stencil buffer (using stencil for 2D clipping is overkill, though) You could also render to texture then render the texture. There are many ways to deal with this.
So should the viewport be told to draw, and examine every object in the game and draw those which are visible?
For a large world, you shouldn't examine every object, because it will be slow. You should be able to find visible object without testing every one of them. For that you'll need some kind of space partitioning - quad trees (because we are in 2D), k-d trees, etc. This way you should be able to handle few thousands (or even hundreds of thousands) of objects, as long as you don't see them all at once.
Should the map tiles be objects that are subjected to this?
If you keep drawing invisible things, FPS will drop.
and they return a graphic of themselves
For 2D game this may be very slow. Remember KISS principle.
Some basic ideas, not specifically for XNA:
objects draw themselves to a "virtual screen" in world coordinates, they don't draw themselves to the screen directly
drawable objects get a "graphics context" object which offers you a drawing API. The "graphics context" knows about the current viewport bounds and realizes the coordinate transformation from world coordinates to screen coordinates (for every drawing operations). The graphics context also does the direct drawing to the screen (or to a background screen buffer, if you need double buffering).
when you have many objects outside the visible bounds of your viewport, then as a performance optimization, your drawing loop can make a before-hand bounds-check for your objects and test if they are completely outside the visible area. If so, there is no need to let them draw themselves.