Archives

Long time since my last post, have been busy with school and such but I also learned how GLSL shaders work. Basically what it comes down too is that I wanted a lighting system fully in shaders, yet I wanted a good fps while having many lights. So I started searching for techniques how to do this and came across deferred shading. It took me a while to implement (mainly because I had no knowledge of GLSL before I started) but I think the results are good 🙂 I also made the engine save to my own mesh format (P3D) which is basically a light binary version of an obj model. I’m planning to expand it to support everything my engine would need in the future (animations and such). I don’t have any pictures of the lighting system on my terrain system because I still need to edit my terrain shaders to support the new lighting system, so I’m just using a test map I found online with a grass texture applied to the whole scene. The red light is a light that is 400 units above the marine and has a radius (all point lights btw) of 1000.0 units. The rest of the lights have a range of 400.0 units and maintain their position. Don’t mind the texturing, I still need a modeller or such to create the models and textures for it.
Anyway, Here are some pictures of the lighting system:Picture 1 (Test Map)Picture 2 (SC2 Terran Command Center)
Looks great doesn’t it?

Next step would be to add support for directional and spot lights, and also some real-time shadow mapping technique.

Lately I have been looking into OpenGL alot and I have to say I really like it compared to DirectX.
Also I’m working on a 3rd person outdoor shooting game in OpenGL, here are some pics of the LOD Terrain System:
and top-down wireframe:

You can clearly see that the detail decreases as you get further away from the camera. This makes it run good on all systems I tried on (except my laptop).

As you can see, the map file defines the textures to use…its not hardcoded into the game.
Also, the gamemodes are scriptable through the embedded scripting language angelscript.
The server will take care of the installation of the missing files at the client, for example it would send textures, sound files, script files etc. to the client to make it work with the current map.
To define a new gamemode you have to create a client-side and server-side script file, here is an example of the server-side script file:http://pastebin.com/pjqRANar
I won’t show the client-side script yet, its not quite done and needs ALOT of changes to work correctly.

And a few screenshots to illustrate (Click the images to view real size):
Before shader effect (zoomed in at shadow border):
After shader effect (zoomed in at shadow border):

Over-all view before:
Over-all view after:

You still see a bit of aliasing, thats because I needed to do a Gaussian blur and I did a box blur. Online they say when running the box blur three-times it produces a blur that looks strongly like Gaussian Blur. But I’m happy with the results now.

I recently started working on a little 2d top-down techdemo using my engine, and I soon found out that I wanted shadows!
Well, how do you do this when using sprites? (so pure pixels?)
The implementation what I now did was create 4 vertex points at each corner of the bounding box (so the shadows aren’t pixel perfect :() and then use those to generate the shadows.
And guess what, IT WORKED!
You can read about the code I used here: http://www.ogre3d.org/forums/viewtopic.php?f=10&t=56294&p=382388#p382388

And an image to show it off:
(Click the image to show real size)

[edit]
Another image with some changes made, and a small test map
(Click the image to show real size)

Lately I’ve been in the process of porting Ogre over to android. This is quite hard since Ogre uses exceptions, RTTI and STL stuff which android’s NDK doesn’t support.
Then we stumbled across this link:http://www.crystax.net/androidndk.php

The guy there, “Crystax”, made his own version of the ndk, using the official ndk, which supports RTTI, exceptions and STL. (Woohoo!).
So OgreMain got ported over with ease (I only had to ditch CMake for now and create a custom android makefile, it seems Assaf Raman on the Ogre forum created a Symbian CMake generator, so maybe this create’s a posibility to create a Android CMake generator) but the next problem was the GLES1 RenderSystem. I still haven’t ported this one over since it uses EGL which android only exposes to the java part for now. Maybe some reader here can give me an alternative for native code that works on android? I was thinking about using dlopen and dlsym to get the EGL functions from the active EGL library on the system, but this doesn’t seem to work either. (Haven’t fully tested it yet, so maybe it does work correctly).

If someone could give me some tips etc. on how to get this going, please let me know!