Best lighting technique?

What do you mean by "lighting technique"? Are you talking about BRDFs? Photorealistic or non-photorealistic shading? Deferred rendering, forward rendering, light pre-pass rendering, inferred rendering, etc. ?

Lighting pipelines can get quite complex, and they really depend on the artistic goals for your game project. Maybe try to define your needs somewhat more specific than "good looking, no weird quirks, good performance"

When it comes to lighting these are some questions you could ask yourself for example:

- Is the rendering of loads of lights at once a priority?
- Do I want to have a large flexibility when it comes to materials? Do I want to support multiple BRDFs so I can render eg. anisotropic materials?
- Do I want photorealistic rendering?
- Are more advanced effects like translucency and subsurface scattering important to the game?
- Do I want support for High Dynamic Range (HDR) lighting?
- etc.

There are more things to consider of course, but these will already give you some insight in what you need in a lighting pipeline

We want to have multiple BRDFs and we will definetly have lots of light sources because we are randomly generating a city so there will be lamp posts and stuff like that. We are going to be using cascaded shadow maps for shadows, SSAO will be there for sure. We would like to have translucent objects, and subsurface scattering but its not really a priority.

Photorealistic is what we eventually want to achieve. However, we are not sure how to approach it. We have read some articles on different global illumination models but we are not sure if any are suitable for dynamic objects and lights.

So hopefully somebody could point us in the right direction with this?

If you want good "lighting", you need these 3 things:

1. Physically-based materials and lighting models. Read through the SIGGRAPH material presented by Naty Hoffman, and when you're done read it again.
   
2. Global illumination. It doesn't have to be dynamic or real time, but you need it.
   
3. A solid HDR pipeline. Read up on radiometry, photometry, photography. Then implement a good tone mapper, and a good auto-exposure routine. Then implement a asset pipeline that properly handles sRGB textures and linear HDR textures.
   

These things are all really hard to get right. It can easily take years, especially if there's only two of you. GI in particular can be really challenging, and it's easy to think you've got it right when really you're still doing it wrong. And of course even if you do these things right, you're still not going to hit "photorealistic" without the right assets. And you're not going to get good performance without a million optimizations and hardware tricks.

If you're making a game, why not spend your resources getting great artists and just use UDK/CryEngine/etc?

Don't underestimate the importance of your art quality. IMHO that's the deciding factor for 'visual quality' in hobby games.

Make some art assets at your target quality and plug it into any offline renderer (maxwell, mental ray, etc). That's roughly as good as it can possibly look. If it still looks bad (happens to me every time)... well

If you want good "lighting", you need these 3 things:
Physically-based materials and lighting models. Read through the SIGGRAPH material presented by Naty Hoffman, and when you're done read it again.
Global illumination. It doesn't have to be dynamic or real time, but you need it.
A solid HDR pipeline. Read up on radiometry, photometry, photography. Then implement a good tone mapper, and a good auto-exposure routine. Then implement a asset pipeline that properly handles sRGB textures and linear HDR textures.

Not to mention the trade off between either rendering many lights at once efficiently and allowing many of these physically accurate BRDFs, since methods like deferred rendering don't play nicely with lots of different material types. Although light pre-pass rendering makes this less of a problem, but at the cost of having to render your geometry twice

With GI I'd always advise going for a dynamic solution, since baked GI or PRT will always require additional pre-processing (IMO something you'll want to avoid) and will break immersion quite soon in more dynamic scenes in my experience. And since current techniques allow for decent real-time dynamic GI implementations (like Crytek's diffuse indirect illumination through LPVs for example) this becomes a viable option.

We know it will take less time, look better, and perform better using tools like UDK, CryEngine, Unity, etc. We are mainly doing this to learn, using those tools we can't learn very much. This will be more a hobby project as of now, but may change in the future.

We have been throwing ideas at each other for this game since February. We have a name, and many aspects of the game decided upon already, really the major thing left is what types of lighting we will use in the game. We believe light either makes or breaks the look of a game. We want to do things right, which is why we came here.

[background=rgb(250, 251, 252)]Please no [/background]more answers about trying to get us to use a pre-built engine.

We have someone working on some models for us, so we should be good on those for now.

Also Radikalizm i would like to go with a dynamic solution also, i don't want to spend hours pre-processing lighting for a scene.

Not to mention the trade off between either rendering many lights at once efficiently and allowing many of these physically accurate BRDFs, since methods like deferred rendering don't play nicely with lots of different material types. Although light pre-pass rendering makes this less of a problem, but at the cost of having to render your geometry twice

Light pre-pass really doesn't give you anything at all in the way of material variety, at least if you're going with physically-based lighting approaches. All of the interesting variety comes from things that you need as input to the lighting pass, so the whole "minimal G-Buffer" thing doesn't really pan out.

With GI I'd always advise going for a dynamic solution, since baked GI or PRT will always require additional pre-processing (IMO something you'll want to avoid) and will break immersion quite soon in more dynamic scenes in my experience. And since current techniques allow for decent real-time dynamic GI implementations (like Crytek's diffuse indirect illumination through LPVs for example) this becomes a viable option.

This discussion is wayyyyyy premature judging by the experience level of the OP. He needs to learn to walk before he tries to run.

This discussion is wayyyyyy premature judging by the experience level of the OP. He needs to learn to walk before he tries to run.

I will be learning more as i go, so yeah. The other guy knows more than i do, but he didn't want to make the thread though.

This thing will be very long term the game is more our final goal, we are planning it out and are going to learn how to do things along the way.

We don't really care how long it takes, but we are going to do it. We probably wont actually get into making the game for 3 or 4 years from now until then we will probably be working on engine stuff slowly.

But this topic isn't about that, we want to know what fits our wants for lighting the best. We will look into it and learn how to do it.

I am making a fully from-scratch engine as well and can understand from where you are coming (links in signature), although I am considering turning it into a middleware company rather than just as a learning experience, but it certainly is a learning experience.

At work, I work on this engine:

That video was recorded in real-time on PlayStation 3.

If you would like to get that type of (physically based) lighting into your own project, you can find many resources on our research page: http://research.tri-ace.com/
Specifically, this PPT explains various models our engine supports (which is used is up to the artists) and shows screenshots of each.

There should be plenty of reading material there for anyone who wants to get a lighting model like in the video. It is efficient enough to run on Xbox 360 and PlayStation 3, and should be plenty efficient enough for modern hardware.


L. Spiro

Light pre-pass really doesn't give you anything at all in the way of material variety, at least if you're going with physically-based lighting approaches. All of the interesting variety comes from things that you need as input to the lighting pass, so the whole "minimal G-Buffer" thing doesn't really pan out.

Yes you're right, my choice of words wasn't all that great. Light pre-pass doesn't solve the material problem, but will give you somewhat more flexibility, but as you said it won't give you the flexibility you require when it comes to input.

And about OP's experience level, since he seems to be quite keen on building this advanced engine I assume he'll have to deal with quite advanced techniques from the start, so why not inform him about the available options. Whether he'll be able to actually pull it off (the GI technique, or the engine in itself) is another matter, and will be something he'll have to deal with himself.

@L. Spiro:
Thanks for the great links, I'll be having a more in-depth look at these later today (my engine's lighting pipeline could always be a bit better)

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]L. Spiro we will certainly be looking at that.[/background]

[/font]

What are the other available options, that we should consider looking into?