Jump to content

  • Log In with Google      Sign In   
  • Create Account

Ep's tool-dev diary


Renderer bells & whistles ~ pt. 2

Posted by , 20 October 2016 - * * * * * · 580 views



Finally some dynamic indirect lighting in the renderer!



(this uses a single ambient light source (an environment map) only)


It's fairly lo-res, but it's good for things like "walking through a dark cave" or "a giant spaceship hanging overhead".


On the cpu side, I look for a diffuse occlusion term by 'ray tracing' (they're pre-rasterized bit masks I fetch from a LUT) a simplified sphere-representation of the scene into a tetrahedral grid of cube maps / bit fields.


During rendering, I then construct the occlusion term, for a specific vertex, based on its position and orientation in the grid and use it to interpolate between an indirect term grabbed in screen space and whatever light comes directly from the ambient light source itself.


Posted Image

Translucency maps

Posted by , 15 April 2016 - - - - - - · 744 views
baked, translucency



A while ago I fiddled a bit with an offline translucency technique as discussed here: http://www.gamedev.net/topic/653094-baking-a-local-thickness-map/. Never officially made it part of the baking pipeline, even though it should only be a small extension - still just flip and ray test those normals.


Though instead of averaging all sampled ray distances, I split them up into small 4x4 8-bits precision sets, so as to break the uniform thickness up into several view dependent values. These grids snug nicely into a uint32[4] vertex map component and can be sampled in a vertex shader based on the camera-to-vertex view tangent.



Posted Image



Posted Image

Renderer bells and whistles

Posted by , 31 March 2016 - - - - - - · 588 views
Super, Mario, World

Hello again,


Updated my lightmapper to bake full indirect diffuse as opposed to only an ambient occlusion term. It now also captures a viewpoint dependent occlusion mask that lets the environment cast a silhouette onto any reflective surfaces:


Posted Image



Also added a 'bias & gain' option to the multitexturing interface that lets you shift the gradient ramp and contrast of vertex map masks. This makes them usable as e.g. damage/wear maps, even with their lo-res nature:


Posted Image


Bokeh to the Future

Posted by , 17 March 2016 - - - - - - · 592 views



Wasted an entire week trying to salvage this plan I had for a new depth of field shader. To up the performance, I came up with this really awkward mipmapping scheme, because for some reason I was convinced the weighted blending filter needed wasn't separable. A few minutes reconsidering this just now and it turns out a two pass method is perfectly feasible - so a quick rewrite later and I have this:



Posted Image



This version gets rid of the worst bleeding artifacts in both the near and far field by adjusting any texel's circle-of-confusion radius based on the depth values of neighboring (and occluding) texels.



Posted Image



I apply a basic dilation filter to bring out the brighter values, but I think I'm probably going to have to render some small point sprites to really have those distinct iris blade patterns pop out.




Posted by , 24 October 2015 - * * * * * · 1,540 views
clouds, radiosity, skybox, IBL

Something I've vowed several times I'd never do again: hand-paint a skybox.

The outdoor cloud-ish type specifically:

Posted Image

Painting clouds is all fun and fulfilling, until you need to fill out a full 360 degree view with dozens of them.

I preferred to draw a cloud scene as a spherical environment map; stretch around the outer regions is somewhat easier to deal with than the discontinuities along borders of the six faces in a cube map. (I always do my painting in Painter, so no clever 3D painting across seams for me.) Then you get the obvious issues with lighting (time of day etc.), that often require a complete repaint if you do not plan properly.

Anyway, the interface of the 'cloud tracer'-tool as it is now: Posted Image
options = [

   "mesh"         => loadmesh([ "path" => "D:/Temp/Cloud.lxo", "mask" => "Bake" ]),
   "env"          => loadimg([ "path" => "D:/Temp/Cloud_Env_2048.exr", "gamma" => 1.0 ]),
   "coverage"     => loadimg([ "path" => "D:/Temp/Cloud_Coverage.png" ]),
   "normal"       => loadimg([ "path" => "D:/Temp/Cloud_Normal.png", "channelmap" => [ 0, 2, 1 ], "levelmin" => -1.0, "levelmax" => 1.0 ]),

   "density"      => 0.025,
   "densityhaze"  => 0.00025,
   "tilelevelmin" => 0.4,
   "tilelevelmax" => 1.0


saveimg([ "textures" => tracer(options) ]);
The "mesh":

Posted Image

CREEPY. Posted Image

I skipped the simulation pass I initially planned on implementing, and simply modelled and replicated a series of basic cloud shapes. These cloud parts are all made up of smaller convex elements, which makes ray-testing fast and robust (occlusion tests against translucent convex objects make up the bulk of the work). I've also been meaning to try and run a radiosity solver on a low-resolution proxy mesh and have its results mapped back onto higher detail geometry - these convex bits seemed like a good candidate.


Posted Image

Illumination comes from a single light probe for now.


I got to doodle some more clouds by hand: geometry is expanded using these normal mapped 'depth billboards', which then have results from the lighting pass projected onto them. They're cheaper to render than volumetric textures, as there's no ray-marching involved. Also, 2D textures are far more straightforward to produce. I might come back to volume textures for other reasons later though.

Then there's some stuff about global cloud density and fog values for space in the scene that's not occupied by cloud geometry.




- Clouds need to be a bit more whispy here and there.
- The in-modeller point cloud replicator I used does a fairly good job at coming up with interesting cloud shapes, but I feel a custom distributor could still do better.
- The radiosity pass finishes pretty quickly as I had hoped, but tracing the final 2048 * 2048 image takes a while running on the cpu - needs more Compute.

Apologies for all the going back-and-forth with the camera.

Lastly, a bit of blatant self-promotion: I've been looking to do some graphics/tools programming for a U.S./European studio. If anyone can think of someone who might be interested, I'd love to hear (doesn't have to be game related per se).


Posted ImagePosted Image

Recent Entries