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?

Comments

  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

    ReplyDelete
    Replies
    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.

      Delete

Post a Comment

Popular posts from this blog

Advice needed on tilesets...

I need some advice on which is the best way to handle building the dungeon. Right now I'm using prefabs for my dungeon, they have a north south east and west section for each "room": The basic tileset. This has several advantages, and also several disadvantages. Firstly I can have curved rooms, I can have tunnels and other interesting shapes. The tilesets can look quite nice with a little work. On the other hand I can't easily get the navigation data before building the map and once the map has been built I can't make changes to the layout, like having active pit traps or believable secret doors. Although the rooms are interesting, they are quite repetitive, and it takes a lot of effort to make even a few different variations. Also rooms are constrained to one size. A newer version of the tileset with a lot of variant parts for making more interesting rooms. To create a tile set is a real headache too. Planning how to lay out the UVs, trying to cra...

Upstairs / Downstairs.

I've decided to make my prefabs multilevel. Later this should allow me to add pit traps and other great stuff. It also makes it easier to line up stairs so that you can exit them on the same co-ordinates where you entered them. The prefab editor is pretty much finished, it just needs some code for loading up prefabs from a saved dictionary, so that they can be checked or edited. The entries will need to be forwards compatible, so I'll be loading each tile and then translating the indexes to a new array, that way if I add extra indexes or extra info (like traps or puzzles) I'll be able to update existing prefabs to work with the new standard. Click for a video.

Video Diary 8

Things are moving along well, there's been a lot of progress on the action manager side of things. Actions have finally moved to the UI, so you can initiate actions by clicking the appropriate button. I've set up some dummy actions to show what happens visually when actions are taken, but the actual dice rolls and such are yet to be integrated. The UI objects are also being added, though some are non functional or empty at the moment. Click on the image to see this week's development video. Every time I add something big I also add about a dozen small things. Like the selection box visualization. Previously this was using render.drawline, and old fashioned Blender function which can be impossible to see at certain resolutions, or at certain frequencies. I replaced it with a function that adds planes of the right size and scale in the right location. I also made all characters a little bigger. I still need to do some work with vectors and final target locations t...