Jorrit's blog

It is high time I put an entry in this blog again :-)


I have been doing a lot of stuff lately. Let me go over all my projects one by one and see what the status on it is:

• Crystal Space: it is funny to see how little I actually work on Crystal Space while I move away to work on projects that use Crystal Space. But still I do some occasional stuff on Crystal Space and I do have some plans for the future too. The last few weeks I have been busy cleaning up and also making some preparations for improving performance with more modern lighting/shadow systems (i.e. the light/sector influence system). Also we are now preparing for a new pseudo-stable release which should come out in a few days from now hopefully.
• CEL: Lately I have been doing a lot of physics work (i.e. mechanics property class) for a game that I'm making (more on that later). Physics is nice and with the mechanics property class it is easy to use in CEL and in the XML behaviour layer.
• Crystal Core: there is a lot of artist activity in Crystal Core but little coding activity. I plan to rectify that soon. My first task is to work on the HUD for Crystal Core. However, I'm still waiting for the artwork to do that. I also hope that Eric Vaught can help with the AI system.
• CrystalBlend Lite: for CrystalBlend I'm busy fixing it so it works on my 64-bit linux system. This is a bit hairy as the old code that is being used to parse the blend files depends on the very wrong assumption that sizeof(pointer) == sizeof(int).
• CrystalBlend Full: I still have a few changes I need to make to the design document of CrystalBlend Full (like make abstraction of the event system) but other then that this project is on hold until the Blender coders are a bit more free to help me (i.e. as soon as Blender 2.4 is released I would hope).
• Secret Project: I got a nice freelance job in the fashion(!) industry which I can do in Crystal Space. Can't tell you more about it as there is an NDA.
• Small Crystals (preliminary code name): I'm working on a set of commercial 'small' games using Crystal Space. Mostly puzzle games and similar that make heavy use of CEL and CS. Things like pinball, boulderdash, ... (here is what I'm using the physics property classes for). I plan to make this a commercial CD-ROM with a lot (as many as I can manage to make) of small games on it. All artwork I'll make myself (using Blender and GIMP). When you buy the CD-ROM you will get full source and blend files of all the games. The source will even be GPL or LGPL depending on the circumstances. So in addition to getting (hopefully) nice games to play you also get tutorials and sources for your own games.

So I can keep myself busy for a while :-)

-----

Seems that Crystal Core? has sprung into action again. Xotic is making amazing maps and RaydenSFX is making amazing sound effects. I'm now working on a 3D sound system in CEL (based on the new sound system that has been put in CS the last week) which will enable us to have 3D sounds attached to objects (like machinery, doors that open/close, ...). Crystal Core will also have footsteps, wind, and other ambient sounds. Nice to hear :-) In the mean time Hak'M and Xotic are also working hard on the story. Seems like Crystal Core will grow into a real game after all!


On the negative side I'm a bit hampered in development with the lack of a good linux machine. I would really like to have a new/second hand laptop that can be used for linux. The specs of that laptop really don't have to be amazing but a adequate 3D card is of course needed.


For people who worry about lack of progress on CrystalBlend. Don't worry. I can't do all at once but I will certainly return to CrystalBlend development soon.


Greetings,

-----

It has been a while since I posted someting in my blog. So let's try to remedy that situation now.


Lately I have been working a lot on CrystalBlend. Things are now looking very good and I have a good feeling that this is going to work very well in the future. I also seem to get a lot of support from the Blender community so I hope it will turn out to be useful indeed.


On the Crystal Space and CEL side things are a bit quiet now. There are several smaller things slumbering in the background (like a CEL camera redesign done by aarobber and some other stuff) and thebolt is still working on the lighting redesign.


I'm also feeling like starting another visibility culler soon :-) With the failure of the static PVS I think we still need something that is simpler then Dynavis but can still manage to cull more then Frustvis. The idea that I'm having now (inspired by biki on the #CrystalSpace channel) is to have a static KDtree (as opposed to Dynavis which uses a dynamic KDtree) that is built from all static objects in a level (so it would require objects to be marked as static). This KDtree would actually split the objects to the nodes. The advantage of this approach would be that we can traverse the KDTree in perfect front-to-back order which means that we can use a coverage based culling system that doesn't need the depth buffer. So this would be more efficient because the coverage buffer writes would be a lot faster and also the KDTree doesn't need modifications. The disadvantage is that you must mark all static objects so this method is not really usable for highly dynamic levels. In practice though most levels are about 98% static.


Xotic recently showed me his latest work for Crystal Core. Things are going to look SOO nice :-) When Xotic finishes his levels it is time for me to prepare the Crystal Core tech demo. I think this will really be something very nice indeed!


On the 'looking nice' front there is also a lot of very interesting work done by the team that did the Fuel game. They are now working on something that resembles Doom3 a bit in visual appearance and atmosphere. From what I can see so far it looks absolutely amazing!


Greetings,

-----

Now that I brought the CS and CEL documentation in a better state (not finished yet but at least it is now a lot better) it is time to concentrate on CrystalBlend. I managed to get the keyboard sensor working pretty well so far. The movement actuator works partially. Sufficient to get a very small demo going.


I now started on physics as well. Currently I'm using the mechanics plugin with ODE underneath. In the mean time Erwin Coumans will be working on integrating his Bullet physics library (Bullet Forums) with Crystal Space by letting it implement the dynamics interfaces. If that is ready we can try out Bullet too and see how it compares to ODE.


So far things are going pretty well.


Greetings,

-----

In case you haven't seen it yet there is a nice deathmatch type game at www.nexuiz.com. It is full free (both art and code) under the GPL and it works on linux and windows. The graphics are nice and I think this is the kind of game/demo that someone should make with Crystal Space too. Crystal Core is almost going to be that except that Crystal Core? is a single player FPS and will have more complicated story mechanisms and interactions with the levels (like vehicles you can control and other stuff like that). I think one of the tasks that I need to tackle soon is to implement some kind of shooting/weapon system in the celtestdemo which I can then use as a proof of concept for Crystal Core?.


Speaking of Crystal Core?. Xotic is back and has shown me a few new things he is working on. Hopefully we can soon get a full set of levels and release the first tech demo (after I added some logic to that of course).


I have been working hard on documentation the past few days but a lot more needs to be done still. More specifically I would also like to document CEL better. One question is if the CEL documentation should be integrated with CS or not. I personally am inclined to think yes but not everyone agrees with that (given that they are technically separate projects).


For CrystalBlend I'm waiting until I get some feedback from Erwin Coumans. He is going to attempt to integrate the existing old GameBlender logic into the current CrystalBlend.


That was it for today.

-----

I did it again! I started yet another new project. As if I don't have enough todo already


The new project is CrystalBlend. It is an alternative to the GameBlender project which you can use to create games from within Blender. The problem with GameBlender is that it is no longer maintained well and is showing its age. A Crystal Space based version of that promises a lot more for the future. Especially since it will use CEL and thus have access to the CEL game entity system. The first version will be compatible with the current GameBlender but the plan is to move to a new CEL based version pretty soon. In the end I hope we can even get a new CrystalBlend game UI in Blender itself. That would really be nice.


As to my other projects. All is still in progress. I'm waiting for the new levels from Xotic and when I get those I will start working on the first tech demo for Crystal Core?.

-----

Now that the celtest demo is released I can start thinking about what to do next. Here is a list of things that I have in my head and that I would like to do:

• Extend genmesh with alpha channel support for every color (similar to spr3d).
• Redesign the collision detection system in CS so that it will become possible to initialize more efficient colliders for well known primitives like boxes and heightmaps. It is specifically for the last example that this will be useful as doing CD on a huge terrain is now a costly operation due to the high amount of triangles needed to represent the terrain for the CD plugin.
• Add a new flag to disable rendering a mesh after a certain distance. This is particulary useful for portals. In the celtestdemo that I made there are several portals that are only visible in close range due to the way the level is made but the sectors all use frustvis so they are not culled at all except when they go outside view frustum.
• Make a new visibility culler that tries to find out when portals are invisible and doesn't worry a lot about the rest. A more general version of this would be a culler that only attempts to cull 'expensive' objects.
• I'm considering adding a more general flag system for objects. Currently there are three ways to attach flags to a mesh. You can attach it to iMeshWrapper, to the iMeshObject, or to iVisibilityObject. The problem is that you can't choose. Some flags go to that interface and cannot be used elsewhere. From the interpretation of the flag it is not always easy to guess where it should go. I wonder if we shouldn't have a more generic flag system that is based on string ID's similar to how the event system will work.
• I also want to work on the CEL pathfinding class. I need to find out how to use it and I would like to redesign it a bit.
• CEL needs a new trigger for Line Of Sight.
• CEL needs a new trigger for when two objects collide.
• I would also like a 'notification' property class in CEL that can be used as a kind of reporter for in game messages.
• I need to work on pcmover, pcspawn, and pcnpcmove in CEL too.
• And finally I still have so many ideas for my celtest demo level

So. I think I still have a little bit of work to do.


Greetings,

-----

Yesterday and a bit of today I worked hard on a complicated corridor in my new celtest level. It was complicated because it had to follow the curve of another object and in the mean time I had to open windows between the corridor and the other object. When I later tried out the level I discovered that the new corridor ran straight through another part of the level that I put in another sector for optimization purposes. Since the new corridor was so complicated to make I had no choice but to change the older corridors that intersected the new areas. Luckily they were not complicated so this part was not very hard. But in addition to those corridors there was also an elevator that intersected the new corridors. I couldn't easily move that elevator so I decided to cut the new corridor in two sections with the elevator in the middle. All in all it turned out nicely.


I just upgraded to blender 2.37. I'm really starting to like this tool a lot. In 2.37 there are again a few new additional tools that make it a lot easier to manipulate and transform your meshes. My favorite functions in Blender are extrude, subdivide, and split. Extrude is extremely useful to enlarge areas and give walls thickness. The only thing is that you need to be careful that all normals are facing the right direction. Subdivide is very useful if you have made some room or corridor and you want to add a new door in a wall. First you split the wall from the rest of the mesh and then you subdivide it (with or without the 'Beauty' option). After that you can go to edge select mode and drag the edges so that you get the right size for the door. Then you remove the face and you have a door. The reason to split the wall before doing a subdivide is to make sure that the subdivision will not cause adjacent faces to be triangulized. You first want to subdivide the wall on its own. Later on you can then remove double vertices in the mesh to ensure that all is connected properly again.


Greetings,

-----

Well the new level is progressing very nicely now. I'm using the textures from Xotic which he made for the Crystal Core levels and with those textures it is very easy for me to make a very big Star Wars lookalike level. It looks a lot cooler then current celtest level When I started making the level I didn't think of using the textures from Xotic so the first part of the level doesn't look as nice. I'm probably going to create that again.


Currently I'm fully concentrating on the level but during building of that level I found out that there are still lots of things to do on the code side. Here is a small summary:

• Fix blend2cs for hierarchical transformations. It is hard to find information on how to correctly interprete the loc, dloc, parentinv, orig, and other fields in the .blend file though.
• Add support for pseudo-dynamic lights to blend2cs.
• Add support for animating lights in the quest sequence manager. Also a pclight property class is required for persistence.
• Add a solution for the stuck-in-door problem. Most likely I'm just going to disable CD on the door as soon as it is open.
• A new quest reward to reposition an entity (can be used for a teleporter device).

Today I fixed an important bug in the static lightmap calculator. Apparently shadows didn't cast through portals. For some obscure reason the code that marked shadows relevant was removed. It was not easy to revive that code so I just consider all shadows relevant now.


That's it for now.

-----

nicely into place


Today I managed to change pclinmove so that it is now possible to walk on an object that itself moves. This can be used for moving platforms, elevators, vehicles, ... and it works very well indeed. With this step done I think that a great deal of the machinery needed to develop the Crystal Core game logic is ready now. The only thing I have to do now is wait for the art to arrive (new levels from Xotic and hopefully some models that I can use too). When I have that I can implant a few quests and things to do and that can be released as the first tech demo of Crystal Core.


I want to work a *little* bit more on the level before releasing it and there are still a few minor things I need to do here and there.


Greetings,

-----

On the CEL side things are looking good now. I have a nice working game which is almost finished. One thing that I really would like to do now is to have support for moving on moving objects. i.e. imagine an elevator which is in itself a moving object. When you go inside that elevator and you press a button it will go up or down. In the mean time you can still move on the floor of the elevator. For trains or other vehicles this would work too.


I started sectorizing the game level to get better performance but instead I got worse performance! The reason is easy. There are two sectors: 'inside' and 'outside'. There are about 10 portals from inside to outside (windows and doors). In the 'outside' region there is a landscape mesh object. This object will be drawn essentially 10 times (if 10 portals are visible). Everytime it will be drawn restricted to the portal area but still it means the landscape mesh has to do LOD and other setup 10 times. This is slow. So I started implementing a new feature in Crystal Space. Basically you will be able to enable 'noclip' for a mesh. When this option is set the mesh will not be clipped to the portal at all and it will also only be drawn once. That means that on the first visible portal the mesh will be rendered completely and all other portals to that same sector will just leave the mesh unrendered. This is all nice in theory and I even implemented it but now I have the problem of getting it to work :-/


I also got a new idea for a visibility culler. This idea was sparked from a discussion on the #Once channel. Basically they are having the problem that if you close a door (and the doorway itself is a portal) then it will still render the contents of that portal in many cases. The reason for that is that dynavis is not a perfect culler and the door object and doorway are very close together. This decreases the chance of dynavis culling the portal. Also if frustvis is used then no such culling happens at all. So I'm considering making a new culler that is very simple in nature and would only attempt to cull away 'complex' objects. A portal is a complex object since a portal represents an entire sector behind it. But other objects can also be marked as complex (typically as a function of number of polygons). I still have to decide on how exactly I would do the culling then. The end result should be a culler that is a lot less expensive then dynavis but would be able to cull away portals that are covered by a closed door.


Greetings,

-----

Literally! My work on CEL is progressing very well now. I basically have a very simple game right now. At the start you enter the level in a room with four doors. Three doors are closed and you have to find the right key to open each of them. So the only option is to go through the open door. The doors open on approach and close again when you go further (unless it is locked of course). Picking up a key unlocks the right door. There is also a sphere that you can click on and when you do an entire section of the floor starts rotating so that you can have access to another part of the level. So plenty to do already but still a lot of work. Here is a list of problems I encountered so far that I still need to solve:

• If you happen to be at the wrong spot when the door opens you can get stuck in the door. That's bad. I have to think about a suitable solution for this roblem.
• There is no range checking on mesh selection. That means that you can click on a button or pick up an item from very far away.
• Cally can't easily run on some of the stairs. She needs to be able to take bigger steps without having to jump.
• I need to design the level carefully so that you can't jump to places you are not supposed to go.
• Celtest has some custom code that is only relevant for basic_celtest level (i.e. selection on actor and also the behaviour). I need to find a way to move that to the basic level so that the game level doesn't suffer from that unneeded functionality.

In addition to the problems encountered above I still need the following enhancements to CEL:

• A pclight property class.
• A sequence operation to animate a pseudo-dynamic lights.

All in all I'm very happy with the way this is working out. The quest manager is appearing to be a very useful tool for making game logic. It is even powerful enough to completely drive a simple game. In real full games you would of course combine it with behaviour logic for more specialized control.



-----

There are at least two property classes that are interested in creation of other entities. One is pcspawn which is a property class that is responsible for spawning entities of a given type at certain intervals. This can be used for creature spawn points for example. Or places where health-kits can spawn. The other property class is pcquest. I would like to add a reward there that creates an entity. The problem with entity creation is that entity creation is not simply a matter of making the entity. You also need to supply a behaviour and property classes. And you also need to set up those property classes. pcspawn partially solves that by allowing you what property classes and behaviour to use at entity creation. However that doesn't help with setting up those property classes so this really is not very useful. The best way to solve this will be to allow entity factories. This is a new concept I will soon add to CEL. That way you can define an entity factory exactly like you would define an entity (in XML addon). pcspawn and the pcquest entity creation reward can then refer to a factory to create the entity.


With all the new work that I have been doing I think it is soon becoming time to document all this. The CEL documentation is very limited and these new property classes are rather advanced. Documentation is badly needed. This will be my next task after finishing the simple game.


Greetings,

-----

Made some good progress on celtest now. I rewrote it so that it now uses the zone manager instead of pcregion. That makes it easier to seperate the world file from the entity definitions. I'm now busy moving all entity creation from code to that entity file so that we can easily substitute other levels + entity definitions for celtest. When that's ready we can put two levels in CEL/CVS: basic_level and simple_game. The latter will be the new level that I'm creating which will have entity definitions that make it an actual simple game.


Looks like Eric is getting his iMac soon. This will be a great boost to the community if Eric gets faster hardware. Even with his very old hardware he manages to do a lot of amazing work on Crystal Space. I can hardly imagine what he will be able to do with a faster computer. Now hopefully the remaining money (plus new donations, hint hint!) can be used to spice up my computer situation a bit. Because after Eric gets his new computer I will be the one with the lowest-end hardware.


Greetings,

-----

Bah, today is one of these days where you spend more time debugging some stupid problem then doing useful coding. In this case the bug is probably not even caused by me. The problem is that on destruction of a mesh wrapper there is a 'pure virtual method' called. Debugging this is hard since the program doesn't crash so you can't get a decent stack backtrace easily.


If all debugging fails I might have to do a 'binary CVS search'. That's the technique of going back in time with CVS trying to find the exact moment at which the bug occurs.


Wish me luck!


Update! The problem is solved now! Time to move on :-)

-----

The new map is progressing nicely. Please don't expect too much of it. I'm not an artist. It is just going to be slightly more interesting then the current celtest map (partsys). It will contain a landscape and a few more areas to visit. Soon I'll start adding the game logic to it. That will require a bit of coding though. More in particular I need to:

• Add support to blend2cs to allow pseudo-dynamic light export.
• Add a new pclight property class to be able to persist the state of lights.
• Add reward to set light intensity.
• Add sequence operation to set/fade light intensity.
• Add sequence operation to move/rotate an object.
• Extend celtest to use the zone manager to load levels.
• And probably a few more things I forgot...

So I have my work :-)

-----

The celtest application and map are getting a bit old and primitive. I'm working on a replacement which will be a little bit more interesting. It will be more like a game with puzzle elements to better demonstrate the things you can do in CEL (like quests and so on). I'm making the map in blender using blend2cs.

-----

It is always satisfying when things work as you intended. In this case I'm talking about the sequence stuff in the quest manager. Today I managed to get a first working sequence in the test quest for celtest. It doesn't do much. Just print out a bunch of numbers during one second. But it proves that the system works. Additionally even persistence works. I can save the state of the entire quest including the running sequences and then later load it again. The quest and sequences just resume where they left off. Pretty nice.


The work will now be in adding more sequence operations to the quest manager so that this actually becomes useful. Also it will be great to have a quest trigger that fires when a sequence finishes. That way you can delay switching of the 'dooropen' state in a quest until the door is actually fully open.


We got a nice offer from Pace University to donate the full Macintosh computer to Eric. If that deal goes through then we need to find a new purpose for the money that has been donated so far (around $1000 USD). One idea is to replace my linux computer which is slowly starting to have problems (bad HD and overheating problems). Also it is underpowered with respect to 3D hardware which means we can't easily test the more advanced renderer features on linux (most of the other CS team members are using Windows these days). And of course I wouldn't mind a new computer :-) But of course that means we need even more money then $1000.

-----

I'm thinking about adding a nice new quest to celtest. Basically I would add a door entity to the world which is initially closed. If you approach the door you would get a message saying something along the lines of 'You need to find a key to open this door'. Then you have to go to another room, pick up a key and with that key you can open the door. I still have to do a bit of work before I can make such a quest but I'm not that far from this goal now. Basically the sequence stuff needs to work and I also have to work on a trigger for the inventory system.


Some time ago I came to an important realization. The persistence system in CEL is *almost* general enough so that you can do the following:

• Play pure CEL game A
• Save the game to 'savefile'. Then exit.
• Play pure CEL game B
• Load the previously saved game from game A.
• Bingo: game B becomes game A.

Not much is needed before this can work. It requires that game A and game B are pure CEL games. This means that they should have a behaviour layer that is a plugin (for example, the python behaviour layer or a custom one that is build as a plugin) and it requires that I add a little extension to the persistence system so that the SCF ID of the behaviour layer is saved too. That would allow us to dynamically load the behaviour layer plugin when the savefile is loaded.


Once this is done you would basically be able to run (for example) the CEL boulderdash game and then load a save file from Crystal Core in that. This is fun stuff :-)

-----

I'm working fully on CEL now. The idea there is to create a full fledged quest manager which will be used for defining the story elements in Crystal Core. Basically the entire game logic and game structure will be defined with the quest manager in XML. The quest manager basically works but right now I'm working on adding sequences to it. I would have liked to use the existing engine sequence manager in CS but unfortunatelly the design of that doesn't make it easy for me to use that in CEL except for small and easy cases (like a fan that rotates or a light that goes on/off on proximity). But in all other cases (like doors that open and close in response to some quest element) we need to be able to save state and resume sequences in the middle later. This is not possible with the CS engine sequence manager. The new CEL sequence manager is part of the quest manager as it is closely tied to that and it will also reuse the triggers of that.


After this I hope I can incorporate some real working quests in Crystal Core. Hopefully Xotic will soon have some new levels so we can start to work on the first tech demo then.


I'll keep you posted.

-----