FreeGameDev

For the last few weeks, I have been working on and off to switch from the custom graphics engine to Ogre. Since it has advanced enough for the game to be sort of playable, and everyone is distracted by the bearded man, showcasing the ugly details should be most opportune.

The code is in the "ogre" branch in the Git repository for now. It'll be merged to master when it doesn't crash quite as much as now, but it's still a bit too early for that. Although it works alright most of the time, there are occasional scary things like bugged vertices in meshes and Ogre aborting mysteriously when rendering stuff. Some of the bugs could be rather nasty, but let's hope that I'll be able to figure them out without too much pain.

Feature wise, the new engine isn't far from the old one. The user interface, model, material, shader and particle systems are roughly as capable, though some script changes are required before everything can be rendered. Animations work in principle, but the deformations are quite awful without dual quaternions. There's also an incomplete implementation of shadow casting, which the old engine didn't have.

I'll be posting updates here whenever I get something noteworthy done. If someone wants to exchange tips, give pointers to useful source code snippets, or badmouth Ogre, feel at home here.

Ahh, I always wondered why LoS used a custom engine. It's probably a good move to switch to Ogre... and I am somewhat surprised that it was even possible to far into development.

I liked the custom engine because learning how graphics algorithms work is interesting. However, since my spare time is more limited these days, I have to cut corners somewhere if I want to get things done in a non-sluggish fashion. Since I'd rather drop the graphics engine part than the game part, this is the outcome.

The main reason why it's possible to replace the graphics engine without significant problems is that LoS is ridiculously modular. The graphics engine has a relatively small API with no structures exposed so you can hack the internals rather freely without other modules minding it. I could basically just remove the internals, test that the game still works with the dummy module, and then plug Ogre to the API in small increments.

Gwee!

How does the performance look? Oh yeah, you have a supercomputer... Lemme check it out on my old lappy.. Compilation guide?

Something along these lines would probably work:

{l Code}: {l Select All Code}

sodo apt-add-repository ppa:ogre-team/ogre
sudo apt-get install libogre-dev libois-dev
git checkout -b ogre remotes/origin/ogre
./waf configure build install

KroArtem tested it too, and it apparently runs, sort of. Materials badly need fallback techniques for older cards, though. For now, there are only techniques for shaders that work on my system, but less expensive shader technique and fixed function techniques are needed too. Also, options for disabling shadow mapping or reducing the shadow map resolution should be added.

Ok, works on my system with only the lips ppa selected, but really slow on my Geforce 6600 Go, but it runs! Voxel textures are broken, character models are broken, but the bookcase is textured for some reason, and the torch particles work.

The same for me here, I have intel integrated graphics though

I have fixed one of the big crasher bugs, but another known one is still around. It appears to be an ugly memory corruption issue so it might take some time to isolate. I also fixed some memory leaks, but it feels like there are still more huge leaks left. I have yet to fully grasp how Ogre's memory management is supposed to be used with streaming content.

Alongside hunting bugs, I have been restoring old features and adding some new things. I added fixed function fallbacks for materials so they should work better on older cards. Eye colorization works again, and it doesn't even look creepy without shaders. I also used Ogre's compositors to reimplement bloom, and added a skybox since it turned out to be a matter of one function call with Ogre.

Wow, this is awesome progress! I can't overstate how impressed I am with your progress.

You've inspired me, I'm going to work on some new models, textures and animations for LoS when I get back from holidays in a week.

Good luck squashing bugs!

Wow, that would be awesome Poss!

glad to see lips back in development! Was it hard to concentrate on school while thinking of what to do with LoS?

I think that I got the second crasher bug fixed. I have been testing a lot while working on other features and haven't experienced any crashes. It looks rather promising so merging the ogre branch should be feasible when the worst breakages in data files and shaders have been fixed.

I have been working on integrating heightmap support to the engine. Both collision and basic rendering work already, but there's no scripting interface for setting the height data yet. Ogre could also render multiple texture layers with fancy transitions, but I haven't tested with more than one layer yet.

It remains to be seen how we're going to use heightmaps in practice. I'd expect that simply settling for a static, hand-painted heightmap would be good enough. However, there are other options too, and the best one ultimately depends on what we want from the map. I'll probably make another thread where we can discuss the map format once I have thought through it in more detail.

p0ss {l Wrote}:You've inspired me, I'm going to work on some new models, textures and animations for LoS when I get back from holidays in a week.

This would be great indeed. We're lacking a lot of graphics so even small contributions would help a lot with making the game look less goofy.

freelikegnu {l Wrote}:Was it hard to concentrate on school while thinking of what to do with LoS?

I guess I did quite well. However, it'd rather not put LoS aside again for such a long time. Being without such a fun hobby makes me feel like a vegetable.

I poked heightmaps some more. Height data can now be loaded from image files, and multiple texture layers work too. I think that it'd be reasonably usable now if there were better textures and height data.

I also fixed some of the issues with shaders and models, but some more still remain. Furthermore, there seems to be yet another serious crasher bug left (apparently in the GUI drawing code) that needs to be fixed.

How does the transition between the "diggable" underground and the hightmap surface work?

But it sounds like you are making great progress!

Julius {l Wrote}:How does the transition between the "diggable" underground and the hightmap surface work?

There's no transition really because the heightmap is a separate entity. Voxel terrain can coexist with it, but it'll appear as separate blocks above it. The heightmap isn't destructible either, and it's no possible to puncture holes through it. The player probably needs to be sent underground with alternative means, such as traditional caves that teleport you there.

Models by p0ss split into a new topic.

The ogre branch has been merged to master. The ogre branch is now deprecated and development will continue in master from now on. There are still some bugs and content issues left but nothing so major that it'd hinder development much. It shouldn't take long until the old features have been restored and the original stability level is reached.

In a loosely related note, I have done major changes to the data directory structure. Instead of files being grouped by their type, they're now grouped into directories based on what object/quest/region uses them. For example, the "musket" directory contains all the specs, the texture and model, and the firing sound of muskets. The primary reason for the change is that it's a pain to know/remember what things we have and how to improve them when the files of interest are spread all over the place. Another reason is that it makes debugging easier when you can disable content by just commenting out directories in one file. It'll help me fix bugs since I can rule out concerns more easily.

Hrm, I liked the old structure This is where tags would be useful, a better filesystem or something like that :P

Congrats for the porting ! Regarding the heightmap, on my side I had a fork of Lips' code last year, which supported this feature directly with the voxels, but it was poorly working and the Ogre system is much more flexible IMHO.

Hey garvek, nice to see you on the forums. The code might still come in handy though, as we need to "fill" the mesh heightmap somehow for when people are underground

Can you tell at what level of integration of the engine Ogre made ​​in this project?

I see, the Ogre is used in the render-internal, but, on Windows I can't configure LoS to use DirectX render system...

Nikitron {l Wrote}:Can you tell at what level of integration of the engine Ogre made ​​in this project?

I see, the Ogre is used in the render-internal, but, on Windows I can't configure LoS to use DirectX render system...

All our shaders and custom extensions to Ogre work with OpenGL only. Hence, no initialization route for DirectX exists at all. There are currently no plans to support DirectX.