Procedural static point lights (with source)

This is very interesting -- it seems to work pretty well with the voxel terrain I am working with.

Is anyone using this? Is it still relevant with 5.5/5.6? Are there any other assets providing the same/similar solution to shadows on real-time procedural terrain?

 

@jason-fisher
>Is anyone using this?

Not sure, my best guess would be half a dozen people downloaded it and edited it to fit their needs

>Is it still relevant with 5.5/5.6?

AFAIK it should work with maybe some minor api changes, and unity doesn't offer a toggle to stop updating shadowmaps so it is sort of relevant.

>Other assets for static-ish shadows on realtime terrain?

I'm not sure. Since the making of this there's things like sonic ether's GI, but it's a whole other type of beast. At the time I couldn't find anything like this.

I'm still using what in the core is this system but I've integrated it a lot with my own voxel system. I can't really update the repo because of that.

 

Thanks for the response -- I haven't been able to find anything else quite like it either. It works fine in Unity 5.6 beta here.

What are you doing for AO?

 

Post processing for now, it works reasonably well.

As for this system, I changed it to use a 32x32x32 3d volume aligned with the voxels, traced on the cpu in ~1 ms IIRC. The 3d volume lowers memory significantly & gives soft-ish shadows / some AO. It also allows for very tight bounding boxes for rendering.

 

Cool -- I'll have to look into extending that. I am working on a trilinear sample/trace of the voxel data for AO on the CPU (for now) and it seemed like this lighting solution would use a similar calculation and that maybe they could be combined.

 

@Zuntatos - you may also want to take a look at this thread if you haven't seen it yet:

https://forum.unity3d.com/threads/a...1-with-rendertexture-or-computebuffer.281346/

This should let you feed in voxel data via ComputeBuffers and pull it back without blocking.

 

Hey guys. This project looks really interesting - Is there still active work going on with it? Or any other plugin developments any of you have seen?

 

There isn't any active work on it. As I stated above, I've tightly integrated it with my game, which makes it quite unsuitable as a standalone thing. The base probably still works though - I don't think the API's have changed much since then.

 

Thanks for the update. Are you able to provide any resources on the work you've done here? I am particularly interested in trying to replicate the kind of lighting conditions found in games like The Sims 4:
Example: https://streamable.com/yoe2k

I assume The Sims 4 makes heavy use of static light/shadow maps and the majority of its procedural environment is static.

I'd love to get your thoughts on this, even if it means this project here isn't exactly right for the job.

 

Looking at that video it seems to be a similar solution to the one I'm using now, baking some shadows into a 3d texture. There's some videos you can find (from Colony Survival) (like this, one of the first results:

At 9:00 ish you can see a bit of how it works. Most youtube videos don't really show torch-lit night building though

I've tried various things like tracing a ray from the center to every block, but most of them fell short or didn't have mostly accurate shadows. The current system precalculates all blocks that are shadowed when a block is solid in about 2 seconds of loading time. This array-of-blocks-per-block stores whether they are 'partially occluded' or 'fully occluded'.

So when calculating shadows, I gather the surroundings into a 32x32x32 array. Then iterate from the center out through the volume, and for every solid block that is found, mark the shadowed blocks pre-calculated for that block. If you find a fully shadows block, ignore it. After iterating through all solid-non-shadow blocks, all the shadows should be cast.

Then it's a case of getting a texture3D (using R8 at the moment) and converting the is-occluded flags to the pixels. Sampling it is dirt cheap, and the interpolation gives a nice style to it combined with the voxel world. A convenient effect from using the CPU to precalculate is that you can also store the bounds of the lit area, and thus lower overdraw a bit. It still is a pixel light though, so still sort of expensive up close.

Range or resolution is fairly limited though. This 32x32x32 takes about 1-2 ms on my pc, which is adequate enough for my case. In that video, it looks like the range is only 4 meter / 8 voxels though - so 16x16x16 - that'd be practically instant to calculate.

I've been thinking about changing it to use some fancy light propagation (possibly in shaders), but my spherical harmonics- & advanced math isn't good enough for it at the moment. It'd be a system similar to what Lexie has made here: https://forum.unity3d.com/threads/hxgi-realtime-dynamic-gi.472486/ .

 

This thing is outstanding . But is there any chance they affect GI and reflection probes?
ATM reflection probes wont read incoming light and shadows properly from PIP lights. Same goes with GI.
What is the exact reason for not interacting properly with them?

I ve been using it for months now, its core to my project (many thanks ) ,just a bit limited because of these two things.

 

I have no idea how to make it affect GI, haven't looked into it. My scenes aren't GI compatible at all .

For runtime reflection probes, it gets messy as hell. They're rendered with forward mode instead of deferred. You'll need some way to set up which lights to render in material properties, and edit the shader that's rendering the material into the probe to sample those lights' properties.

 

bake scene with normal standart shadows as usual. then turn them off and use pip lights. information about shadows must be saved in enlightin system.

 

On our current project, we are using a custom reflection probe baker, that allows us to use a camera with post-effects. It's also in deferred and much faster than Unity baking.

I downloaded this project to see what it was doing, and right now we are writing our own solution with some inspiration from it.

One thing we are doing;
- Shadowmap of static objects are baked into a texture and saved on disk. No need to redraw those all the time. (Alpha8 texture format is fairly light)
- We blit the shadowmap to a RenderTexture, than draw only dynamic object on top with a BlendOp Min.

The nice thing by baking that, is we can apply some nice filter on it, making far shadow a bit blurrier.

So the number of draw call for a light casting shadow is the number of dynamic object + 1.

 

@LightStriker sounds really cool mate! Is this something you would be interested in releasing open source or commercially?

 

Can you expand on that? I am really interested and I can't figure out the math

 

Can always consider it if there's some interest.

Since it's baked, you can do all kind of expensive post-effect on it. Like you do a smart blur, the further the pixel, the more blur.

Right now the point light works fine. I'm bangning my head on the spotlight, as I have no idea what I'm suppose to pass as unity_WorldToLight matrix.

 

I also don't know, but you can check the frame debugger window with a Unity spotlight and see what happens when changing the values, plus checking the built-in shader source code of the lighting (I don't remember the exact file)

Also, can you post an image of your lights with the blurred shadow? I really want to see them, as looking at lighting renders is always cool

 

I know, that's what I'm doing. But I'm still trying to figuring out how to build the matrix it wants. (Comparing the stuff pass to a normal spot light)

As for the blur post-effect, right now it's a theory I haven't tried. But for now it's nice to see shadow caster in our complex city using only 1 draw call

 

@LightStriker do you have any screenshots worth sharing yet?

 

Nothing crazy for now:


In this image, the spot light is 4 draw calls; the character, its 2 weapons, and the light itself. Everything else is from the baked shadowmap.

I finally figured out the spot matrix.

Anybody know where I could reach the default spot light cookie? Usually it's in _LightTexture0, but since it's not a real spotlight, Unity isn't passing it.

EDIT: Interesting to note... Doing Camera.Render() produce a ton of overhead compared to letting a camera perform its rendering like a normal camera.

 

Variance Shadow Mapping

http://www.punkuser.net/vsm/vsm_paper.pdf

 

Because why not... You can add a colored cubemap (for point light) or 2d texture (for spot) that is added on top of the cookie.

To reduce even further performance impact, you can make spot light "baked" only, or turn off specific faced rendering update of a point light. (like if it's closed to the ceiling, it might be pointless to update the up view)

 

Dang, I would love to have this!

 

Because I love to be a tease.

Oh... Because I like performance, each light can be set to turn off real time shadow and its rendering based on distance to the camera. Pretty useful for us to tweak each light to update and render only when it's truly visible.

 

Area light with cookie/filter.

What I noticed is that sadly, all those are only in deferred and will never affect a forward (transparent) object.
If it's possible, I haven't found out how.

 

Yeah as far as I'm aware, there's no way to do that. You'd need a way to pass the values (+ shadowmap) into the properties for the draw call, and then a custom shader to actually sample the shadowmap.

Hopefully the future scriptable rendering pipeline will make editing things like this easier

(P.S: you can do a lot with commandbuffers already, but you'll end up replacing a lot of systems)

 

... what shadowmap? That's another problem, I'm not using any because of their limitation. Sure, they are faster when using native comparison, but that's about it.

I haven't found a way to supply a custom shader for the transparent/forward draw calls on a per-light basis.

 

Yeah sorry, cookie. Same issue though

 

Pip Lights don't seem to work in 2017.3 / 2017.4, although they did work up to 2017.2
Can anyone offer any advice on getting this working again?

Edit:
Seems unity expects shadow textures in the Green chanel, or is processing shadow textures differently, changing Render texture format at

Code (CSharp):

1. shadowMap = new RenderTexture ((int)shadowResolutionCurrent, (int)shadowResolutionCurrent, 0, RenderTextureFormat.RHalf, RenderTextureReadWrite.Linear);

to

Code (CSharp):

1. shadowMap = new RenderTexture ((int)shadowResolutionCurrent, (int)shadowResolutionCurrent, 0, RenderTextureFormat.RGHalf, RenderTextureReadWrite.Linear);

causes shadows to render, but now lighting intensity and shadow strength are all wrong. Any idea on a proper fix?

 

Anyone still using this? There seems to be some kind of shadow bias problem with newer Unity versions and the above fix regarding the render texture format.

 

It may be that some of the shader macro's / .cginc's have changed and that those changes broke something. (I won't look into it, I haven't used this code in this form since ages)