Archives for: May 2007


Permalink 22:02:44, Categories: Optimisation Framework  

Overview of project

Hey, my name is Mike Gist (aka Xordan). Currently I'm a first year student studying Computing at Imperial College London. I'll be working on the optimisation framework project for the next few months and I'll be keeping note of my progress here and explain a bit about what I'll be doing now.

At the moment there are various optimisations that could be done using SIMD instructions, but there is no way to properly detect support and use the correct code path. Obviously an Athlon XP won't be able to use SSE3 instructions, and a PPC processor will be able to use AltiVec only.. assuming it supports it. My job is to add runtime and compile time detection of the supported instruction sets (both for the processor and the OS), add a method for the correct code path to be selected and used, and then to make use of this in various places in the existing CS code.

Within the scope of this project I'll be concentrating on MMX, SSE, SSE2, SSE3 and AltiVec. Later I will expand and include SSSE3 and SSE4, but those aren't priorities for now.

Currently there is a class called csProcessorCapability which contains some MMX detection code. I plan to rewrite all of this, but keep the name :) There are different ways of detecting supported instructions (asm or inbuilt compiler functions). VC has a function called isProcessorFeaturePresent() which makes detection very simple. For gcc it's a bit harder, we will need to use cpuid to get the info. We will know the minimum instruction set supported by an architecture so we can short cut some checks as well (amd64 all support from MMX through to SSE2 for example).

The csProcessorCapability class will look something like this:

class csProcessorCapability

csProcessorCapability() {}

~csProcessorCapability() {}

static inline bool HasMMX() {}

static inline bool HasSSE() {}

static inline bool HasSSE2() {}

static inline bool HasSSE3() {}

static inline bool HasAltiVec() {}


static inline void Initialise() {}
static bool isInitialised;
static bool supportsMMX;
static bool supportsSSE;
static bool supportsSSE2;
static bool supportsSSE3;
static bool supportsAltiVec;

static inline void CheckSupportedInstructions(bool MMX, bool SSE, bool SSE2, bool SSE3, bool altiVec) {}

The CheckSupportedInstructions function is run once by the Initialise() function, and contains all the detection code. If it's already known that an instruction is supported or isn't supported then this will be passed to that function and it won't be checked. I'll go into more detail as I progress.

Compile time checks will be for __m128 support (checking for xmmintrin.h), so we know if the compiler actually supports this stuff :) No compiler support, no extra cpu juice. Some other things will be used, like target arch, which will allow us to rule out some instruction sets. I'll add an entry just on this when I get to it. First thing is getting that class written. I'm giving myself two weeks to finish the detection, then I'll move on to making use of it. I'm hoping to get a good chunk of that done by the mid-term evaluation, leaving me about a month to finish it and optimise some areas (to be chosen) of code. I'll detail that a bit more very soon.

Soc Starts!

Hi there!

Well, coding time started this monday and I wanted to keep you informed on my progress and my schedule for the next weeks.

As I explained before, I will be working in three main sections (Steering Behaviours, Path Finding and Decision Making). I am planning to work four weeks in each of them (hoping I only need 3 weeks for the first too). I will be starting in steering behaviours (which is needed by pathfinding), then I'll be covering Pathfinding and, finally I'll be working with Decision Making.

After all of this I will make a simple but complete application showing how to use all of what I made.

I hope I'll be soon showing you some code from steer property class, I've already starting coding and I am waiting to test it in some application.

That's all for now,
talk to you soon =)

Permalink 11:34:49 am, Categories: General  

Public Relations!

I'm pretty happy to announce CS^2 (or CrystalSquared). Basically Marten and me will now give commercial support for people who are interested in that kind of thing. Basically if you have a bigger problem with CS that you really can't solve (and we can't solve without more extensive work), you want to get some help starting up a new project (i.e. setting up the basic project and stuff), you want help on some very big bug, you want to pay for an important new feature in Crystal Space, or you want some private tutorial or lessons then visit and we will try to help you as good as we can. Maybe we can also offer commercial support for other things we didn't think about. Just tell us and we will see what we can do. A few weeks ago I had the idea to start this but we were a bit worried about how to do this exactly. It is important to emphasize that we absolutely do NOT want to decrease the quality of the already existing free support in any way. Preferably we even want to improve on that even. This commercial support option is only there for the kind of support that we wouldn't do for free since it is too much work. So hopefully this all works out to the best. We're not the first Open Source project to offer this kind of support. Ogre3D does it for example.

On public relations and publicity I also updated the pages at ohloh. Ohloh is a rather interesting site where you can submit a project and ohloh will calculate various statistics about popularity, code base, contributors and so on. We have the following projects there right now:

If you visit these project links then you can 'stack' a project indicating that you use that project. You can also give 'kudo's to the project developers which gives an indication level of your appreciation of that person. If you are a developer of one of those projects then you can link your username with the contributions done on that project and if you additionally placed yourselves on the map then it will show on the little earth map with every project that you stacked and/or are a contributor of.

In the mean time I'd also like to note that we're very busy working on the 1.2 release now. Hopefully we can release 1.2rc1 in a matter of weeks now.

And yes, the 'secret project' is still in planning stages :-)


Permalink 06:15:29 am, Categories: World Editor  

Editor Object Abstraction

Since my last post, I realized how important SCF is in Crystal Space and how it could help me implement the property editor, tools, scene browser, and asset browser in a way that remains extensible.

In my last post, I talked about how I will implement the property editor. I'll now talk about how to do the rest of the major parts.

When something in the editor needs to know about what interfaces an object implements, it must query each possible SCF interface until it finds a match. When you have all of the CS interfaces, all of the CEL interfaces, and user-defined interfaces represented, there is a lot of querying going on.

Editor object diagram

Over the weekend, I spent some time to come up with a class EditorObject which abstracts each iBase* object in the editor. This class will keep a list of the interfaces which an object implements. Since I need to do a lot of SCF interface querying, and querying isn't particularly efficient, this cache should boost performance. More importantly, it provides an abstraction of an editor object--no matter what kind of interfaces the object implements, there should be a consistent way of getting/setting the name, parent, and getting the type (factory, instance, or other) and properties.

For each SCF interface, there will be an implementation of iInterfaceWrapperFactory. This will create instances of iInterfaceWrapper, only if the passed iBase* implements the particular interface which the iInterfaceWrapperFactory wraps (it determines this using QueryInterface). Each iInterfaceWrapper implementation will keep a pointer to the queried interface to carry out requests for the Name, Parent, Properties, etc.

Upon construction with an iBase* object, the EditorObject calls each registered iInterfaceWrapperFactory on the object, and stores the resulting iInterfaceWrappers in a list. It stores iInterfaceWrappers whose iInterfaceWrapperFactory::HasNameAttribute() and HasParentAttribute(), respectively, return true, separately, but in addition to the aforementioned list. It does this so it can provide constant time access to name and parent attributes. I can't think of a case at the moment in which one object has at least two interfaces which provide a Name attribute, but if this becomes a problem, certain interfaces could be given a higher priority than others. Even in this case, the other Name attribute can still be edited in the property editor.

How does the Scene Browser and Asset Browser know which objects to display? EditorObject asks each iInterfaceWrapperFactory for the type of the object implementing the interface. By type, I mean instance or factory. For those interfaces which do not help identify whether an object is an instance or a factory, they return unknown type. The EditorObject then stores the resulting type. Ideally, all interfaces return unknown, but one which returns either instance or factory. If there is a conflict where at least one interface says it is an instance type and at least one says it is a factory type, then the logical solution would be to set the resulting EditorObject type to unknown. In this case, both the Scene Browser and the Asset Browser could show it. This isn't as uncommon as it might sound, although I can't think of an example.

The Property Editor will also need to know about the properties from each interface. Here EditorObject will ask each interface for a list of properties. I still need to come up with a property representation which these GetProperties functions use. I don't think it would be a good idea to have the interface wrappers tied to wxPropertyGrid.

Instead of showing the interface name as the category in the property editor, there will be a name based on logical groupings of properties, like "Surface", for properties related to a surface. The idea is that there is a better grouping of properties for editing than the groupings dictated by the interfaces, which were designed to be good groupings for runtime. To implement this, each property will specifie under which category that property should be displayed. Ideally, these category names would be standardized. For the advanced user, the underlying interface name can be shown in the property description, and optionally, the properties could be grouped by interface.

Finally, Tools are interested in what interfaces an object has so that they can determine whether they are available. They can use EditorObject::HasInterface to query for interfaces using cached results.

On a more practical note...
My mentor kindly created a branch for me in
I've gotten both wxAUI and wxPropertyGrid samples to compile from within the CSExtra source tree, by including wxPropertyGrid sources in the tree and assuming wxAUI is built into wxWidgets. I should require wxWidgets 2.8+ since only that has wxAUI, but I haven't messed with the standard configure check yet. A more elegant way would be to make an additional check for wxAUI. In the case that it isn't present, I could have the PanelManager use some sort of static layout with splitters, but this isn't a priority.

In my next post, I'll talk a bit about registering objects with the editor and selections.

I hope to really iron out the design during this week so I can get a good start on the code. I'll try to come up with a schedule tomorrow. Signing out.

Permalink 03:34:59 am, Categories: Personal Log  

Personal Log 28 May 2007

I will be traveling from Grand Forks to Minneapolis for the better part of the day tomorrow. As such, I probably won't be making a log entry for 29 May 2007. I will be addressing the following issues when I get back home to Minneapolis:

  • Determine problems with parsing of XML files using current setup
  • Make UML class diagrams more concise and readable
  • Develop Use Case documents
  • Finish basic application and parsing of a simply XML file

Once these items are finished, I will begin working on the geometry conversion functionality in the COLLADA conversion library.


Permalink 10:06:56 pm, Categories: Design Log  

Design Log 28 May 2007

My goals for today are the following:

  • Get iDocument code working correctly
  • Fix UML Class Diagrams
  • Create Use Cases

I began tackling the first item on the list, but ran into a few troubles, which I am still trying to figure out (although the day is not yet gone ;) ).

Basically, what it amounts to is that I have been working to try and get the basic iDocument system figured out. It's actually very easy to understand, and pretty easy to implement, but I am getting a segfault which confounds me. Specifically, I have the following code to load a COLLADA file:

colladaFile = fileSystem->Open(TESTFILE, VFS_FILE_READ);
        if (!colladaFile.IsValid())	
		cout << "Attempting to open: " << TESTDIR << TESTFILE << endl;
		return ReportError("Error: Unable to open COLLADA file on VFS.  Terminating.");

	// This works
	csRef<iDataBuffer> buf = colladaFile->GetAllData();
	//cout << buf->GetData() << endl;
	// This does not work

One would think that the colladaDocument->Parse() calls would actually parse the file in question, which happens to be a COLLADA file exported with Blender. Since COLLADA files are XML files, the XMLRead plugin (or the XMLTiny plugin) should be able to at least PARSE the file. Instead, I get a segfault when I attempt to run the program. The lines previous to it (the ones commented with // this works) work fine - the file is clearly read into the data buffer and then output again, if I want it to be. It's the parsing that seems to be a pain.

The second item hasn't yet been accomplished, due to some problems with Java on my current workstation, and thus my inability to use my current UML tool: Visual Paradigm. I intend to get this problem fixed by tomorrow afternoon, but I haven't got the slightest clue why install4j doesn't work. (There were some problems with the system, so I decided to reinstall VP. When I tried to do so, the installer gives me a null pointer exception. Wierd).

I am currently working on the third item on the list, and should be finished by late this afternoon. I will publish an update when I am finished, along with downloadable versions of the Use Case Documents.


Permalink 10:14:52 pm, Categories: Design Log  

Design Log 25 May 2007

After beginning development of the SCF interface for the COLLADA Conversion Library (which, I believe will be called iColladaConvertor), I have decided that constructing a rudementary Use Case diagram would be beneficial. This will, at least, allow me to visualize what it is I am trying to keep in my brain - that is, what the library will actually DO, and how that will be structured. A diagram is attached:

COLLADA Conversion Library Use Case Diagram

Ideally, the user will be able to interface with the library in multiple ways. I am designing it such that the user could concievable convert COLLADA files to Crystal Space formats 'on-the-fly', although this would be time consuming. I will develop an alternative method, such that instead of calling all of the individual ConvertGeometry(), ConvertRiggingAnimation(), etc... functions, they would be able to do a complete conversion of all COLLADA files before the game starts, (or possibly, as things develop, before a zone is loaded). Of course, the general idea would still be that COLLADA is an interchange format, and thus, most of the conversion should happen offline, before the game ships, this would allow users to support COLLADA formats in-game, for example, with users who wish to use COLLADA formats for modding a game already constructed. At any rate, the idea is to abstract as much as possible, so that it 'just works', but yet allow those users who may only want to display the geometry of a COLLADA file (i.e. for testing purposes) and not anything else (e.g. the shaders, lighting, animation/rigging, etc...) to access individual conversion functions.


Permalink 03:33:13 am, Categories: World Editor  

Class Diagram and some Q&A with myself

Now that exams are over, I can start the real work on the CS editor.

I decided to start off by trying to make a class diagram of the editor. This allows me visualize the system and locate problem areas in the design.

Class Diagram

There are a few issues that I've identified right now:

  1. What type do I use for the selections?

    Since I'm allowing heterogeneous selections, I need an array which can hold basically any CS engine object, including factories. I'm thinking a csWeakRefArray of iBase will work. It should use weak references since, we don't want to keep objects around if they deleted. Perhaps I need to call csWeakRefArray::Compact() before any function dealing with the selection, so I don't need to deal with invalid objects.

  2. How do I get the property editor for the selected objects?

    Each SCF interface will have its own property category, and each of these categories will be registered with the main property editor. To display the appropriate property editor for the selection, for each object, I should query each possible SCF interface until I find a match. The downside of this is that it has to test each and every interface for each object.

    Something like:

    class MeshWrapperPropertyCategory {
      // Pretty name for the category
      const char* GetCategory() {
        return "Mesh Wrapper";
      bool AddToEditor(iBase* obj, PropertyEditor* propEditor) {
        iMeshWrapper* mesh = scfQueryInterface<iMeshWrapper>(obj);
        if (!mesh) return false;
        // ...
        // Add properties to propEditor.
        // These will also setup property change handlers which will call the interface's functions.
        // ...
        return true;
      // Property change handlers go here.

    This should allow you to edit objects of different types as long as they share some common SCF interface. The property editor will only show the interfaces in common. This will also reduce the amount of querying being done, since if the first object doesn't have interface X, we don't have to check if the next object has it.

  3. How do I register the tools with the toolbox?

    When a tool will registers itself with the tool manager, the tool manager should publish a ToolAdded event to its listeners. Among the listeners will be the ToolboxPanel. This should solve that.

  4. How to draw special stuff like the selection, manipulators for the move, rotate, and scale tools, or billboard icons for lights so you can select them visually?

    These should be handled in different classes.

    The CS view should draw the selection bounding box and the billboards for lights.
    The move, rotate, and scale tools should draw the manipulators.

  5. Where to use SCF interfaces in the code?

    I think one of the annoyances of CStudio was that everything was an interface and you had to put up with a lot of SCF boilerplate and interface querying to do anything. That said, I think that parts of the editor which are meant to be implemented by plugins should use SCF so that I can leave the dirty work of plugin loading to SCF. So, you'll probably end up seeing iTool, iPanel, and iAction. I'll have to read up more on SCF and talk to my mentor to make sure this is what I want.

Still, the diagram is missing some detail, e.g. tool and property category registration, various events/listeners, settings manager, and many tools/actions are not shown.

I will try to come up with a more complete diagram tomorrow and then I'll try to sort out any further difficulties. Hopefully I can get my hands on some code soon. In the meantime, to entertain my thirst for action rather than abstract thinking, I will try to set up the build system to work with wxAUI and wxPropertyGrid.

Permalink 03:15:37 am, Categories: Design Log  

Design Log 23 May 2007

I began implementing what will become the COLLADA Conversion Utility. I started out with this piece, because I am working to learn the basics of iDocument/iDocumentNode usage. It's fairly straightforward and simple, but as the program evolves, it will be more complex. Right now, all the application does is open a Crystal Space Window, and associate with a document. It's probably not necessary to have it as a Crystal Space Application, but since I had a template for this, it seemed easiest at the moment. I will probably change it tomorrow so that it's just a standard application utilizing Crystal Space functionality.

Since the SOC hasn't actually started yet, I've been taking it easy and just mainly focusing on research. Thus, my posts until the 28th will probably be fairly brief, but you can expect more detailed log entries after May 28th.


Permalink 04:07:44 pm, Categories: General  

Stuff ...

Why is the title of my blog so often 'Stuff...'? That's because I just can't find a good title for the jumble of things I'm talking about :-)

Anyway, I finally started work on Crystal Core again. Our main artist (Xotic or Anders Wisur) has catched a major case of 'Real Life' and he told me that he will only be cured of that around August. So until then the art side of Crystal Core is pretty much stalling. But I decided to work on the game logic again. So now I'm working on a new shiny weapon system. You will be able to pick up weapons and ammo and switch between weapons. Most of this is already working to some extent. But I need more models for weapons, ammo, and also visual effects.

Soon we are going to branch CS and CEL 1.2. Then we can finally start working on fixing the last bugs for 1.2 and release. It is hard to keep on schedule here. We really could use some more developers focused on fixing bugs and doing more 'mundane' things like completing features and such.

I also picked up a VERY old hobby of mine: electronics. When I was a kid I used to play with digital electronics a lot (making small logic circuits and such). But then I got my first computer and for more then twenty years I completely forgot about it. But now my children are starting to get in the age that they are also interested in stuff like this so I picked it up again. This time however I'm concentrating on analog electronics. More specifically I'm trying to build analog synthesizers. Nothing fancy. Just playing around a bit with transistors and 'opamps' :-)

To pay for my new hobby (among other things) I thought that it would be nice if I could finally make some money out of Crystal Space. So we (me and a few others) are considering starting some kind of consultancy site on Crystal Space and CEL. So we can give commercial support for projects that are interested in that kind of thing. OGRE also has something similar. We'll see how this works out. Once we are ready with this I'll post an announcement.

Edit: forgot to mention that planning for the 'secret project' is still in progress :-)

That's it for today. See you in my next blog post!


Permalink 10:54:13 pm, Categories: Design Log  

Design Log 22 May 2007

I have been working on the design aspects of the COLLADA Conversion implementation. My primary goal at this point is to create an overall structure of where I want to go, before beginning actual coding on the 28th. I have constructed a basic (very basic) class diagram. I probably should've created a Use Case Diagram first, but I feel this would be somewhat of a waste of time, as I already am familiar with what the system should do, and how it should interact with the user. In the case of a use case diagram for the library, this might be useful, but I want to design one such that it exhibits the traits necessary for the first iteration. The basic class diagram is attached. The XMLFile class, as well as the Translator (basic class) will more than likely be replaced by iDocument and iDocumentNode classes, which are already present in the CS codebase. I just placed them in for now, so that I have a direction of where to proceed and what I need to implement.

Additionally, I will be looking into researching how the iDocument interfaces work, and how to use them in my implementation, in the next day or two.

COLLADA Conversion Library Initial Class Diagram


Permalink 07:16:25 pm, Categories: Steering Behaviours  

Some examples

Hi there!

This few days I´ve been working in Steering Behaviours.
I´ve been writing some code, basically getting some ideas from pcmover property class and upgrading it.

This property class is based, mostly, in Linear Algebra and High School physics. Most of what I am doing in here is performing calculations with vectors.

For better understanding I will put some images I drew in paint (yeah I know is lame but is the best I could come up with =$)

As you can see, everything is about determining an entities direction to perform its current task.
This task could be seeking, pursuing of fleeing from a target; while avoiding obstacles, or separating
from other entities, etc.


Permalink 12:40:43 am, Categories: Design Log  

Design Log 10 May 2007

I began working on the overall design of the project. I am experienced with UML and formal design processes, so I will be drawing upon that expertise in order to make sure that my project is successful. The package diagram (designed to illustrate which distinct packages, or components of the software need to be developed) is attached.

Package Diagram for COLLADA Conversion Project

The overall goal is to define a library which will transform (either on the fly, or offline) a COLLADA file to a Crystal Space world or library file using an XML translation process. Thus, an XML interpreter will be necessary. The idea is that both COLLADA and CS files are XML files, and should be verifiable. Thus, I might be able to diagnose and eliminate errors before they cause the program to crash or whatnot - if it's not valid XML, throw it out. Also, while the XML interpreter is going to be a class inside of my design schematics, I assume that Crystal Space already has an interpreter, as well as an XML File class.


Permalink 12:27:22 am, Categories: Personal Log  

Summer of Code to Begin

Ok, well I intend to keep a daily log here of my work on the COLLADA conversion utility/library for GSoC. I probably will be posting off and on until around May 20, but after that, it will be a daily (perhaps more than daily) log. I am really excited to begin working on this project. I have been looking forward to it for the remainder of this semester - thinking 'man...if I just get through these next couple of weeks, then I get to do cool stuff' Hehe. Anyway, for those of you who I have never met, my name is Scott Johnson. I'm a PhD student at the University of Minnesota. I have worked with Crystal Space for about a year and a half now, but this is the first time I am going to get the opportunity to really get my hands dirty with the engine itself (rather than applications that use it). I hope this will be a jump off point for me to start working continuously on different parts of the CS engine.

Say hi if you get a chance - my nick on irc is jwir3, and I'm always willing to chat over email. scottj {at} - I love meeting new people, especially those that share my interests, so don't feel shy to drop me an email!


Permalink 01:27:24 pm, Categories: General  

Warning! Exciting future ahead!

This is the first time I'm using the new blog system.

Here is some good news! Besides the upcoming conference which is always exciting, there is the possibility of a VERY nice upcoming project which has the potential of giving CS a huge boost. This boost would be in the form of upgrading the public image of Crystal Space (i.e. A PR boost) and also a technical boost. We're currently still in the negotiation phase and since a big project like this requires considerable money we're probably going to have to organize a big donation campaign. But we'll see. At this moment I can't tell you much more about this project.

On the Crystal Space 1.2 side things are a bit slower then they could be. There is still a lot to do and too little time...

Then there is also Google Summer of Code. Hopefully we can get a lot of good things from it this year.


Permalink 04:33:59 pm, Categories: Pathfinding  

Statically definition of graphs


I have been reading section 4.16 of Crystal Space manual (Format of Map Files). I have already think of a way to define graphs in an xml, first of all I think the new world file should look like this:

initialization part:
one texture specification section.
one material specification section.
one shader section.
one sounds section.
one variable section.
one plugin section.
one settings section.
zero or more start locations.
zero or more library specifications.
zero or more keys.
world elements:
zero or more add-ons.
zero or more mesh factories.
world definition:
zero or more sectors.
one ore more graphs
zero or more collections.
action section:
one sequence section.
one trigger section.

I think one graph should be specified for each sector and a special kind of edge should be included in the nodes which connect two or more sectors.

This graph section should look like this:

node id="0"
position x="0", y="0", z="0"/
edge to="1"/
node id ="1"
position x="50", y="0", z="50"/
edge to="0"/
edge to="-1" sector="sector_name"/

BTW: this is meant to be xml but I didnt get to write it correctly, I will re-write this later :)...

Permalink 04:25:38 pm, Categories: general  

Welcome to blogs

This is the blogs service, providing blogs for members of the CrystalSpace community. At the top of this page you can see a list of all available blogs.

Also take a look at the CrystalSpace Planet which aggregates blogs from this and external services.

If you would like to have a blog on this site you need to follow these steps:

Similarly, if you have an external blog or feed (e.g. project news) you can get aggregated by Planet by writing a mail to with the URL of your feed.

May 2007
Mon Tue Wed Thu Fri Sat Sun
 << < Current> >>
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Blog All Title

This is the long description for the blog named 'Blog All'.

This blog (blog #1) is actually a very special blog! It automatically aggregates all posts from all other blogs. This allows you to easily track everything that is posted on this system. You can hide this blog from the public by unchecking 'Include in public blog list' in the blogs admin.



XML Feeds

What is this?

powered by