It is currently Thu Feb 22, 2018 9:50 am

All times are UTC - 5 hours

 Page 1 of 1 [ 2 posts ] 
Author Message
 Post subject: A Possible New Way Of Handling Lighting/Shading?
PostPosted: Tue Mar 02, 2010 5:54 am 

Joined: Sat Aug 16, 2008 7:58 am
Posts: 452
The idea I have in mind is something like this. There are 3 main types of lighting and shading in Game Devolpment. You have Pixel, Vertex and Planer shading. Each have their strenghts and set backs.

With Pixel you get a more accurate lighting scheme and better shading, but is computationally expensive. With Vertex it is less expensive, not as accurate but you have more nomals per face. This will cause uneven shading. Then you have planer which is the least expensive and runs fast but, you do not get any shading at all, for example we have an object in world space say at v3ObjPos( 1.0f, 0.0f, 1.0f ) and we have a Light at v3Position( 2.5f, 1.0f, 1.5f ), with v3Direction( -0.65f, -0.33f, -0.25f )
We will assume that the light is pointing at the object from above on an angle. Lets say that this object or model has roughly 3k triangles ranging in all different sizes from very small to somewhat big. How can we resolve the issue of what type of lighting or shading to use? If we use pixel lighting/shading this will work great for shading effects, but where we have hundreds and even thousands of tiny triangles in a small area,
this is what I like to call bleeding( as the seen updates and the camera is moved or the lighting is dynamic, the same pixel/pixel color is being rendered mostly on top of itself and if our texture/material/lighting has an alpha channel, this is even worse ). If we use Vertex shading, then we will have some area's of this object look nice and smooth and some area's of this object looking rough and jagged from all the normals, and the shading isn't too great. If we use planer normals, then the processing time is great, but the shading sucks. for example Lets say we have a person standing here and the light is pointing downward on their right side as if they were looking at the camer (in front) of us. If we used shadows in the game. Both sides will throw off a shadow on the ground where the way it should be is the right side of the object should appear brighter and the left side a little darker, and the casting shadow on the ground or near by objects should be drawn only in the facing direction vector of the light.

So how do we resolve this?

I don't know if this will be too expensive computationally, but before we render anything to the screen. My idea is that since our objects are stored in nodes which are contained in a vector<> which holds all the vertice, material and texture data in it. What we could do is have a checking system. The first thing it does is check to see if the object that is loaded is a general shape from our object library such as a box, cylinder, flat grid, or sphere. Then this can perform a combination of either planer or vertex shading, depending on the size of the triangles / and distance - direction from the camera. Then we check against the models that are loaded in.

Here we need a way to know all the lights that are in the current scene and a way to recognize if the scene's camera has been updated to reasign the lights, before we can compare the models. So initially we load in all lights first which is already done but to keep a log of there positions and directions (if they have direction ), then we load in our models with their material and textures. And in the loading state we do our first check

We need a method to retrieve all the vertex data of any current models that will appear in the seen from start up which has to coincide with the camera/players initial position and direction even if it is random, from here we do our first check and what my idea kindof makes sense.

We need a new simple math function that will calculate the area of a face of the triangle. We can then use this area to determine which of the three types of lighting or shading to use. Another words well will be analyzing the wire mesh to this model. and for any triangle's area that are within a certain range we do one type and so on. but this is not the only check
we will have 3 cases, but we also need to do another check as well

for example lets say we are looking at the chest of the player, here the triangles will be small but not tiny and their sizes will be roughly the same
so we can assume to use vertex or planer / depending on distance and angle vs the lights direction. But if we look at the arms as we get closer to the hands, you will notice that the triangles are getting small and smaller the closer you get to the fingers. Here If this model is fairly close to the camera we can say it is safe to use a combination of pixel and vertex shading. but if we are to move away from this object and this model is now sortof far away (not so far that it looks like a dot or a blur) yet close enough to see some detail, Like you won't quite be able to see the design on it's shirt but you can distinguish its body, from its arms, legs and head.
Now since the player has moved or the object has moved (either or) and its distance from the camera's perspective and from the lighting perspective have changed this will be a second checking call and the lighting on this object will update, and now the area of these triangles have actually changed do to perspective. For example lets say the initial area of a triangle when it is first loaded into the the scene at start up is
.85f units^2 and the object moved in some direction and distance from us
and is now farther away in the scene, since the update function is constantly being called, this is a good place to check it but to keep things less expensive ( we can use the original data from the first check at the loading stage as a reference instead of actually recalculating each and every triangle's area on each update call (TOO expensive) but we can have a (map) or chart to base off of for all triangles with in range [A,B]
for all distances of Camera from Range [C,D] we do the following and it would be safe to say that we could have 3-4 differen range case values.
and what happens is that at loading time after the inital areas are calculated are then placed in a specific group and this is the compairing table, and if the object has been moved then it is quickly swapped to a differnt group and automatically the differnt lighting techinque is applied.

But to make things a little simple for example ( lets say we have a complex object like a battleship that has some areas with large triangles
such as the base of the ship that sits in the water. this will usually not change unless if it gets fairly far from the camera. But the compartments above the deck have many vertices, ranging in all sizes. Here we can use another algorithim that works during loading time to see if there are many small triangles but are on the relative same plane then we can approximate this area and use vertex instead of pixel to save computation
(but this last part is optional).

These are just ideas that I have that I am throwing them out there for people to read about and comment about. I would really like to hear your opinions, the good ones the bad ones the pros and cons of this, and If this does seam feasible, how to implement this. Instead of the common know shading models( tessellation or retessellation ) methods that are common. I would like to call this the Lighting Engine(TM)
Please feel free to leave your comments and feedback.

 Post subject: Another Approach To This Same Idea
PostPosted: Tue Mar 02, 2010 6:21 am 

Joined: Sat Aug 16, 2008 7:58 am
Posts: 452
We could also creat another file parser that works during the game, and this parser will actually read and write data on the fly. Here with this file some things can not be overwritten, such as all the neccessary triangles' areas that are loaded in from the objects at start up ( or the loading state ) and at each phsycis refresh rate call, this file is read and writing too if and only if there are significant changes. And to make things a little easier, so that we don't end up having some reference file or text file accummulating to a few MB or larger, this pertains to models only since standard objects that are static and have low poly count will use the same basic lighiting unless real far from camera or at extreme angles with respect to the lights, can be done with in the code itself, the models will have each of their own extension file to reference so lets say we have 15 models in 1 scene at a current time our scene graph vector would be like this objs<0, 1, 2, 3, 4, 5, 6 ,7 8, 9, 10, 11, 12, 13, 14> where each element of this vector is a vector or an array itself. A simple note to look at too is which object to do focus on the most for the more accurate lighting and shading. The answer is simple the ones that are closest to the camera. We should already have a frustrum calling method, and perspective calling method in place that checks to see how far the objects are from the camera, we can use this as a reference point(we don't have to redo the same calculations) but will will have to add in the ability to check where the lights are in the scene and their direction with respect to the camera and the objects of concern. we can traverse through this array
and lets say that objects 4,7,9 & 12 are close to the camera and are most visible where the other ones are farther. you would think that since the farther ones have a smaller appearing triangle area would use pixel shading, but their view is out of range, so we can use the defualt for them and leave them as is, but for the 4 that are close, now that we know that they are within range of the concerned area we will chose to work with the one that is closest to the camera where the focus is higher (such as looking at a picture taken from a real camera) we can use the file parser method to retrieve the file pointer and read the initial data, then use our compare function, and from there we can use our algorithm to reassign the new ligthing reference values and write this into the temp section of the file. We don't really need to load in this data and save it to memory, we can use a filestream to do this. so that we have a on the go lookup table. Now the trick thing is when the application is shut down, we do need a method that will keep the inital true(triangle area) size such as in the header of the file, and we can skip past this block, and delete everything else in the file so that when the application restarts. There will not be any conflicts with data values. And another thing with this method that can be very usefull is if we know the current position of this model, and we know where the origin to the coordinate system is with respect to itself, and that we have an accumalated list of the wire mesh's triangle areas, we can use this for collision detection as well. With the collision dection part if we are to read in the file we will only be concerned with the main header as well as the objects current position. then we can use a for loop to traverse through these triangles and see if any of these come in contact vs another object, wall, ceiling etc... Happy Coding(TM)

Display posts from previous:  Sort by  
 Page 1 of 1 [ 2 posts ] 

All times are UTC - 5 hours

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Jump to: