[RELEASED] - Screen Space Area Lights (SSAL)

Textures need to be located within a Resource subfolder.
For example:

redLights/Resources/TearsOfSteel2

or
yourContent/Resources/Images

 

Ok, cool, thanks.

 

Update for tonight. Support for IES light profiles is almost complete and will be included in the next release.



Have a nice evening!

 

So I picked this up and it's pretty awesome. I did find a bug related to a shader of mine. I have an alpha mask colorizable texture, basically the masked portion does not receive material color under normal lighting conditions, but in redlight area color light, the portion of surface in shadow is masked while the portion in light is not masked, receiving the full color of the material. I can send you the shader if that will help you debug this situation. Please advise.

 

Good morning and thanks for the purchase. If you send me the shader we will take a look.

 

Sent private msg. Thanks! Other than this problem, the lights look great! Very happy with the product.

 

Is this compatible with toon shaders? (Toony colors pro)
I wish there was a try before you buy watermarked version, we could test it with our various shaders and setups 😀
Thanks

 

I just bought this package really liking how soft the lighting is compared to normal lights in unity and just all the great things it has to offer for lighting. Some questions.

1. When do we get to test out the IES lighting really looking forward to that and is sorely needed for interior realistic lighting.

2. Was wondering if these types of lights you can bake in lighting with? Reason I ask is the lighting on spherical lights for example looks so soft and not those ugly rings that always appear on unity point and spot lights. Curious to know if that type of soft lighting can translate to bake lighting as well.

3. Can an entire interior house(2 bedroom, living room, kitchen, bathroom) be lit using area lights only and still be able to run on most machines? Now I know this question has way to many variables that apply to the circumstance but just in general good rule of thumb how many lights should be in VIEW at once sort of thing. I'm new to real-time area lights so I just wanted to know how processor intense they are when using them for scenes.

Keep up the great work. This is a great buy!

 

Hi problem spotted and fixed, see pm. But like I said, it's a bit involved and we are currently thinking about an elegant way to integrate this into the package.

The next release will also contain an in-depth explanation on how to use custom shaders with our lights.

 

Hi this is a bit tricky, since the toon shaders use custom lighting models, which are currently not supported by our package.
You could get it to work, but it would require a couple of modifications.

 

IES support for point light sources will be included in the next release. We might setup a little demo before.
As to when we will release the next release: We hope to get it out this week, but since there are quite a bit of new features, we need more time to shape things up codewise and do testing and all that stuff.

Nope, sry. Our lights are rendered as a postpro effect in the very last step of the rendering process and thus are unfortunately not compatible with the Beast lightmapper in a sense that they can be baked into a lightmap. However, you can use our lights as realtime lights on top of a previously baked lightmap.

Generally speaking yes, that should be possible. But like you said, there are many factors that have to be considered when doing this. Our lights are more expensive to render compared to the standard lights, since the lighting calculation is more involved, but you can use multiple lights at once, no problem. But it really depends on how you setup your lighting and which emitter types you use.

For example textured rectangular emitter with spec are more expensive to render than a simple monochrome emitter with no spec and so on...

 

Can I use light culling mask with SSAL?

 

I'm afraid, you can't. Our lights are rendered in screenspace and right now there is no way to distinguish objects based on culling masks.

But it's an interesting suggestion. We need to think about it.

Thanks!

 

Hi guys,

redLights 1.5 has just been submitted and is currently pending in the review. Hopefully it won't take too long.

Among quite a few of bug fixes and code refactoring this update will include:

• Support for multi camera setups such as the Oculus Rift. We tested this with the official SDK (OVRCameraController, OVRPlayerController)
• Basic IES light profile support for point emitter. We support IES profiles, that have been exported with iesgen_4. http://rip3d.net/Downloadmodels/iesgen_4.rar
• Diffuse/Specular lighting can be switched on/off separately for all light types, as requested.
• Improved support for custom shaders/materials. We added an example shader that demonstrates the steps, that are required to get custom shaders working with our lights. Right now we don' support all available material attributes. If you are unsure, if your shader will be supported, please contact me directly.
• We finally updated the documentation...
• Plus some more, that I can't remember right now

Have a nice evening!

 

Just downloaded the latest version (v1.5) and upon import it throws the following errors :



There are inconsistent line endings in the 'Assets/redLights/Resources/Shader/WorldNormal.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

There are inconsistent line endings in the 'Assets/redLights/Resources/CustomMaterials/Camera-DepthTexture.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

There are inconsistent line endings in the 'Assets/redLights/Resources/Shader/UnlitTransparency.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

There are inconsistent line endings in the 'Assets/redLights/Resources/Shader/UnlitAlbedo.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

Shader error in 'redPlant/AreaLightCylindrical': Shader compilation produced no results (compiler crashed?)

Shader error in 'redPlant/AreaLightCylindrical': Parse error: syntax error at line 10

Shader error in '': Parse error: syntax error at line 375

 

Hi,

AreaLightCylindrical.shader has been removed in 1.5. You can delete it safely.

I'm assuming you did not make a clean import, but instead tried to update the package in an existing project?

Martin

 

Btw... 1.5 is online.

This time it didn't even take half a day to get approved. Quite strange...

 

Ah! Exactly. I didn't make a clean install.
But what about the other warnings?

 

Well, ignore them. The warnings shoudn't cause any problems.
I converted these line endings like a gazillion times, but they keep popping up. It's most probably due to some esoteric git setting. But until I find out, which it is, just ignore them...

 

Clean install, and warnings still happens.


There are inconsistent line endings in the 'Assets/redLights/Resources/Shader/WorldNormal.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

There are inconsistent line endings in the 'Assets/redLights/Resources/CustomMaterials/Camera-DepthTexture.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

There are inconsistent line endings in the 'Assets/redLights/Resources/Shader/UnlitTransparency.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.

There are inconsistent line endings in the 'Assets/redLights/Resources/Shader/UnlitAlbedo.shader' script. Some are Mac OS X (UNIX) and some are Windows.
This might lead to incorrect line numbers in stacktraces and compiler errors. Many text editors can fix this using Convert Line Endings menu commands.


Shader error in '': Parse error: syntax error at line 375


That last one refers to the "Camera-DepthTexture.shader".

Also, oddly the previoius version did not have the above "inconsistent line endings" warnings.

 

I get them all the time when using monodevelop, and every so often in vs but not nearly so often, they are completely harmless though, as far as ive seen

 

@I am da bawss

You are right, the error occurs in 3.5.7 on Mac. Seems like, the shader compiler is more picky than it should be in that constellation.

Anyway, you can either ignore the error, since it doesn't influence the rest of the package, or you delete the file "Camera-DepthTexture.shader". You really only need it, if you want to integrate our lights with custom shaders, that are rendered with RenderType-tags other than the standard tags.

That's why we commented the whole source out. It's just for demonstration purposes and we didn't expect the compiler to complain about an empty source file. Sorry for the confusion.

Martin

 

Any way to use these lights with the new 4.3 Sprites? Tried the default and diffuse Sprite shader but no-go.

 

Hi,

It should work, but since I don't have any sprite content at hand, it's difficult to do any testing. If you can send me an example project with a couple of test sprites, I'll be happy to take a look.

Martin

 

Hello MPanknin. Sorry for asking again, but... What about shadows? You still planing to implement them? And do you plan to do a mesh light emiter?
Im little noob in programming, so i even dont know is it possible even.

 

Hi zelmund,

sry for the late reply. Yes we are working on the shadows, but we still can't tell you a reliable release date.
We might look into something like this, but there won't be any arbitrary mesh emitters.

Martin

 

!!! Ooh, based on the emails we've exchanged, the fact that you're looking into that shadertoy demo has me excited

Shadows and a reflection blur effect based on the reflective surface's gloss/roughness map (also like the shadertoy demo where patches of certain textures have smoother/sharper highlights while others have broad/blurrier ones defined by the gloss map) are the other two components I'm extremely interested in.

I'm really looking forward to seeing how this progresses, because right now it looks like you're on track to have the definitive area light system that will bring a lot of Unity's dynamic lighting up to the level of the stuff we're seeing from next-gen (XB1 and PS4) engines

On a somewhat unrelated note, do your lights universally work with any arbitrary plugin or effect that samples lighting data? I've been looking into illuminated particles recently and stumbled across this: http://www.edelweissinteractive.com/products/cloud-system/good-evil-demo-preview/
It's not really a make-or-break feature but more idle curiosity if your SSAL system would theoretically illuminate special-case shaders like that.

Cheers!

 

My bi-monthly thread trawl!

Just curious whats next for this very fine piece of asset? Last we talked there was a possibility for inverted-sphere emitters...maybe?

Also, I'll second (I'm sure I'm like 6th in line actually) the desire for shadows...no pressure, hehe.

Cheers mate

-Steven

EDIT: Bonus Question! Does this commingle nicely with Physically Based Shaders (i.e. Alloy, Jove)?

 

Hi Nick,

theoretically speaking this is possible. However it would require an update of our current g-buffer setup. Right now we only generate buffers for normals, albedo as well as specular power. Taking into account other parameters such as gloss, reflection color and brightness would require additional replacement shaders for generating the respective renderbuffers. In addition to that, we need to update the lighting model that is used on our lighting calculation to accept these new parameters.

We have both items on our roadmap for 2014.

There are a couple of steps involved, when integrating custom shaders with our package. Check the subfolder Resources/CustomMaterials for an example shader/material. The shader CustomExample.shader uses a "RenderType"="CustomRenderType" tag. In order to make this custom shader compatible with our lights, you must also provide proper replacement subshader, so that your custom objects show up in our g-buffer. Right now you must write subshader for depth rendering, albedo/specular power as well as world space normals. Most of the time this code will be identical among different rendertype tags. Since there is only a single subshader allowed per rendertype tag, there will be some redundant code. This is just the way how unity handles its internal rendering.

Martin

 

Hi Steve,

I was looking into the inverted sphere lighting, but it turned out to be a bit more tricky, than I initially expected. But It's still on our todo list.

Yep, we are currently doing quite a bit of research in this regard. But I'm afraid we can't tell you a reliable release date until now. Thx for your patience...

It should be compatible as long as you generate the respective subshader. See above. I'll try to grab a copy of the alloy package and do some testing. I'll keep you posted.

Merry Christmas!

Martin

 

And sorry for not coming back to you guys earlier.
The last days of the year are always a bit turbulent...

 

Hi,
I'm trying to publish the demo scenes from the last version but they won't compile. The problem is that the IESParser.cs script uses the UnityEditor namespace but it is not inside a editor folder. So at compilation Unity throws some exceptions. When I comment out the UnityEditor directive I can compile the scenes.(But don't know if something else will not work. ) I also have problems with Unity in general when opening one of the scenes. (Unity crashes when I try to reopen my project, which only has the arealight asset . I have to open another project, then changing to the areallight project without crashing the editor. When I try to reopen the project Unity crashes and I have to open another project and then change to the areaLights project ). I'm using Unity 4.3.1f1 on Windows 7

 

Hi,

that's strange, but we didn't do any testing with the new 4.3 to be honest. I'll look into it and come back to you tomorrow.

Just in case, can you please PM me the editor logfile after you have experienced such a total crash? Location should be something like:
C:\Users\YourUser\AppData\Local\Unity\Editor

Thanks and have a nice evening!

 

I just bought your package and I'm toying with it.

I think we might be able to add this to our game, but have some questions;

How do you calculate the performance costs? Is it a one time cost + each light affecting the view? Or is it more complicated?
How does it react with culling? Can I put as much light as I want in the scene knowing that with the culling only a few are calculated at one particular moment and the other are symply skipped?
Does the size of the light affect the performance or is it a fixed cost per light?

We are making a FPS, do you have any recomendation for that type of scenes/games?

 

Hi and thanks for the purchase!

Rendering of our lights works roughly as follows:

Per frame, we need to generate several renderbuffers (world space normals, albedo + spec power as well as transparent objects). This is done once per frame via shader replacement (check UnlitAlbedo.shader, UnlitTransparency.shader and WorldNormal.shader for details). Since these are actually geometry passes, rendering cost depends on the complexity of your scene and this step may/may not be expensive.

After the necessary buffers have been created, each light is rendered independently with a fullscreen quad as proxy geometry. Performance of light rendering is decoupled from your scene complexity, since in this step we only take into account information that is present inside the respective renderextures.

So yes, there is a one time cost for constructing the g-buffer plus the cost for each light.

I'm afraid no. There is no automatic culling in the current version. It is up to you to decide, which lights are visible/invisible and have to be activated/deactivated.

Generally speaking it is a fixed cost per light, since each light is rendered as a fullscreenquad. However, different light types may have different performance charateristics. For example, a rectangular textured light emitter with specular is more expensive to render than a single colored emitter without specular and so on.

Btw. I just watched the demo video that you published on your facebook page. Looks awesome! Keep it up!

Cheers,
Martin

 

Thanks for those details and thaks for your kind words about Storm united ^^

For the culling maybe you can try to place a super small (invisible?) cube then arealight.enabled = renderer.isVisible ?

We do some rendertexture voodoo in our project and those cameras have Viewport w=0.33 and H 0.64 . Because of this the post process can not be used.

Any solution to that?

 

Hi there,

I noticed that when using the customfalloff script, the effect is "inverted" up-side down when the project is set from Forward to Deferred, is there anyway I could solve this issue?

 

I'll look into it. What Unity version and OS are you using?

 

Rendering with non-normalized viewport rects is a bit tricky. We have implemented something similar with respect to the oculus rift, so it is definitely possible. If you can send me a simple example scene with one of your camera setups, I'll be happy to take a look.

 

@MPAnknin

Using Unity 4.3.2f if I am not wrong. Running on windows 7 64 bit.

 

Hello ! This product is marvelous !

BUT I am having a problem:

in the editor, all the arealights is marvelous !

BUT when I do a build export ( Windows 64 - Running: I3 4GB Ram onboard video ), the game crashes, and even start,

I Tried just enabling the script Area Light Render -> OK
But If I enabled any arealight object , the game crashes,

What I can do ?

I am using Unity 4.3.f1 On Windows 7 64

Many thanks

 

Folks, After more research, I see that, if i use spherical are lights it dont crashes the game but the colors is really different from the editor mode, I am using linear space lights with deferred render,

 

Hi, that is really unusual behaviour. Please send me the unity log file after the application has crashed. Even better, send me a simple unity project that we can use for reproducing the problem.

Thanks

 

Again, we need some more input (screenshots, example projects etc.) from your side in order to reproduce what is going on. Just upload it somewhere or send me a PM.

Thanks

 

I'm interested in purchasing this asset, a couple of questions.

I understand shadows are not supported, so does the light continue on through objects like unity lights (area) without shadows? Or can you set a falloff distance?

Is there a limit to the number of lights you should because of performance?

Can performance be increased with occlusion culling? Thanks.

 

Thanks for adding stuff that I've asked for! Also Ive got question.

Do we really need so much junk in Resources directory? Those files are loaded into memory in every scene!
You can also find there 600 images with post-frame movies.

You should release those demos as separate unitypackage which you can import when you need it.

 

I don't think everything in Resources is loaded into RAM for every scene. However, they are included in every build, regardless of whether any scenes use them so it's still a good idea to limit the amount of stuff sitting in there.

 

I'm afraid, there are no shadows at the moment, so light emission isn't blocked by any scene elements. It's basically the same behavior as the built-in lights in forward rendering (except the directional lights). However, there are different falloff options, that you can use to adjust the range of the light.

For example, the default falloff is a basic constant, linear quadratic falloff with all parameters exposed to the user. The second mode lets you define completely custom falloff functions using the built-in function editor. In this second mode you can also define a max distance that limits the range of a single light.

It really depends on your scene and also the hardware you are targeting. Per frame, we need to generate several renderbuffers (world space normals, albedo + spec power as well as transparent objects). This is done once per frame via shader replacement (check UnlitAlbedo.shader, UnlitTransparency.shader and WorldNormal.shader for details). Since these are actually geometry passes, rendering cost depends on the complexity of your scene and this step may/may not be expensive.

I just randomly placed 100 lights in the stealth demo scene, that can be downloaded from the asset store.

First image. Scene is illuminated by redLights. (Per frame g-buffer construction plus fullscreen light rendering)


Second image. Deactivated light rendering. Per frame g-buffer construction is still active.


Third image. Deactivated per frame g-buffer construction.


Last image. Same scene illuminated by standard point lights.


So in this example the construction of the g-buffer has the most performance impact. The performance drop of subsequent light rendering is negligible. However, if your scene is less complex in terms of geometric detail, generating the renderbuffers will be less expensive.

Hope this helps.

Martin

 

Hi,

in the beginning redLights and the respective demo content were separated for this exact reason. However, we encountered several problems. First of all, the assetstore publishing guidelines demand reference material that is included in the package itself. Second some people downloaded only the demo content without purchasing the redLights before and were confused why stuff, that they downloaded from our website wasn't working. And that's why we decided to put it all together into a single, big package.

If you don't need all the reference material, which I agree is quite a lot in terms of image files, I would recommend deleting the redLights/demo folder and exporting the redLights folder as a cleaned package. We do this all the time with assetstore packages. Download, check out the demo material to get a feeling of how things are working. Afterwards throw out everything that is not needed and export a clean package.

Cheers,
Martin

 

Hi there,

we just uploaded redLights 1.51 to the AssetStore. Unfortunately not many new features in this release, only bug fixing:

• Fixed problem with fog rendering and normal buffer.
• Fixed problem with linear / gamma color space and RenderTextures.
• Fixed ultra strange bizzaro bug that caused unity 4.3 to completely crash during startup.
• Fixed vertically flipped uv coordinates when rendering path was set to UsePlayerSettings.
• Changed loading of IES source files. IES files must now be provided with the .txt extension.
• Some code refactoring.

Have a nive evening!