As a lot of Unity features, point light shadows are either fully dynamic or they require static geometry and baking in the editor. If you’re procedurally generating terrain, and want to light it statically, you’re out of luck.
I haven’t been able to find something to fix this in unity3d yet, probably because it ‘needs’ things like command buffers to be implemented properly, and those are fairly recent. So I made my own system.
Early test results: Custom lighting in unity3d - Album on Imgur
Demo file: https://drive.google.com/file/d/0B7PRzgpiVzsAR293b2lsWTNxLVk
It’s a self-extracting 7z archive, as the demo is 110 MB due to a heap of sphere meshes and simple zip was shitty at compressing. I promise, no malware 
Demo consists of 2000 spheres being lit by 55 point lights (so complex and realistic!)
Source code link: Bitbucket
Edit: Big rewrite/deletion etc. Added demo file
Edit2: Some demo information
Edit3: Added source
7 Likes
I would be very interested in a system like this. I work with a lot of architectural scenes that make heavy use of dynamic lighting. Some of the missing features that would be a must have for me would be a working recieve/cast shadow option and also support for cookies on point lights. I never use spot lights but directional lights would be nice to have as well. Looks very good and thanks for sharing. Looking forward to any updates on this.
A system that fully replaces unity lights with ones that are more accessible through script would be nice. I really wish there was a way to get access to the shadow maps generated by lights for other random purposes. Area lights ( sphere, square, tube, etc with textures would be nice as well.
Cubemap cookies for point lights should be rather simple to add. A working receive shadow option won’t work, as this needs deferred rendering to work properly. Cast shadow - maybe, have to look into it. Layers would work for casting shadows already, but again not receiving shadows. Directional lights should be doable as well, just need to figure out some orthogonal camera math.
That’s exactly what I thought.
Area lights could be added as they are in the command buffer examples from unity itself, but it’ll be madness to add cookies and to add proper area light shadows (except maybe lerping between different point lights).
Cubemap cookies would be the most important for me, as I use them on just about every light. Good to hear that they would be simple to add. Any updates on this? Thanks!
Haven’t been working much on it. I’ve replaced most of the custom code with versions that already existed in the builtin .cginc’s, but it turns out half of the values that are used in there will be overwritten if set manually via commandbuffer.setglobalvector and similar. I had to make some ‘duplicate’ values for those. There’s also no documentation for half the code (which variables used for what, what are in them, when are they set by unity).
Using the .cginc’s added support for using the GGX option present in them instead of normalized blinn-phong & the same soft shadows as default lights. It also optimized the code a bit and probably added compatibility options.
There’s support for cookies in the .cginc’s in the form of a _LightTexture0 cubemap in combination with a #define POINT_COOKIE iirc.
TL;DR: Basically rewrote shader to use unity’s code, more options/fps.
P.S: Found interesting things as well. Shadow bias hardcoded to 0.97 (probably 0.03 as setting) in the .cginc for point lights, no wonder that option didn’t work for me
P.S2: It looks like practically all performance difference between my lights are the builtin lights (when updating) comes from Camera.RenderToCube() blitting 6 times into the cubemap for some reason
I’ve actually written a runtime lightmapper that can bake a decent sized scene in ~5 seconds, would be interested to see what you have done, perhaps there is some areas where we could help each other
It’s not really what I’d call lightmapping. It merely attempts to do exactly the same as the builtin lights + their shadows, and then add in options to re-use the shadowmap from previous frames for a big performance boost.
On progress:
Added support for rendering the lights in-editor. (Workaround with an editorwindow to grab the camera)
Added support for non-HDR rendering
Added most of the inspector interface, mimics builtin lights now.
Added gizmo’s
Added soft shadows option
Added shadow strength option
Added culling mask; select which layers cast shadows.
Added an optional range check to discard pixels that are known to be out of the light’s range
Added an option to discard pixels that are known to be shadows
Both these discards improve performance on my simple test scenes on PC. Need some complex scenes to test further.
Fixed shadow bias not working due to builtin-cginc-port
Changed level of detail algorithm to be more sensible (could lower detail while inside a big light’s range)
I’ll have to find some sample cookies to add support for them, didn’t find any at my first google search.
True about the lightmapping, although lightmapping could be natural progression. Nevertheless I am quite excited to try these lights out and see if I can’t learn a thing or two from them!
Zuntatos, I’ve got some cookies I could send you if you still need some.
Cookies working now, including rotation, doesn’t require a shadowmap update to rotate it as well.
Fixed the work-around to make lights work on the scene view so now it works properly
Added ‘refresh all shadows’ button to light inspector.
Added option in right click menu to make a new light.
–Maybe something else, can’t remember.
Nice, sounding good. What are your plans for releasing it?
Not sure. Atleast before any form of release i’d have to refactor some code to have sensible naming, optimize some and make sure the editor plays with them nicely.
For the release itself, I’m still in doubt whether to release it to the asset store for free / for money (what price?) / just post it on a public bitbucket for everyone.
If I’d go for the asset store, I’d add spot light support as well, to make it more of a whole replacement. (Directional static is a possibility, but it won’t have cascades and it’d be limited to a box area)
Sounds good. I’ll be on the look out for updates. I’m definitely interested in it.
Updated OP with a simple demo scene
My machine wont allow me to download the demo, perhaps its just my machine though (IT at work locks some connecctions down)
Worked well for me. On my work machine which I was getting 47 fps with unity lights and 212 fps with the custom static lights. Huge difference, very nice work.
Hi Zuntatos. Any updates on this? I’ve got a project I’m working on that could make great use of this. Would love to test it out. Thanks!
Eeeh didn’t work on it at all past days. I’ll do a quick refactor in the coming days somewhere and put the source up for free