I’ll just say that I’m not a pro (yet ;)), but I’ve learned a bit about Blender, 3d and a little of coding in the last couple of years. I’ll try to answer some of your questions…
To use the GLSL you only need to turn on the setting and that’s it?
Basically, yes. But GLSL materials require a bit more work to set up. You need the diffuse texture for the colours and a normal map to give it a nice 3d look as a basic material setup. It also adds realism to add a specular map so for example you can have a worn metal object that is tarnished and unreflective in places and worn to a shine in other places. It depends on the time you have and the level of realism you’re going for. For ultra realism you could add a parallax occlusion shader like here, but blender GLSL materials don’t currently support this and you’d need the script from the .blend posted on that page to use a shader like this. I find normal maps to be quick and easy to set up and sufficient for most tasks.
The gimp has a fully functional script for creating normal maps from images that I’ve used fairly succesfully. I find that greyscale images tend to give better results, but this might just be me. You can also bake normals from a high poly mesh to a lower poly one. There is an explanation of the workflow in the wiki, also this page.
You can find some good tutorials relating to materials in the information from the Apricot “Yo Frankie!” game project that relate to realtime representations. Baking ambient occlusion to diffuse textures, texture splatting etc. (Though you’re probably familiar with this from rendering 2d images)
To use GLSL materials in the game engine, all textures need to be UV mapped to the objects. This may be why your materials disappeared? Also, procedural textures will not work (I don’t think… they didn’t used to anyway). To use a procedural texture, I render it to a flat plane and save the rendered image to use as a texture.
So I do not yet fully understand what the difference between Loc and Force is.
Just like in the real world, force will gradually accelerate a dynamic or rigid body object. The settings for “damp” and friction will exert an opposing force that will gently slow the dynamic object to rest. The movement of the object is calculated effectively constantly. When using force, the location of the object between frames is extrapolated based on it’s velocity and so can register collisions betwen frames.
Loc simply changes the location of the object and so moves the object in discrete jumps of the same size (resulting in instant acceleration and deceleration). The illusion of constant motion is created by making a jump every frame. This discrete nature as opposed to constant motion leads to issues with collision detection because the object may make one of the jumps straight through a wall or other object.
For ultra-fine control you could consider using the servo motion actuator, but this seems overkill for most applications. Wikipedia explains it well here. (Almost too well, but it made interesting reading for me ;))
interactions like clicking on a door and opening it so you can walk through
In your previously defined setup, the mouse was used for turning the camera so an on-screen pointer wouldn’t work, but you could set up an action for the door object with a 1 bone armature that rotates the door around the hinges through 90 degrees. This action could be triggered by having a near sensor on the door connected to the action actuator by an “and” controller. This would open the door when you’re within a certain distance of it.
In order to preserve usability it might be best to avoid having the user click the mouse to open the door, but this could be achieved by adding a mouse sensor to the “and” controller that recognises a left click (for example), therefore opening the door only if the user is within range and the mouse is clicked.
Since we have two DJs on that location I thought it might be nice to also have sound.
I’ve not messed with sound much, but I’ve read that Blender’s game engine has poor sound support :(. Most people considering including sound in their games seem to recommend PyGame, a Python API that supports more advanced features like playing sound files from hard disk, analog controller support and other stuff. If you can integrate this, it might take the walkthrough to another level, but may take some effort.
[edit]
As far as I know, the game engine only supports .wav files, which are ok for short samples that are reused frequently, but have huge file sizes for anything like music.
[/edit]
Did you also use the old Radiosity engine?
I’ve never used radiosity in the game engine, and didn’t think it was possible. I’ll have to check this out.
Maybe it’s possible to bake the radiosity into the diffuse texture? Since only the camera (and maybe doors) will be moving, this might be a good option in terms of processor overhead and frame rate anyway.
Hmmm… this post just kind of kept growing. I hope it’s pretty accurate and fairly easy to understand.
Good luck.
