Unity5: How to add a lightmap to standard shader?

I can't figure out how to add a lightmap coming from an external package (e.g 3dsmax, usually baked to UV-Channel 2) to the new standard shader in Unity5.
The occlusionmap-slot is definately the wrong place for this, it´s on UV1 and tiles with the diffuse/normalmaps.

I know there´s an extra forum for this, but I don´t get any answer there.

 

You can download the source for the standard shader. Just add another map to it that uses the UV channel that you want.

 

Thanks!
Unfortunately I´m not familiar with shadercoding.
I´m afraid correctly implementing a lightmap is not that easy at all.

In my opinion this can only be a temporary workaround:
Lightmapping is a fundamental missing part for this shader as it is one of the most important new feature in Unity5.
I really would like to have an official statement from Unity-developers.

 

Lightmaps are not new to Unity 5 as they already existed in Unity 4, maybe even Unity 3.x. The workflow didn't change considerably. If you bake the lightmap in Unity, you don't have to assign it because it happens automatically. If you bake it somewhere else, you need to create your own shader.

 

I see, even if Shaderforge can do the same PBR stuff, too, it´s a shame and very disapointing to me that the new standard shader is not supporting custom lightmaps and we are forced to use legacy shaders.
They simply ignore the workflow from professional studios.

 

Don't get me wrong on this. I completely agree that this would be very useful. This is the kind of trade off that needs to be made if the interface has to look as simple as possible. When it comes to advanced functionality, it is not anymore possible without a considerable amount of work.

 

Ok, fine.
After all I would summarize that adding this feature to the standard shader should not be a big problem for the programmers but would be a big plus for us users.

 

It is not as simple as that. If there is a slot for lightmaps, it needs to be visible all the time. If the lightmap is baked in Unity, it is necessary to show that one as well, though the baked lightmaps are hidden at the moment. Of course, Unity could make them directly visible, but you can be sure that some users would start to draw on those lightmaps directly and would loose their changes after a rebake. And as the lightmaps would need to be visible, it is not clear what should happen if someone uses a lightmap texture in a non-static object. It might just work for the moment but would break after a rebake.
It would take away some of the automagic nature of Unity, but would have the nice side effect to teach users how it actually works

 

Right, this is the old discussion between simplicity/userfriendlyness versus the advantages of a professional 3d-production workflow.
We are doing architecture presentations with Max+VRay+Distributed rendering and all that stuff.
It´s kind of frustating that this superiour baking-workflow is not really "supported".

An idea would be a switch where users can chose between Unity-Lightmapping and "Custom"-Lightmapping:
But why isn´t it possible to display the lightmap in Unity and let users easily chose between the Unity lightmap and an external lightmap? I don´t see why users should "draw" on lightmaps?

I can´t imagine that the big studios are accepting these restrictions and do their lightbaking in Unity.
Maybe they chose other engines.
My company just started looking into UE, will soon now how its handled there....

 

I know people who bake their lightmaps in other applications, such that they are able to modify them by hand to get the look they want.

That's not really a criterion for a big studio. They use either their in house engine or write custom shaders for their workflows. Writing custom shader's isn't that complicated.

 

Since I never ever rendered lightmaps outside of unity... if the only problem with occlusion maps is the wrong texture coordinates, can't you Change UnityUniversalCore.cginc

Code (csharp):

1. struct VertexOutputForwardBase
2. {
3. float4 pos : SV_POSITION;
4. float4 tex : TEXCOORD0;

to

Code (csharp):

1. struct VertexOutputForwardBase
2. {
3. float4 pos : SV_POSITION;
4. float4 tex : TEXCOORD1;

or something like that? That should use UV1 for occlusion instead of UV0

 

It is not a good idea to modify any standard shader or cginc directly. There will be a possibility to use the standard lighting in surface shaders in b12. This should make it a lot simpler. Remember Unity 5 is still a beta version.

 

Unfortunately, there's no way that a hybrid lighting system for a realtime/pre-baked solution can compete with a pre-baked GI rendering algorithm such as Vray. That's not to say that the realtime system won't eventually be able to outdate the pre-rendered solutions, but we're not there yet. It would be great to use the lighting probes and reflections probes in the scene to work with the lightmap baked solutions that 3rd party applications produce. That way, you have the best of both worlds. Realtime reflections, dynamically lit objects, baked in quality lightmaps, and generated ambient bounce lighting, which can be changed dynamically. I think with a lightmap feature in the standard shader, we will get there.

 

Absolutely!

 

It have to be done

 

Responded in your other thread already, so just for completeness:
http://forum.unity3d.com/threads/st...htmap-from-3dsmax-on-uv2.278166/#post-1923095