Err, there's really no reason to be doing Light Pre-pass anymore unless you're targeting, I don't know, mobile devices with tiny amounts of bandwidth. But once your memory bandwidth is freed up there's no reason not to do deferred shading, your just bottleknecking yourself in geometry and limiting yourself in materials.
Quoting for truth. It's a win if you're stuck doing 'dumb' deferred shading, but you can get huuuuge bandwidth savings for a deferred renderer by going over to a tile-based approach (and you don't even need to make a fancy compute shader to do so!) instead of light volumes. The advantages were questionable even when the technique first came out AFAIK; I'm not sure why so many people latched onto it.
Nice job sepehr. Keep going
@ Frenetic Pony: Actually Light Pre-pass have no limitation for materials, unlike full deferred.
I don't really follow, here. If you want to have multiple BRDFs you're still stuck with some sort of an index. You can do some futzing around with the accumulated light, but there are better ways to do that that don't involve rendering all your meshes twice.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
@InvalidPointer: thanks for the input, I'll implement a deferred + tiled (cpu) and compare the results in a bigger scene. fortunately it doesn't take much effort to implement a deferred renderer in this engine and compare.
@Guest: sorry but it's been couple of days that I've been busy, I don't know your username on bitbucket, and the problem is bitbucket only allows for 5 developers to have access to private code, and they are full now, I'll remove one of them and give access to u.
thanks again for other users who liked this stuff, I'm currently working in my spare time to make the code public and also make more decent demos.
@InvalidPointer: thanks for the input, I'll implement a deferred + tiled (cpu) and compare the results in a bigger scene. fortunately it doesn't take much effort to implement a deferred renderer in this engine and compare.
@Guest: sorry but it's been couple of days that I've been busy, I don't know your username on bitbucket, and the problem is bitbucket only allows for 5 developers to have access to private code, and they are full now, I'll remove one of them and give access to u.
thanks again for other users who liked this stuff, I'm currently working in my spare time to make the code public and also make more decent demos.
Yeah, looking at your scene here I'm going to guess you're just rendering out diffuse/spec factors and multiplying. You're still using the same amount of fillrate, but you don't need to make two render passes to get that information. Worst-case, you're GPU-limited and it's going to be about the same perf-wise. Best-case, you're removing a significant amount of CPU work.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.
@Guest: sorry but it's been couple of days that I've been busy, I don't know your username on bitbucket, and the problem is bitbucket only allows for 5 developers to have access to private code, and they are full now, I'll remove one of them and give access to u.
I've sent yu my bitbucket account name using a GDnet message. Thanks already!
a new project derived from 'hmrengine' is now launched on http://www.hmrengine.com/blog
which is open-source and multiplatform, written in C language
check it out ...
