Normal mapping

[oln]

This is still something that not works.
I have tried to play with the materials, but i haven't managed to make it work. I managed to make a material script (claimed) use the bumpmapping programs i think, but the tile just shows up really bright in the game.
Both the wiki page and the example does have code that generates tangent vectors though, maybe this is needed for it to look right. I don't know where in the code this should be done though.

[svenskmand]

Ok I have some questions about this:

1) Do you have a working example with normal maps somewhere on the net?

2) Have you checked if you need to enable normal maps in the render option window of Ogre3D for it to work?

3) Do you need to tell each individual light if it should make shadows on an texture with a normal map?

[andrewbuck]

If you want to try adding the tangent vector stuff it would probaly go in src/ExampleFrameListener.cpp take a look at the RenderRequest::createTile: case statement which is where the actual Ogre code to put the thing onscreen is.

-Buck

[svenskmand]

Bump on my questions? Are they stupid?

[oln]

1. There is an example in the SDK
2. Don't think there is one?
3. Don't think that's needed.

[svenskmand]

Ok

[oln]

Tried doing the vector generation stuff, but the tiles still doesn't receive any light from anywhere, and are really bright.

[oln]

It seems that it actually works after testing a bit, but something is causing all the tiles to be fully light up, so the effect isn't visible.

[andrewbuck]

The normal mapping has to be done on a per light basis so your .material file should have two pass sections, once with a "perlight" clause and the other is just a normal one without. It might be that in one or both of these you have something like ambient set to 1.0 across the board.

-Buck

[Skorpio]

If you want to test normal mapping on a creature then use the tentacle. I think it's the only creature with unmirrored uv-coordinates. You can find the normal map in the source folder.

[oln]

That could be why the normal mapping wasn't behaving properly.

[andrewbuck]

Note that you can also change the scale of the tentacle if you are going to test normal mapping on it. The scale is set in the level file under the CreatureClasses section. Scaling it up 5 or 10 times would make the texturing much easier to see for purposes of testing.

-Buck

[oln]

I now got this working somewhat, using http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Normal%20AO%20Specular%20Mapping%20Shader.
It's turned on on the troll, forge and claimed tiles.
Pushed to git and svn. I also moved the material scripts to "scripts"
Using this makes the models very bright compared to other models, not sure what's causing this.
Haven't made all models use the same shader yet, and some models have mirrored uv maps, which has to be unwrapped.
Also noticed that the material that the forge uses is called "Material", which needs to be fixed (I don't know how to do this).
EDIT: There is also a texture missing (pine_green.png for the wood on the bed)

[svenskmand]

Awesome , now we just need to bug fix it and then the 0.4.8 release will be incredible

[oln]

Hm, this did have a rather major effect on performance. The shader might need some optimising, I don't know how optimised it is. Should prob look at how to turn the mapping on or off dynamically.

[StefanP.MUC]

The whole normal mapping/colorize problem started before I really joined the team. Can someone quickly sum up what/where the problem is?

Oh, and yes, performance went down from ~40 to ~20 fps for me (fullscreen, 1280x800, FSAAx2, vsync on, FBO). Could this also have to do with the not-so-well things about graphical optimization p0ss mentioned?

[oln]

The artists have wanted normal mapping in the game for a long time, but we haven't really gotten it working. The team colouring was done by using the emissive component of the material, which made things look a bit odd, and would have to be implemented in the shader (would be quite simple I think) if we want it done this way still. (The shader currently doesn't utilise the emissive component I think, as it not used much.)

Regarding the performance, I was also thinking about the stuff p0ss talked about (even though his points about texture size were a bit off.)
The graphics seem to have become a bit of a bottleneck now, so it's probably the right place to look for optimisation possibilities.

[StefanP.MUC]

I just made some very basic tests about the performance. The major fps decrease seems to come from the ~40-50 loight sources after starting a game with the test level, in combination with the normal mapping.

I turned shadow quality 3 (highest) on for testing and the single creatures have loads shoadows of all intensity in all direction (generated and added by the many light sources).

I then turned of shadows again and commented out the createMapLight renderrequest (-> only mouse and ambient light left). My fps almost reached their original value of 35-40 fps.

I don't know if ALL these light sources are needed (or what they are for in the first place) and if some are maybe just to bright or placed to high (shining over walls and generating unneccessary GPU load), but this is definitly a point where optimizations could (and should) be done.

[oln]

Yes, a large number of lights does indeed affect performance. Most of them are probably not needed in the future. Not sure quite how lighting is meant to be done, if certain buildings should provide light, or something else. (How was this done in DK?) The claim effects are also a light in addition to the green dust stuff, not sure if we need them to be emitting light as well. (Some of this could be changeable by tweaking settings at some point.)
Might also check that the range parameter for attenuation of the lights is set to a sensible value. I changed it from 50 to 20 in the level file, and it seemed to help a bit, without noticing any artefacts.

I wouldn't focus too much on optimising at this point though, besides major things like this. Maybe we should disable some of the bling untill we get a config system in place.

[StefanP.MUC]

On the ogre website there is a page about optimization.
http://www.ogre3d.org/tikiwiki/Optimisation+checklist
It doesn't go much into detail, but it has some general points that could help us, maybe.

[Zlodo]

If there are lots of lights with rather localized effects, deferred shading would be a good way to improve performances: http://www.ogre3d.org/tikiwiki/Deferred+Shading

It's used by a lot of games nowadays, notably starcraft II for the very reason that they need to have lots of small light sources everywhere and a lot of models potentially affected by them.

Also, maybe not every light source need to cast a shadow, because that can be very expensive.

Lastly, perhaps evaluate what art really need to use actual light sources rather than just an emissive texture (a texture whose pixels are used as the "emissive" component of the material) or even emissive vertex colors (same thing but with colors painted in vertices, this was a very popular way to fake acceptable lighting on very primitive hardware such as the first playstation).

[oln]

Yeah, that is probably not a bad idea.
Another problem is the geometry. Normally one would use the terrain renderer, or ogre's static geometry for the terrain parts of the scene. But since it changes quite often, that's not possible to do in a simple way, so it is rendered as individual meshes. This probably also has an impact on the rendering performance.

[MyEmail]

You can get a really nice lighting system up without ever having to touch differed shading. Just bloom+precalculated lighting makes some nice scenes (take a look at Sauerbraten). Its screaming-fast and easy to implement.

[Skorpio]

I just noticed something interesting: The normal maps only seem to work on one troll model, even on the second troll model in the scene the normal map has no effect. I'm not sure about the spec maps. They seem to work on the forge and some ground tiles, but not on the troll.