the team of redPlant is excited to announce the upcoming release of the new redLights 2.0 plugin. In order to support the new rendering goodies in Unity 5.0 we have rewritten our area lights from scratch. The new version 2.0 is not based on SSAL anymore and follows Unity’s rendering pipeline more closely.
The new lights support most of what the stock lights are capable of (forward/deferred, mobile/web/standalone, light culling masks etc.).
redlights 2.0 are more flexible, faster and better looking!
Works in Forward & Deferred Shading rendering path
Works on Windows / Mac
Roadmap for future updates:
Mobile support. Mobile export is already working, however we still need to do some performance tuning, before we support it officially.
Support for textured emitter (Rects & Spheres). We have a working version for this, but we need to eliminate a couple of minor rendering glitches, before we support it officialy.
Not out of the box, I’m afraid. Skyshop uses it’s own suite of material shaders, while we only support the new PBS standard shader that ships with Unity 5.0.
Not sure, how complex it would be to integrate our lights with Skyshop, but it should be certainly possible. We’ll do some tests after we have released redLights 2.0 and keep you guys posted.
No, we don’t use CommandBuffers. We’ve read that article with great interest, but right now we use a different setup that avoids any pro features.
We might switch to CommandBuffers in a future update, since they certainly simplify a couple of things but beforehand we need to figure out if/how they can completely replace our current setup (in forward rendering for instance).
small update for today. We survived carnival and will upload our package to the assetstore this week (probably tomorrow). We are currently finishing the documentation and are preparing the key images for the store entry.
However, we have decided to release the package in two phases, since there are still some minor glitches that we want to get rid of, before releasing all the functionality.
Just to be clear, this works just fine then with Enlighten? (understanding as you say this is no different than standard unity lights)
As it is now, Area Lights appear broken in U5.x, where intensity is dictated by the size of the emiiter, yet you clearly have area lights with an intensity parameter. Your emitter strength is independent of emitter size?
our lights can not be baked into lightmaps at the moment. However, they can be used on top of other lightmapped materials. We are currently investigating several ways to support enlighten. But this won’t be included in the current release.
I’ll update the first post to avoid any future misunderstandings. Thanks!
Yes, the size of the emitter influences the lights intensity. However, if you want you can still attenuate / amplify the lights intensity with the respective intensity parameter.
Okay and to be even clearer, I was referring only to real-time Enlighten. I figured if it’s not much different than the Standard Light model in Unity, it would work with their Standard Shader thus contribute to the lighting solution.
Yes, it does work with the new Standard Shader. But to be honest I’m not sure if I understand your question correctly. If you can explain to me what exactly you are interested in, I’m happy to do a quick test.
Using the Standard Shader/Emissive, you can make any object an Area Light that then contributes to the GI solution and lights the scene, in real-time. Do your lights behave like emissive “Area Light” objects in Enlighten? This has nothing to do with baking lightmaps, just how they render with Unity’s new core PBS and Enlighten lighting system.
I’m afraid, it’s a new package, that you have to purchase separately. There isn’t much left of the old codebase (maybe 5%) and therefore we can not simply release it as a free update.
(For example Skyshop integration)