Is this a local build or cloud build? We fixed recently an issue that the Cloud Build was failing to strip shaders and would cause massive build times + memory.
We’ve added an option in the pipeline asset to log shader variants recently. It will be in the next package. Meanwhile, disable in the pipeline asset settings from lighting and shadows categories. Those control shader stripping.
its a local build
Also, I disabled the lighting and shadows in the asset settings but it did not seem to make any difference.
What shader are you using? There was an issue with SimpleLit shader that got fixed recently (not yet available)
The main light is global and affects all objects. The per object limit controls the amount of additinal lights that can affect an object. They can be shaded per-vertex or per-pixel.
Can you post the full log so I can take a look.
Both of these issues are fixed now. I’ll generate a package for 2018.3 with backporting issue sometime next week.
VR team is looking into it. I dont’ have an ETA yet. We are confident we can enable it for DX11 and that should be done soon.
Sorry if it sounds off topic, but i was wondering why the option to bake indirect lighting is disabled in LWRP…
is this a sacrifice we have to take by switching to LWRP?
personally i would want to have some sort of baked indirect lights… it make scenes more beautiful to look at than baked shadows.
that being said, i wonder why it is not an option to have baked lightmaps to contain both shadows and indirect lights at same textures!
3815443–321058–Editor.log.zip (49.8 KB)
I’ll add a massive +1 to this, in the legacy rendering pipeline I think the dynamic GI is one of the most impressive VR effects you can get, especially when considering how well it runs.
I saw Andy’s talk on Unite LA today and wondering if we might face a situation where 2018.3 goes into stable while LWRP continue to be in Preview.
I am fine with the lack of some major features but it would be pretty bad to not have a stable release of LWRP for 2018.3 or 2018.4 LTS: this is the version of Unity we are inevitably going to use for current project (we are using 2018.3b in production at this point, since we want to use latest LWRP there isn’t any alternative.)
I am experiencing a peculiar problem with the property names in the shadergraph at the moment. Its possible that this behaviour commenced as a consequence of a shader being duplicated. The property names inside multiple other shaders seem to have changed themselves, but still only respond to their previous names. So that the name displayed in the shader graph (btw it has been saved ) is unresponsive , and responses from the shader can only be gotten by referring to it s previous names. Strange. And difficult.
And whats more…Even if i find out what the previous property name was, I am unable to restore it in the shader graph as every time I attempt to restore the name, it autocorrects it with an underscore at the beginning…which screws up all other scripts which previously referred to this shader.
No. You should not have a compilation error due to the RenderPipeline tag itself. If you use functions defined in LWRP shader library or SRP and if you don’t have the package installed, yes. It won’t compile. All Subshaders in a shader will be compiled unless you strip them with a custom shader stripper.
If you want to support both LWRP and Builtin with same shader file then declared a SubShader first with “RenderPipeline” = “LightweightPipeline” and a second with either “RenderPipeline” = “” or no RenderPipeline tag.
@phil_lira that’s not exactly the behaviour I’m getting: if I omit the RenderPipeline tag of the first SubShader section below, the shader won’t work in LWRP (shows in pink).
Using Unity 2018.2.7f1, LWRP packages correctly installed and working.
..
SubShader {
Tags { "RenderPipeline" = "" }
Pass {
...
}
}
SubShader {
Tags {"RenderPipeline" = "LightweightPipeline" }
Pass {
...
}
}
But leaving the RenderPipeline=“” makes it work for both standard and LWRP.
I would like to report another peculiar feature of the LWRP that I have found. I have found that if I have a material with a LWRP shader with a texture2D input, and a designated texture…if i remove the texture from the material and press play , it automatically reassigns the last placed texture back into the slot, like it remembers it. And then if I try to assign a new texture to the material, as soon as I press play it reassigns the previous texture. This does not happen all the time…just in some cases… not sure why
Hello I would like to see if its something I have bugged or its actual bug in LWRP, I have grass with Transparent Alpha material and when I activate receive shadows it just takes shadows for opaque shaders behind actual transparent material, had this bug on terrain grass shader aswell, but it was working from time to time but by putting the transparent material it just breaks it. Any fixes outhere caus I could not find any. Thanks
Is there any workaround for the 16 lights limit? Given the lack of both deferred path and realtime GI (hence no realtime light probe neither), I don’t know how to make an interior or night time scene where there are potentially more than 16 light source in view. (I can’t use baked light in this case due to working with a dynamic scene)
Another question is does LWRP 4.0.x still support SH lights? I believe it was working in 2018.2, but somehow with 2018.3b I can only get pixel/vertex light to work. (The additional light slider on LWRP asset used to cap the number of pixel/vertex lights per object, but now it seems to cap the number of all lights per object, including SH lights, so visible lights are always pixel or vertex now?)
Basically I am looking at SampleSHPixel but I am not sure how many additional lights are available per object exactly, is it still 1 + 8 (1 directional + 4 point/spot + rest is SH)? or is it 1 + 4 (no SH)?
UPDATE: I have posted some screenshots to illustrate my problems in a reddit thread.
https://www.reddit.com/r/Unity3D/comments/9rhxcr/lwrp_how_does_sh_light_work_any_workaround_to_the/
I also think this is a bug in LWRP 4.0.1 preview: changing the additional lights dropdown to vertex lighting shouldn’t disable the per object limit slider.
Hey ! It’s said that the lightweight render pipeline it’s planned to be release in 2019. But for what version, the 2019.1 ? so at the beginning of the next year ? It’s a little bit too large the “2019” version…
I asking that because i’ll be working at my work on mobile and we’ll be in need of that version.
I’m seeing the same issue as this - it looks like the culprit is maybe in SetupLightweightConstantsPass line 182:
// In subtractive light mode, main light direct contribution is baked on lightmap
// In this case we setup light position w component as 0.0f so we can remove it's contribution
// from realtime light computation
if (lightData.lightType == LightType.Directional)
lightPos.w = 0.0f;
Once we set the attenuation value to 0, we get no light contribution in either the LightweightFragmentPBR or LightweightFragmentBlinnPhong passes (Lit or SimpleLit shaders).
I don’t think we need to do this in the constants setup since the directional light contribution is removed from lightmapped objects in the shader (MixRealtimeAndBakedGI → SubtractDirectMainLightFromLightmap).
[Edit] - or not, that blows out my scene - but the problem is definitely that the attentuation is 0 for non-lightmapped objects…
[Edit Edit] And, I see there is a fix incoming - disregard
I am seeing another odd issue with mixed mode shadows -
When there are no objects being drawn into the shadow map, I get what looks like a large shadow drawn across the scene - this changes position / orientation and pops on and off when I move the scene view camera around. Also, this happens in a standalone build:
