Jump to content

  • Log In with Google      Sign In   
  • Create Account


  • You cannot edit this iotd

Hammer engine - showcase 09/2012  by sepul    *****

 



Time Spent: 18 months
Date Added: Jun 09 2012 07:10 AM

Hammer engine is a lightweight 3d game engine, written in C language as my hobby project. with it's own editor and tools.
As soon as I clean the code and make some features more stable, it will be launched as LPGL'd open-source project. (although curious developers can e-mail me for early source code access).

Some of the features in the current build are :
  • Custom SIMD optimized for functions like culling, tiling, occlusion, etc.
  • DirectX11 renderer, capable of rendering for D3D10 and D3D10.1 hardware.
  • Deferred lighting (light prepass) optimized with tiles (deferred tiling) on CPU.
  • MSAA + FXAA anti-aliasing
  • Instanced rendering for all scene meshes.
  • Supports alpha and forward shading materials.
  • Normal maps, specular maps, ambient maps, emissive maps, reflection maps, ...
  • SSAO
  • Fully dynamic CSM (PSSM) outdoor shadows (killzone2 method)
  • Dynamic game entity component system with automatic serialization, scripting and editor integration
  • Physx 3.2 rigid body integration which contains it's own physics file format.
  • HDR lighting with filmic tonemapping
  • Current tools are: mesh-importer, shader-builder, texture-compression tool, remote console app and map-editor.
  • Scene management with unified grid spatial data structure
  • Common engine systems like file-system, shader-manager, resource-manager, thread-manager etc.
  • Animation for skinned and hierarchical meshes (blending not implemented yet)
  • 2D/3D debug drawing tools with unicode font support.
  • Basic OpenAL sound system with OGG and WAV file formats
  • Basic scripting support with AngelScript engine.
For more information, check out my dev-blog: http://www.hmrengine.com/blog
models are courtesy of dexsoft games (http://www.dexsoft-games.com/)  
Microsoft visual studio 2010 - SP1
Physx 3.2
OpenAL
Angelscript
ZLib


  • You cannot edit this iotd

Share:


15 Comments

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! :P
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 Posted Image. 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 Posted Image). 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 ...

PARTNERS