Hi!
Just to show you some progress I made concerning my new renderer: a light pre-pass renderer with relief-mapping over all surfaces! An important feature of this engine is that each texel in the virtual scene is unique. Indeed, no virtual texture mapping is used but simply large 4096*4096 textures! Because no virtual texturing is used, everything is resident in the GPU video memory. Texture for dynamically added objects in the VE are allocated in dynamic texture atlases (using a quad-tree to manage texture space use). As a result, when designing a map (under Maya with my exporter), you have to find a good trade-off between texel density in world space and the size of your map. For me, it is important to have unique texel everywhere to achieve this kind of effects I made before.
Yesterday, as visible on screen-shots, I have finished implementing Virtual Shadow Depth Cube map as described in ShaderX3. I may test later render to cube map using geometry shader.
Thank to this light pre-pass engine, I will be able to easily implement/test several rendering methods like soft particles, light propagation volume, SSAO, etc... The only thing I miss in this engine is spherical-harmonic- or Source-like lightmaps (I wish I had a Beast or Turtle license for this). Currently, it is a Quake3-like lightmap: no directional information about incoming light on surfaces.
With this engine I plan to develop a simple Quake3-like-death-match-with-bots game as a simple demo. If some artist read this post and are interested in designing a death match map, please send me an email. The only thing you would need is Maya2008.
Just to show you some progress I made concerning my new renderer: a light pre-pass renderer with relief-mapping over all surfaces! An important feature of this engine is that each texel in the virtual scene is unique. Indeed, no virtual texture mapping is used but simply large 4096*4096 textures! Because no virtual texturing is used, everything is resident in the GPU video memory. Texture for dynamically added objects in the VE are allocated in dynamic texture atlases (using a quad-tree to manage texture space use). As a result, when designing a map (under Maya with my exporter), you have to find a good trade-off between texel density in world space and the size of your map. For me, it is important to have unique texel everywhere to achieve this kind of effects I made before.
Yesterday, as visible on screen-shots, I have finished implementing Virtual Shadow Depth Cube map as described in ShaderX3. I may test later render to cube map using geometry shader.
Thank to this light pre-pass engine, I will be able to easily implement/test several rendering methods like soft particles, light propagation volume, SSAO, etc... The only thing I miss in this engine is spherical-harmonic- or Source-like lightmaps (I wish I had a Beast or Turtle license for this). Currently, it is a Quake3-like lightmap: no directional information about incoming light on surfaces.
With this engine I plan to develop a simple Quake3-like-death-match-with-bots game as a simple demo. If some artist read this post and are interested in designing a death match map, please send me an email. The only thing you would need is Maya2008.
Black lightmap, two shadowed point light sources
Black lightmap, two shadowed point light sources
Grey lightmap: directional indirect lighting using
spherical harmonic volume.
For this, I use the library I have developed.
spherical harmonic volume.
For this, I use the library I have developed.
In these screenshots, I only used a uniformly colored lightmap because I did not found time to generate one for this level. And also because I just finished adding point light sources support which will be used for direct illumination (lightmap will only contains emissive surface and global illumination). Next move is adding spot lights and optimizing shaders as well as the way meshes are processed by the engine.
Feel free to ask me some questions! :)
ça claque, ya pas à dire :)
ReplyDeleteYou rock, go on with your experiments. French PhDs FTW !!!
How would you handle water reflexion in Quake3 maps (or any 3d scene...) with a deferred renderer ? I stopped developing mine at that point, I didn't want to create a full G-Buffer for each mirror in the scene. Any idea?
Merci! :))
ReplyDeleteYes, reflexion is a bit tricky in this case... Hmm, Maybe you could first run your deferred pipeline as usual from the reflexion camera view point on the other side of the water surface or mirror. This could be done at a lower resolution than your back buffer by reducing the surface used in your GBuffer (by downsizing the viewport). Also, maybe it is possible to ignore shadows during this pass depending one your scene... The generated image from this viewpoint could be stored in a texture and then re-used in the final water pass with distortion based on water normals.
This is basically the first idea I get... You can also use a stencil mask to render reflected environment on water surface only but this way you can't get distorted reflection and you have to work at full resolution.
Wow, man you rock :)
ReplyDeleteactually I did something like you propose for reflections in my deferred renderer. It works pretty ok. Besides as I wrote in this article: http://www.gamedev.net/reference/programming/features/ppWaterRender/ water can be then done as a regular post-processing effect.
Thanks,
ReplyDeleteI think I'll make a really blurry reflexion then, on a dirty and muddy water pool :) Or work with a desert environment.
About your renderer, how well does it run, performance-wise ?
Yeah Riddlemaster, I've read your article, I really like the quality of your water and shores :) But we still have to run the whole renderer to compute the damned reflexion map :(
ReplyDeleteYes. But this cannot be skipped, unfortunately. You can also use some obvious optimizations like closer far plane, render only some of the objects (less than normally I mean), or with much simpler materials (some sort of shader LOD) etc. It depends on what quality you need :)
ReplyDeleteTotally agree! Post-processed water is a really nice advantage of deferred renderer over forward one (looks like it is also used in LeftForDead2).
ReplyDeleteConcerning the performance, I am currently running up to 130 fps on a GeForceQuadro3700M (1280*1024) but it depends on the number of light (shadowed or not), physical objects, and texture cache used (relief mapping is expenssive). I think it will be faster on my GF275 and slower with a lot of object and lights... I will compute accurate rendering time soon and post them here.