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

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting. Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective.

The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work.

I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography.

You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject...

..,or as part of a fully lit scene to add some subtle highlights. See how alive the subject look…

How to... build a strong art concept.

So you want to make some art assets for your game. The first on the list is a Steampunk Revolver for your main character to shoot up Cthulhu with. Quickly opening your internet browser you start with a Google image search. Ah, there is is!

It might be a good idea to find a few influences so you don't accidentally end up copying a famous design.

Just mash them up and you're ready to go! Off to your favorite modeling program.
But wait! isn't there more to building a strong design concept than that?

Of course there is.
One of the diseases of modern design is that of recursion. Everything is a copy of a copy of a copy. This is especially a problem with "historical" concepts. Over the course of that recursive process the concept becomes infected with modern design elements, and ends up looking very similar to everything else that anyone else has ever made.
If you want to come up with a really fresh idea, you have to get beyond secondary references and go look at real …


Ok, so it's not exactly skynet, but I have got my first AI state working, kind of.

The first state is "HOLD" in which case the agent stays in place where they are and shoots at any unit that comes in range. When I started writing this module, I found that the existing method of triggering actions wasn't good enough to allow the AI to choose the best weapon or target. It worked by simply sending a command to the unit to trigger the currently selected action.

If the action is valid, it triggered, if not it didn't.
That's fine for play controlled units, as that's all they need to do. But AI needs to know in advance if the action is valid. The player can get that info from UI feedback, but that wasn't available to the AI player.

There were three problems:

1. The UI feedback duplicated code in the action trigger function. These  two sets of code could get out of phase so that UI feedback was wrong.

2. The action trigger didn't give enough feedback for …