Hammer engine - showcase 09/2012  by sepul   

Very very impressive! Does it have or do you plan to include simple networking support?

@GameCreator: thanks, no I don't have any plans to include networking yet, unless the source goes public and someone decides to do that

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.

@Frenetic: there is no reason ?! light prepass may not be the best method for next-gen (dx11+ hardware), but still pretty good for current gen and low/mid-range hardware. especially if you want MSAA too.

About materials, actually you can put all kinds of properties and textures into materials without any fat g-buffers, as for BRDFs I may need couple of them like skin and isotropic which are all applicable for light-prepass.

I'm not making a commercial cutting edge, big epic style engine that can handle huge environments and effects. maybe in the future I implement CS deferred, but not now.

Very impressive!

Nice job sepehr. Keep going

@ Frenetic Pony: Actually Light Pre-pass have no limitation for materials, unlike full deferred.

Wow. I applaud your efforts. Keep up the good work Sir. Nice!

Hi segul,
I'm one of the curious developers who would like to have a look at the source code of your creation . Mailed you last weekend but no response up till now. I'm imagining that you're very busy working on improving your creation.

Any chance that you want to share source code on short notice? Or a demo so we can see with our own eyes (and you get some performance feedback ). It looks very impressive already and I think a lot of people could benefit from it. It stands out from the croud w.r.t. a lot of other renderers.

Thx!

Hi segul,
I'm one of the curious developers who would like to have a look at the source code of your creation . Mailed you last weekend but no response up till now. I'm imagining that you're very busy working on improving your creation.

Any chance that you want to share source code on short notice? Or a demo so we can see with our own eyes (and you get some performance feedback ). It looks very impressive already and I think a lot of people could benefit from it. It stands out from the croud w.r.t. a lot of other renderers.

Thx!

+1 !

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.

Looks great !

@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.

@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 ...