It will, I just don't have the code in it yet. I will of course need it when I get the freecam in, but that's after I do a bit more work.

Gotcha, my error, I misread. Keep up the great work on this, then, and I'll do my best to be part of the cheering squad even before there are eye-candy screenshots for us to ooh and ahh over.

I have input working plus physics in the client side now. I will need to make a character model and learn how to do armature animation in OpenGL as well as storing/recording it (for actual in-game stuff, not a freecam).

What sort of models will you be making? How is your terrain (you have terrain?) set up?

Models will be human-like characters. If I get the rigging set up properly, I can make anything that fits that shape. (Then later will be the fun models)

No terrain created yet that's game-worthy. I am only making test maps just to run tests, like creating physics shapes, proper collision, etc. Terrain right now is just a list of models that will be loaded at the start of the game.

Once more has been done I can focus on more fun physics effects

So, I am needing help... Has anyone done armature animations in OpenGL/Direct3D/etc.? I am trying to figure out where to even start with adding in weighted bones.

Working on exporting bone data from Blender using python. I need to see how it uses animations as well.

I just got past coder's block here. I finally understood enough of Blender 2.63's Python API to export bone weight data. Woo! I am still not done, but at least I have 1/2 of the needed data for animated models.

MC sure does kill time.... :-\

I don't know whether I love it or hate it for that reason; probably the latter. Glad to hear you have half the data for animated models. Now get the other half!

Picked this project up again, and hey! I forgot I made a thread here!

Python was scrapped in light of Lua, which is now loading as a map resource and can run. I have 0 integration, but it is there for future work I already have done testing with making a library and handling fun things between lua and C.

I am using MD5 models for the animated model format of choice right now. I have been working on a loader for it which will need work to get animations going.

The game is able to render yet again! I will be getting the spectator camera going soon in noclip mode, then hopefully get it to use Bullet for collision stuffs.

I will try to display the models sent over by the server and have it rendered while working on the spec. camera, so fun stuffs should show up.

I have added in a spectator camera that can look around using the mouse (flawlessly now) and move around as a rigid body camera (no collision tested yet, movement works flawlessly). WOO HOO, this was a PITA to figure out how glm does stuff as the docs suck.

I finished my transform update method (2 lines) and now map objects sent from the server are synced with the client! With my new spectator camera, I was able to watch a cubic meter of grass fall out of the world (pardon the Minecraft reference, unintended).

Very happy at the progress I made. Not sure what to tackle next. Probably testing the physics aspects by making a physics objects to interact with (ground included) to test the world transforms being sent and rendered as well as the camera's collision ability. I bet that my movement of the object isn't correct and will have to use impulses, but that is for later.

I will also need to get Lua added into the game and client for GUIs and map stuffs. Expect awesome screenies in the future when I add screenshotting to the client.

Started to work on the MD5 loader as that is something I need to get into for models. Right now, I have a static model format that really shouldn't exist Just for testing and such.

NOTE: Blender 2.6x stores physics settings in "Blender Game" mode. To access these settings, use bpy.context.active_object.game

As you can see from the above, I figured out where to set physics settings in blender 2.6x as well as accessing those values in python for exporting. this will be for my map exporting script that will be able to specify models (knows about linked-duplicate objects), object locrotscale data, physics properties, and other info. I will be adding the ability to have certain objects have Lua bindings, such as doors, buttons, areas, and more.

Out with the old map format:
Code:

... and in with the new
Code:


The new resourseMap code is still migrating the changes and closely resembles the resourceMD5 loading code. Will have to rework how I load models and such. Chances are is that I will move my custom model code from resourceModel to resourceREDModel, have resourceModel store all VBO and other OpenGL data, and have this shared to many resourceMD5/resourceREDModels so that I can properly instance objects, saving on exported models and still having unique properties.

I adjusted all of the rotations and translations from how blender stores them to how OpenGL uses them. I now have instancing down, so I can have multiple of the same model used in a map with the data stored once, however the physics data is stored per-mesh (will be changed). The physics properties load correctly and I can have a rigid bodies fall down onto static meshes (only sphere and box shapes right now, more to come).

I will have to add in interpolation later on to make everything smooth. I will probably wing-it for now until I find an article that gives an example. (Look at average time to receive that entity's update_transform packet and interpolate the transformation based on the predicted next frame.)

I will also look into dynamic lighting in shaders. Right now, the map allows for lamps in the maps, so I just need to get the engine to integrate lamps with the programs.

More things, like bump mapping and such will be looked into later on.

After spending all of break fighting with GLSL, I found a few critical bugs that got squashed! Firstly, silly blender. Stop it with your coordinate system not being OpenGL's when your backend is OpenGL.

My normals were not facing the right way, firstly. Many issues with GLSL, namely the internet showing modelview matrices used when they should be model matrices (else moving the camera moves the lighting for lambert calculations).

More bugs left, including the X axis being flipped for spawned-in map objects. Here's a screenie of a scene exported from blender, loaded onto a server, and rendered with a client connected over UDP after a box fell off of the sphere (light source above the sphere):



I will be working on post-processing effects now.

I now have post-processing effects going on both the overlay UI and the actual scene. Just tests of a shadow shader on the text, pixelation/distortion on the scene, and MD5 object processing.

Animation!?

Made a cursor and will work on the UI. Right now, the UI overlays are created in software with SDL and then used as a texture (can be fullscreen or used on a model). I am thinking about rendering the UI partially with OpenGL, but then again, not crucial as the CPU can do it just fine.

Created a SVG cursor and will be getting the UI overlay the ability to grab the mouse and use it.

Looking great! Not a big fan of the per-vertex lighting on the cube three posts up, though.

Neither am I I used to have code for some nice lighting, but was fighting it simply because I was failing to load normals and such right in the first place. I will get back around to fixing that.

Currently adding in a dedicated RTT system in order to standardize the effects as well as get the UI drawn using OpenGL since I am seeing issues with SDL2 doing blending with an OpenGL renderer.