Ogre on Windows

[x3n]

I tried to use Code::Blocks (instead of eclipse) to compile Ogre from source and I succeeded, so there are at the moment no problems with ogre on windows. The picture above shows mesh to BSP shadows (stencil modulative). BSP to BSP shadows are most probably impossible. This allows us to have static lights and dynamic meshes (and therefore shadows) in BSP levels. But dynamic lights won't look right, because the BSP lightmaps are precompiled by GTK-Radiant.

Additionally I did some tests with GTK-Radiant and I discovered a way to get better lightmaps. It costs more time to compile and the bsp file gets bigger, but it looks better. I've already recompiled the spacestation levels from winter and I'll do so with the moonstation hangar too (yet unfinished).
Lightmap scale 0.125 means 8x8 lightmap pixels instead of 1x1. In the spacestation levels I've only used lightmap scale 0.250 (4x4) for the most important walls, the rest is still at 1.000 to save space and CPU time.

[beni]

Okay. If I get this right we can have BSP on BSP static shadows and dynamic model on BSP shadows, right? Only that dynamic shadow wouldn't look good because it's not shown on BSP.

So what would happen if we have a light in a room which flickers? Wouldn't it get dark when we turn off the light? Would we see the light outside of the room even when there are walls between us and the light? I think we could live without moving light, but flickering light would be cool.

Anyways: Great work so far. Ogre looks really good in my opinion. I hope it's as good as or at least close to Ogre on Linux. Let's see what Crystal Space is able to.

[x3n]

Okay. If I get this right we can have BSP on BSP static shadows and dynamic model on BSP shadows, right?

Right.

Only that dynamic shadow wouldn't look good because it's not shown on BSP.

Dynamic LIGHTS (for example a flashlight) wouldn't look good, because then the player expects dynamic BSP to BSP shadows (which seems to be impossible). Dynamic shadows (casted by a static light and a dynamic mesh) are no problem. But I think that's what you meant.

So what would happen if we have a light in a room which flickers? Wouldn't it get dark when we turn off the light?

No, I found no way to illuminate a BSP wall with dynamic lights so far (maybe there's a way), so a flickering light would only turn Mesh to BSP shadows on and off but not changing the brightness of a BSP wall. Lights have absolutely no effect on BSP models, only shadows have (I know, it sounds odd). But in case we would choose Ogre we could possibly write an extension that allows at least flickering lights. And maybe there's a way to make BSP models nonstatic, but I don't know if that's good for the performance.

Would we see the light outside of the room even when there are walls between us and the light?

I haven't tested that yet, but I think shadow volumes get culled. But I have no idea concerning the light outside the room. If we can illuminate BSP models and lights are blocked by walls, then we had in fact dynamic BSP to BSP shadows.

Let's see what Crystal Space is able to.

I wasn't able to find out if they actually support BSP models. That's why I tested Irrlicht and G3D too.

[beni]

What would happen when we would put transparent "shadow" meshes in every wall. Those meshes would cast a shadow on the BSP, right?
I guess then the performance will surely die.

[x3n]

Yes and yes

But that would be a good idea for some special parts of a map, but it's a lot of work too.

[x3n]

Ok, after some changes in the engine the flashlight works, but its still buggy, a hack, not really nice (it's vertex lighting) and doesn't cast BSP to BSP shadows. But it's a beginning.

[beni]

Looks a bit strange in my opinion. Somehow the walls are lit that much that they would have to reflect at least a bit of light and the shadow cannot be that dark. But I guess that's a matter of values you give your flashlight.

[patrick]

Every day I come here to be surprised and overwhelmed by your work guys. I'm looking forward to some spare time after my master thesis to join you. Until then I guess you will all be pros already

[x3n]

Looks a bit strange in my opinion. Somehow the walls are lit that much that they would have to reflect at least a bit of light and the shadow cannot be that dark. But I guess that's a matter of values you give your flashlight.

Yes, the "reflection factor" is 1 on this picture, it's only a test
The darkness of the shadow sould be variable too.

But there are several problems:
1) The illumination of the BSP model is vertex lighting, which means: bilinear approximation of the illumination between vertices. That's no problem when we have small and a constant size of triangles. But in a BSP model we often have big triangles on the floor and very small ones on a handrail or so. That makes the illumination look odd.
We need per pixel lighting.

2) Lights shine through BSP walls.

3) Even more serious: Shadows go through BSP walls.

I don't know if any of those problems is solvable.

[beni]

Well, now I can kinda understand how BSP is something they wanna drop in Ogre and is not even implemented in Crystal Space.
I hurts to say that, but somehow it's a lot of work to deal with BSP nowadays. It's just not good enough anymore. We have those cool levels, but if they cannot look good in the new engine, what are our options?

[x3n]

what are our options?

Blender (or other) meshes, put together to a map (as I mentioned some posts before).

But why do you say "they cannot look good in the new engine"? It looks exactly the same as in our old engine, but actual features like dynamic lights and shadows in Ogre aren't created for BSP but for meshes, that's why I can't just put "BSPModel->activateDynamicLighting()" into my code and it works

At the moment I'm looking into the BSP implementation and I start to get common with the code (it's not too big). I've already fixed the "The map is too bright" bug (now it looks exactly like orxonox) and I see how to extend the materials to allow special shaders, which is the condition to implement per pixel lighting or bumpmapping.

[Nowic]

I think the Crystal Space guys had (or have) exactly the same problems. Before 0.9x they had BSP support. But they couldn't add their advanced features to bsp maps, so they dropped the support for it completely (it looks like that to me). An other benefit is, that without bsp, they can use one fully integrated editor (in this case blender) to model, texture and compose the game content and levels. You can define all content of your game, like scripts, quests, shaders, lights, zones (portals in bsp), physics properties, animations, etc inside one editor. Blender offers you tools to generate organic shapes (like landscapes) as well as complex buildings. Bsp editors don't offer that.

It just sounds very nice from an artist's viewpoint, if it really works! I know that several people don't like Blender. But it's not a problem for people with no experience, like most of the PPS students. And there is a workaround: you could import the bsp geometry to blender, retexture it and assigne the engine features. And there are probably exporters for other 3D editors, too (Maya, 3DStudio...).

Blender2Crystal Demonstrations:
Info: http://b2cs.delcorp.org/index.php/General_Overview
Stream: http://video.google.com/videoplay?docid ... 2210656011
Higher resolution: http://www.blender.org/fileadmin/bconf0 ... p4.torrent

In my opinion, we should think about dropping bsp too, and use the level format of our future favorite engine. These formates are problably better extendable for our special needs too. And it will take some years until the current quake engine map format specification will be released as open source.

[x3n]

Yes, you're right, if we want a state-of-the-art game, we should drop BSP. But I might remember that we already have way too few designers. BSP maps are very easy to create, that's the biggest advantage nowadays. We wouldn't have 1 finished level after 2 semesters without BSP.

Of course we could drop BSP and I won't cry , but we must think of the factor "time" too.

I'm still experimenting with Ogre, but if I don't succeed, we could look into the code of nexuiz, they do have shadows

http://alientrap.org/nexuiz/public/new/14.jpg

[beni]

well. when it's easier (or faster) to work with the BSP editor, then we shouldn't stop working with it. If the conversion from BSP in Blender is easy enough, then this would be a good solution. But the question is of course, what makes it so much faster and can we keep those advantages.

[x3n]

I've read the same question in the Ogre forum and the answer was:
Modern graphics cards are optimized to work with large amounts of data. But BSP is from a time, when it was faster to have many small pieces and that's exactly what the BSP compiler does: Splitting up the model into small parts.

The newest version of GTK Radiant has an "Export as Wavefront object" option. Converting a whole map into one object won't work, but maybe it works with small pieces, but then we have to do the "which parts are visible from each position" code on our own.
But first we should try other options like shaders on BSP textures to allow per pixel lighting. I tried it yesterday but I had no success, it's hard to work with a totally new engine with totally new features (shaders, materials, textures, images, passes, ...).

Another option is to convert the BSP-Tree into an Octree, maybe that's faster with modern graphics cards. Ogre has Octree support, but I don't know if such a conversion is good for the performance.