3D object selection

We are now able to select 3d objects by mouse clicks (2d object selection was already part of the ScummVM Wintermute port). Take a look at the following screenshot:

The cursor indicates that it is pointing onto our main protagonist.

Essentially what happens is that we have a bounding rectangle (constructed from a bounding box) for our model, which is added to a list. Every frame the list is traversed. If the mouse coordinates land in one of the rectangles, a more precise test is performed. In case of our model this means that we send a ray into the scene and check if it hits one of the triangles of the model. If so, the model becomes the active object, which means it can be selected by a mouse click.

Adding more 2d stuff and fixing 3d movement

We are now at a point where the 2d graphics side of things has reached a certain stableness. There are still parts of the original wme engine which are not implemented yet, but the main functionality is there, at least for Alpha Polaris (and the demos as well). Some screenshots:

This actually comes from an in-game video. Now the speech bubble in the lower left corner is not supposed to be there.
Rune’s not happy about being abruptly awakened. The debug messages in the upper left indicate that there is still enough work to do.
Looks like they found something. Unfortunately, shadows are still missing, so the scene doesn’t look quite right yet.
The laboratory. Rune looks almost floating, this will hopefully change once shadows are rendered.

What cannot be seen on the screenshots is movement of course. There were some more issues with it since the scripting code of Alpha Polaris is expecting a Direct3D coordinate system. So some conversions were needed. But now things seem to work as expected or at least nothing unexpected has happened. But then this is only the very beginning of the game.

One thing that worked straight out of the box was 2d object selection. On the other hand, 3d object selection together with attaching these objects to characters is still missing. Implementing this will be the next goal. After that, we will be able to have some fun with rifles and bears!

Getting coordinate systems right

So last Tuesday I thought that I had the .X file stuff basically finished, up to missing details at least. Unfortunately this was not correct. After getting everything to work in the Wintermute 3D demo, I decided to try out and see, what would happen in Alpha Polaris. Well, this was the first result:

The black something flying over the bed is supposed to be the main protagonist of the game. So this didn’t work out so well. Issues were negative texture coordinates together with clamping and a wrong mesh update function, which did not set all vertex position values to zero before calculating the new positions during an animation.

After fixing this, I realized, that my model was still using the Direct3D coordinate system, which caused it to appear mirrored. So this meant some more work figuring out how to correctly change the coordinate system to an OpenGL one and fixing some more bugs along the way. Lesson learned here: The coordinate system has definitively to be consistent.

Now things are looking much better. Pictures will follow over the weekend, there are still some other issues in Alpha Polaris, which have to be fixed.

Animating .X models

So, most of the necessary Wintermute 3D code is now imported. Also, the .X loader is almost finished, meaning in particular that the animation data is loaded in and applied. Here is the current state in a video (rightclick -> play should start the video):

So basic animations are essentially working (although there could be buggy edge case which so far did not appear). Also path-finding seems to work already. On the other hand there are still some glitches like the model being visible in the initial screen, the teapot disappearing when reentering the front part of the scene (although it will reappear again if you just go towards the back and then to the front again), letters two far away, etc. .. .

Trying some .X loading

Wintermute3D offers the possibility to load in and display 3d models from .X files. For this it relies on functionality offered by the D3DX helper library, which parses in the data into an intermediate data structure. Wme then puts the data from there into it’s own data structure, which actually closely resembles the .X file format, meaning that essentially for every non-trivial data type there is a class in the engine code. Now although these classes are portable, which is very convenient, the loader itself is missing and has to be implemented from scratch.

So the first thing I did at the beginning of this week was to import the usable code from Wme3D into ResidualVM. This took some time, but now almost all importing of necessary or potentially useful code is already done. After that I started to work on a parser for the .X file format. Originally the plan was to base the parser on the Assimp library, but after some more research on the format, I thought, that implementing a recursive descent parser from scratch might be just as good as an option. So that’s what I did. Now at the moment, several key parts are still missing, but the essential structure is there and I am able to load in some data in display in “some” way onto screen, like this:

In front of the first door, there is a 3d model of what is supposed to be Trinity from the movie Matrix. As one can see, it’s somewhat displaced in mid air. Also the scene geometry is messed up, as can be seen by comparing above image to the one from my last post. But hey, what can you hope for..

One thing that I have to change about the whole .X parsing stuff is the handling of commas and semicolons. By design, .X files like semicolons, everywhere, and the code shows this very explicitly at the moment.

During all of this work I also learned the hard, that the override keyword can be very useful (if you use it). Some of the classes, that I imported, where supposed to override certain virtual member functions. But the function signatures of the base classes had changed when they where imported into ScummVM and so nothing was overridden. And then I wondered, why the imported code wasn’t called. Another moral of this story could be though, that checking compiler warnings, at least sometimes and also keeping them minimal would be a good idea..