Skip to main content

Per-vertex graphics mode VS Per-pixel.

Going back and making some tweaks to the lighting set up I found I can get a similar result from the classic graphics mode as I can from the more modern style.

Per vertex lighting.
Can you tell the two modes apart? I can, there is definitely a better quality to the per-pixel lighting, nicer shading, better shading of unlit portions of models, better handling of normals etc... but not enough of an improvement to justify the switch maybe.

Per pixel lighting.
Per pixel lighting does have some other benefits, such as better materials handling (I can dynamically mix two texture on a single object using a mask) which can give a much better appearance to tilesets. It can also do dynamic shadows, reflective surfaces, normal maps and a whole raft of other stuff. But... I don't intend to use any of those features right now. The game is supposed to run on low end computers, I've chosen to use very low detailed art assets to help with that. Putting a normal map on a very low poly character just doesn't work. Things like reflective surfaces look great up close, but are pretty much unnoticeable at the scale of view I'm using.

So what else could per pixel lighting offer?

Per-pixel lighting.
Well for one thing per pixel lighting handles color much better. Colored lights look much more natural.

It also allows for lights to be positioned much nearer to the characters and cast light as if they are really holding a torch, instead of as if god were shining a torch down from above.

Per vertex lighting.
There's also the fact that per-vertex lighting has been discontinued in the newest version of Blender. It's no longer an option if I choose to use the most modern  features of the engine.

As I already said these features already include threaded animations (to increase speed) and in future could include other things which might be useful. What do you think? Would it be better to use per-pixel lighting knowing that it limits my audience, or keep using per vertex lighting and miss out on more modern improvements to the game engine?


  1. pixel all the way :)
    But... I think you might be missing a trick or two here.
    You say you have 8 lights. ok
    lets use the second image as it has tiles on the floor. so we can also talk in terms of tiles :)
    light 1 will be you character light - put this slightly above your main character. it light up 6 tiles, so a 6 tile area around your character will be lit, there will be fall off so lets give that another 3 tiles
    if the light is dimming refuse the light power until just the 3 tiles are lit. moving between them give a flickering look.
    Everything else is black

    now, you have 7 lights left - work in rooms. a room is the large area the character is in - or a corridor. so give is a fill light (2), this is just a lower level light but one that is more powerful? you might need 3 light here (2,3,4)
    which leaves 4 lights to play with - use these as bright lights that affect small areas with different colours as well.

    You'll need to write a light handler though

    1. Thanks for reading. I'm leaning more and more towards the pixel based lighting, in part because it gives much nicer results at low light levels, but also because I'm really liking the improvements to speed caused by threaded animations.

      I actually already have a light handler, I didn't explain it very well though.

      I have one light parented to the camera pointing towards the focus of the camera's view, this is low intensity and serves to provide a little light when no character is holding a torch.

      I also have 6 dynamic lights which can be warped to the same position as any light emitting objects in the scene. First I create a list of all active light sources in the game scene and then sort them in order of distance from the camera. Then I place one of my 6 lights to represent that light source. If there should be more that 6 light sources on screen at the same time, they will be ignored (but the visible area will already be really bright so you wouldn't notice). If there are less than 6 light sources then the remaining lights are set to 0.0 energy and are left out of lighting calculations.

      When placing a light I can set it's energy, and fade distance, as well as color. Each light source (a static lamp or a character holding a light emitting object has data about its energy, distance and color, so it's possible to control the lighting in the scene quite subtly without using more than 7 lights. I can also animate the lights so they flicker or pulse.
      The one remaining light I'm keeping back for now, but may be used for environmental effects such as upward cast light from lava or glowing slime in concert with controlling the main scene light.


Post a Comment

Popular posts from this blog

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.

Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.


I finished working on the code for adding foliage and having some extra time I decided to experiment with the code for rockets.

The original idea I had was that rockets would be large vehicle components that can be fired very quickly, regardless of how much manpower is used for reloading.

They would use up a lot of ammo, so they would run dry after a short but devastating barrage.
The problem here is that it's easy to take advantage of this by adding a lot of ammo, which is much smaller than in bulk than the rockets.

There's also the problem of firing large caliber rockets. In real life rockets of up to 30cm were used, but I think that will be too powerful for the scale of combat in this game.

lol. Somehow that one trooper survived the mother of all explosions...

A 30cm rocket could contain nearly 30KG of explosive. That would be a very large explosion.

I've tried to balance the game by using a simple equation to make bigger guns more powerful, but hopefully not too powerf…

Infantry combat and entering buildings.

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.

Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…