# OpenGL The missing gap (light mapping)

## Recommended Posts

Hi there, recently I have been learning to construct my own 3D engine using OpenTK and C#. Everything is going smooth as pie, I have a great system for using wavefront obj file's, and their material libraries. It correctly handles UV texture mapping / normal data for lighting, and I've even sorted out alpha blending (making sure to order faces correctly). The project uses immediate mode at the moment as VBO's can easily be implemented later, and I just want to focus on learning the theory.

Now it's time to move onto lighting and shadows, I've done a great deal of research into the matter already, and have decided that light maps are the way to go. From my
understanding and research, the following should be right (please correct me if i'm mistaken):

[list][*]A texture providing light data need's to be produced for each mesh.[*]Each triangle on the mesh requires a separate set of coordinates to allow the lumel's provided by the texture to be mapped onto each triangle surface.[*]Shadow's can exhibit jagged edges if the light map is of small resolution, as lumel projection is determined by the pixel centre, not pixel edges.[*]light map coordinate data needs only to be calculated once.[*]When calculating light map coordinate data, the maths must be done using plane projection.[/list]

Those of you who are experienced in this area I'm sure already can spot the gap's in my knowledge, but I'm hoping that I am not too far away, and that someone may be able to nudge me in the right direction. Today I found a tutorial on flip code [url="http://www.flipcode.com/archives/Light_Mapping_Theory_and_Implementation.shtml"]Light Mapping - Theory And Implementation[/url] , I think using it, I should be able to eventually understand the things I need to, though I have a few questions that I believe would help me learn a bit faster:

[list][*]Are there any less pseudo OpenGL examples of plane projection that people use, I don't mind the language, as long as it's strong typed (not pseudo).[*]I'm a bit confused on how lights relate to a light map, does this process assume that light's are static, therefore the usage of the light map texture,
this concept is part of what's confusing it for me.[*]Am I right in assuming that once I understand this process, I should be able to write a GLSL shader to map the lumel's based on the light map texture ID,
and light UV via a uniform variable or something similar?[*]Finally (and this one is a bit off-topic at the moment), but taking into account a semi-transparent face would not cast such a dark shadow, how would you
build this into this process? or would the colour information passed to the shader already account for the alpha channel.[/list]

Thanks for your time, I understand this is not the most straight forward question to answer, but I value your opinions, and very much look forward to some feedback.

Aimee.

##### Share on other sites
Hello,

definitely implement VBOs as soon as you'll get some time, it is just a matter of few hours and it will save you a lot of pain .

Lighting and shadows are quite huge area of rendering. Lighting can be divided to two main parts - direct lighting and indirect lighting. As indirect lighting methods are quite complicated I won't recommend learning them now, it will be time to learn them later. On the other hand direct lighting can be divided to again two parts - static lighting and dynamic lighting (as a matter of fact, indirect lighting can be also static and dynamic, but well ... lets forget indirect lighting for now and leave it to future).

Static lighting can be achieved using F.e. light maps, they're not as easy as they seem to be, they can begin to be overcomplicated when it comes to unwrapping mesh to texture. Try rather to do base dynamic lighting, it is a bit easier to do. Also light maps are a bit outdated right now and they're not so common in modern game engines.

Dynamic lighting can be computed using immediate mode lights, or shading languages (I recommend learning shaders, and trying to do lighting in them). Of course once you do your first dynamic light, you should continue and learn what is deferred shading and forward shading. How to work with them, try both of them, etc.

Shadows are another topic and they're much harder to achieve. There is no absolutely robust solution in rasterizers, you can use shadow volumes (but well... they're not so good), or better shadow mapping (that can be very robust). Both shadow mapping and shadow volumes can be extended to work properly with semi-transparent objects, to be soft shadows, or even properly physically plausible.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
627762
• Total Posts
2978967
• ### Similar Content

• Hello! As an exercise for delving into modern OpenGL, I'm creating a simple .obj renderer. I want to support things like varying degrees of specularity, geometry opacity, things like that, on a per-material basis. Different materials can also have different textures. Basic .obj necessities. I've done this in old school OpenGL, but modern OpenGL has its own thing going on, and I'd like to conform as closely to the standards as possible so as to keep the program running correctly, and I'm hoping to avoid picking up bad habits this early on.
Reading around on the OpenGL Wiki, one tip in particular really stands out to me on this page:
For something like a renderer for .obj files, this sort of thing seems almost ideal, but according to the wiki, it's a bad idea. Interesting to note!
So, here's what the plan is so far as far as loading goes:
Set up a type for materials so that materials can be created and destroyed. They will contain things like diffuse color, diffuse texture, geometry opacity, and so on, for each material in the .mtl file. Since .obj files are conveniently split up by material, I can load different groups of vertices/normals/UVs and triangles into different blocks of data for different models. When it comes to the rendering, I get a bit lost. I can either:
Between drawing triangle groups, call glUseProgram to use a different shader for that particular geometry (so a unique shader just for the material that is shared by this triangle group). or
Between drawing triangle groups, call glUniform a few times to adjust different parameters within the "master shader", such as specularity, diffuse color, and geometry opacity. In both cases, I still have to call glBindTexture between drawing triangle groups in order to bind the diffuse texture used by the material, so there doesn't seem to be a way around having the CPU do *something* during the rendering process instead of letting the GPU do everything all at once.
The second option here seems less cluttered, however. There are less shaders to keep up with while one "master shader" handles it all. I don't have to duplicate any code or compile multiple shaders. Arguably, I could always have the shader program for each material be embedded in the material itself, and be auto-generated upon loading the material from the .mtl file. But this still leads to constantly calling glUseProgram, much more than is probably necessary in order to properly render the .obj. There seem to be a number of differing opinions on if it's okay to use hundreds of shaders or if it's best to just use tens of shaders.
So, ultimately, what is the "right" way to do this? Does using a "master shader" (or a few variants of one) bog down the system compared to using hundreds of shader programs each dedicated to their own corresponding materials? Keeping in mind that the "master shaders" would have to track these additional uniforms and potentially have numerous branches of ifs, it may be possible that the ifs will lead to additional and unnecessary processing. But would that more expensive than constantly calling glUseProgram to switch shaders, or storing the shaders to begin with?
With all these angles to consider, it's difficult to come to a conclusion. Both possible methods work, and both seem rather convenient for their own reasons, but which is the most performant? Please help this beginner/dummy understand. Thank you!

• I want to make professional java 3d game with server program and database,packet handling for multiplayer and client-server communicating,maps rendering,models,and stuffs Which aspect of java can I learn and where can I learn java Lwjgl OpenGL rendering Like minecraft and world of tanks

• A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

-What I'm using:
C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.
-Questions
Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?

• Both functions are available since 3.0, and I'm currently using glMapBuffer(), which works fine.
But, I was wondering if anyone has experienced advantage in using glMapBufferRange(), which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
• By xhcao
Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness.

• 11
• 10
• 10
• 23
• 14