GLSL shading is now in blender, thanks to the work of our rockstar coder Brecht. Just enable it in your preferences under System & OpenGL, and change to the shaded draw type. Among other amazing things, this means normal maps in 3d view!

Along with this also comes the ability to paint multiple textures directly onto your objects using texture paint mode in the 3d view. Because with glsl blender can draw materials with texture stacks that contain stencil maps, splatting grass and dirt onto your terrain is as simple as using texture paint mode with a stencil map assigned to the uvs. It’s such a beautiful thing. Watch the video to learn how this is done. The idea is that this same texture stack will then be exported to crystal space for splatting for the game.

From Amir, one of the Crystal Space developer working on camera and movement system improvements:

No it’s not the new Hollywood blockbuster, it’s my test application for developing the camera and character movement controller! Because it takes a while to update python bindings when developing C++ code, I use this interim solution while doing heavy development.First you see character walking in and out of the camera. There is a slight spring, but only within a certain range of the relaxed position. You can visualise the camera as having a hard pole with a spring attached to the player. When the player walks into the camera, the spring becomes depressed and the camera will start to move backwards. If you move beyond the spring then you will just push the camera. So we calculate the desired forward movement to reach the player within our range for the camera using the equations:

cos (x) = camera_direction . camera_to_player
move = distance * cos (x)
=> move = distance * (camera_direction . camera_to_player) – forward_position_offset
Then you next see tilting the camera up and down. There is no standard or universal behaviour in games really for tilting so I took a bit of creative license here. Annoying the player with too many controls for just a camera can just be well, annoying. So how to incorporate the zoom? Well this looks like a nice solution. We actually describe the ‘hard-pole’ positional offset of the camera we just described as an elevation angle from the ground and a distance and can use the normal circle equations to find the camera position for tilting. For this zooming effect I just make the distance proportional to the elevation angle. You can follow this link to know best cameras.

Then it’s collision detection when you walk into the wall. This more than anything causes lots of pain. Some games don’t even let you pan into the wall 🙂 cheaters. Not only is the collision detection dependent on a calculation in one place, but another calculation is dependent on the collision detection in another place. Throw in 2 or 3 more of these cases and then you have dependency nightmares. Then panning into walls at large perpendicular angles when you first touch the wall when panning, usually means that the camera is oriented halfway between nothingness and the world. Therefore you need to offset the camera from the wall. But if you get in close, then this offset will cause the camera to flip on the otherside of the player and so you need to linearly decrease this. Then you also need a vertical offset for the camera, above the players collision box if the target is inside the player… and you need to interpolate this value too. Coming out of the zoomed-iness the camera will jump, so you must interpolate the zooming out also. This needs some more work, but well everything interferes with each other 🙂

To finish off there’s some preliminary character movement demonstration. I haven’t worked too much on this yet so it’s a bit rough. TODO: Fix the jumping of the camera between movement modes. 🙂 The first mode is when you go into fighting mode. No enemy is around so you just strafe around. Suddenly an enemy enters the view! The camera locks onto the target and you move around the enemy, rolling and dodging and doing attacks. The player movement needs work though yet, like smoother turning when moving diagonal after moving straight. Straight to straight movement should be fast though we think.

Any suggestions for you preferences? What do you think of mouse control for the camera? This is popular but I sometimes get annoyed when I’m accidentally knocking the camera. Below is the written document for player movement.

From Apricot:

Beside of developing in the Blender Institute we working remotely with other Crystal Space developers, they made a lot of new amazing improvements like new animation system, smoother collisions, new logic system, also camera, movement system and many other things. So without their work it would be impossible to release an industry-quality game. Cheers guys !

This video demos some additions to the apricot branch of blender for snapping, library browsing and baking.

Download the OGG File

We are preparing to open our repository for a public to feel real Open Source power. At this moment we need people who will help us with making package releases for GNU/Linux, Windows and OS/X. So if you have a time, if you know something about packaging and bug tracking/solving write to us ! Apply to: res[-a-t-]crystalspace3d.org

Some people are curious how everything works, so I’d like to explain how we combining every piece together and putting life into it.

What is the biggest obstacle in the typical development process ? Well – let’s divide that process to 3 stages: planning, implementing, watching results.

1) Planning: It’s a very cool stage, you can sit in comfortable place, take a favuorite drink, piece of paper and now you thinking and inventing, nothing is wrong here, you need a good plan.

2) Implementing: So before you start Implementing your brilliant alghorithm you spent a lot of time already, but can you do the same with implementing ? Well, better not too much. It is also nice stage, many people enjoying programming for example, but if implementing stage is harder than planning – then something is wrong. Tool serves for human not human for tool.

3) Watching results: Worst case is when you need to wait too long between implementing and seeing results. It’s a waste of time, really nothing interesting happens there, so perfect time for this stage is 0. Now we have much modern tools but in the 70’s you waited for a result a couple of days waiting in a queue and converting program to punched cards. Later in the 80’s you need to write program, compile, link then see result so it takes a couple of minutes. In the 90’s during game development people need to export 3d model, put into right directory, write in code loading and displaying, initializing etc, then compile, so still a couple of minutes. But today we have 00’s (?) 🙂 So in our tool this time is Zero. We can see results imediatelly.

When you see on screenshot:

Left-top corner: working game using external engine, you can play there.

Right-top corner: blenders 3d window, you can add, delete, translate and edit objects,just blender.

Left-bottom corner: visual scripting using logic bricks.

Right-bottom corner: python console so you can program in realtime and everything changes in the same time in the game.