I added another framebuffer at the tail-end of the rendering pipe, this is where I do the culling of the lighting volumes for Deferred Shading. This is also the beginnings of any future post-processing work I do (HDR/Tonemapping/ambient occlusion).
I feel like the lighting is done enough to move into Lua.
My next project is to make a realtime editing of light values in the editor I have (the purpose of its early existance).
Here is an example of where i hope to get with my editor eventually, but for now im just going to do lights =). I by no means have an Uber-Shader yet, but I’m working towards that.
I added point lights over the weekend. Aside from getting the proper light volume shape (a sphere geometry) and proper values for my attenuation, its almost there. Here’s a pic.
So my Deferred Shading shaders were messed up, and after some clarification on theory and math I am starting to see some real working results. here is a picture of a light moving from right to left right behind the camera.
directional light
Next is point lights and a bunch of lights moving around the screen.
Cheers!
PS. Once this is working and im comfy with it i will be sure to talk about it =)
Here is a link to someone who has given me some critiquing on my deferred renderer. We have similar goals with different tools and different things we are currently working on. Another great source for engine stuff.
I just managed to get running the Lua Module system I described toward the end of my presentation. link.
To sum up the reason for this post, i point you to the google search results of “Lua modules” where you will see that the second page in the list is titled “lua’s module function critiqued”. If you have gone down this route before you know what I am talking about. It is NOT clear cut and dry how to implement modules in lua in the lua book and in a lot of the tutorials online.
The process is not like an import or #include, since “require” searches in the package.loaded table for anything that you have defined in module()… and anything defined WITH module() CANNOT call ANY globals (like print or another require) once this module function is called. (if you go to that critique web page you will see how to overcome this)
Confused? Well it seems like Lua and the Lua team have opportunity to improve the system and straighten things out. Just know that when you call module, the environment is wiped nearly entirely, meaning that those nifty functions like print and such will no longer be with you.
Why don’t I fix it? Because i can see why they do it the way they do, to make each module lightweight and somewhat private… but… there has to be a better way. I really think this is important ALSO because this is the essence of sharing code, and if you cant get the system of sharing code right… how will anyone be able to use it (espcially with the MIT license just begging for free sharing of code).
So the whole point of me doing more Lua stuff right now is so I can go back to working on my lighting model. I want to be able to add cameras, lights and objects to anywhere in my scene by the click of a button, even change normal maps. This makes debugging an OpenGL lighting model easier, since the debugging tools aren’t as plentiful as DirectX.
However, I have also been trying to build up enough stuff to put out a demo to test how the engine is holding up with all of these structural changes. So, I am going to come up with a very very simple demo using the new lua structure.
So Be on the lookout for some future posts on Deferred Shading. If anyone has any requests about how this post should be tailored, I’m all ears. I was thinking about doing a 3 part post. 1st on ABSOLUTE beginner intro 2nd on architecture, and 3rd on implementation.
This Post is an answer to the question recently posted in a comment about updating game objects.
There are 2 encarnations of a single “game object”.
1) The Object class in the C++ engine (which i pointed out in the video), containing things like collision mesh, mesh, texture, etc.
2) The lua table that describes the properties of the game object to make it a gun or a tank or a shield or sword OR more importantly, a button or a minimap, or a bullet. (the advantage of making it generic, more on this later).
Now, I briefly talk about the event system that I have in place in lua in my presentation. This event system allows me to fire events when certain things happen, and have lua game objects (lua tables) call a specific function when a particular event is fired.
This event system is interwoven into the c++ side of the engine so i can fire events from C++ and respond to them in lua. (the gameloop shows the event->update() function which just calls the event system’s lua function that calls all the functions of any listeners where their event had fired that frame)
SO, in a “game” context there are several cases in which something needs to be updated. When an object collides with another object, something needs to happen (a collision event fires for the two objects). when a button gets clicked on a click event fires.
In terms of moving somewhere, an object may be told to move to point x. and when the object gets to point x an event is fired.
On the C++ engine side, the “graphics/physics” object is being updated every frame, where as the game logic is more so updated in response to events.
ALL of our game logic should be able to exist within these events. And things like timers and other tools will be made in C++ to fire events in lua if needed.
here is a link to the source code from lua programming gems (a pretty cool book btw).
So to conclude, you can see that there are multiple kinds of “updates” and event listener functions that are called to make the update process efficient and fast, but hopefully robust =)
Now that the architecture for the engine has been laid out, it is now time to migrate all of our engine’s objects into lua in one way or another, and provide these to the game. I’m starting with things that we originally did in C++. For example, here are some files of different kinds of Camera implementations. These Core things will exist across multiple games.
Camera is the base object, while free camera (respond to w,a,s,d and move around) and preview camera (will sit at the origin and look down the z-axis.)
Right now these implementations are empty, however they will call engine api functions for making a certain camera active for rendering and for moving them around.
I have been on vacation, but before I left I gave a video presentation on the engine’s architecture.
Check it out!
I’ll be posting more errata from this presentation, but here are some corrections.
you cannot (to my knowledge) use DirectX shaders with OpenGL.
I also said that you shouldn’t use pointers with lua for referring to game objects, This is actually a pretty good idea, however it should be done with care, since you are bypassing the enginemanager and going directly to the objects.
Irrlicht and Ogre do implement different physics engines, not sure which.
I also forgot to point out Decoda which is a debugger for the lua environment, it does cost a bit of money but all of you know how valuable a debugger can be. If you use visual studio and have the lua source embedded directly into your project, as long as you have the .pdb files it will work (so cool!), otherwise you need to point it to the dll I believe (still cool).
