Light Probes Questions/Feedback

ok I got it, I need to add

Code (csharp):

1. float3 worldNormal;
2. INTERNAL_DATA

to the Input struct.

It now samples it very nicely.

Can anyone tell me what the 4th value that gets passed into ShaderSH9 is for? Setting it to zero seems to make it darker but it's still getting the lightprobe light.

 

This is all good.

Is there any way to decode specular highlights from probes? Or is there a decent approximation method I can use?

Edit: I found this in a paper on the internets

Do we have a view-reflection vector lying around?

 

I'm now using something like this, I dunno how much of a hack this is, but it gives what I think is nice looking shiney specularity.

Code (csharp):

1.  
2. fixed3 worldN = WorldNormalVector(IN, o.Normal);
3. fixed3 worldR = normalize(WorldReflectionVector(IN, o.Normal));
4. o.Emission = o.Albedo*ShadeSH9(float4(worldN,1.0)) + o.Gloss*pow(ShadeSH9(float4(worldR,1.0)),2.5);

The 2.5 is a hard coded shininess value, the higher I make it the smaller the specular highlights get.

 

I'm just wondering, do the coefficients simply get applied per object or do you have some other "magic" way so that it works properly? And if it's per object, how does it handle really large objects (so that they usually should use multiple probes) and batching?

 

Coefficients get applied per vertex. You can find the code in one of the cginc files.

The average probe gets calculated per object though, this scheme isn't designed to help with big objects.

If you have big static objects and lots of lights, use lightmapping. If you have big dynamic objects and lots of lights use deffered.

 

Yeah i know, but thats the calculation stuff inside the shader. I was wondering how they get passed from the cpu.

 

How about Dynamic object like trees in terrain? when using lightprobe it's losing dynamic light from direct light (or any light source).

 

Uhh..something like this, maybe I said it wrong (somehow) on my previous comment so i'll speak visually.

The big one placed manually it's receive direct light and lightprobe as well (but the leaves didn't receive any dynamic light, only lit by light probe). And...the small one placed using terrain engine and it didn't receive any light from lightprobe. And those two came from the same prefab.

 

I just realized if you guys are interested in faking specular highlights why not just do it with a cubemap? Use reflective bump spec, allow it to use the light probes... but at the same time have a cube map applied that looks like specular highlights... Sort of a ghetto hack , but it looks pretty good. I actually think thats the way halflife 2 did it back in the day. Not exactly accurate, but still looks better then nothing.

Oh but one of these shaders will still need to be modified to take advantage of the diffuse with light probes that someone else was doing in these posts...

Would love it if someone could post a diffuse bumped shader that also has a cubemap support to fake spec highlights ... I dont know how to write shaders. You can even change the cubemaps as you enter different rooms by using different instances of the material based on the character and his location.

 

The problem is not adding cubemaps, but having multiple ones and blending between them, like lightprobes are doing.

 

Light probes are applied as spherical harmonics, so they can be passed to the shader as only 9 float coefficients (i think it was 9 right?). This can be done separately for each object without creating multiple materials (and i'd guess without breaking the static batching as well). This was btw. the reason why i've asked how the probes values get applied and then i found the Renderer.SetMaterialBlock method. Using a cubemap, as far as i can see, you'd have to create a separate material for each object using the cubemap light probes and it would have a waaaaaaaay larger performance hit. Of course it's possible, but the benefit would probably be to small to justify it.

 

i think u guys are overcomplicating my idea... forget the probes themselves for the cubemapping part... i just basically said fake a specular highlight by making an all black cubemap with a couple of blinn or phong shines in it... an image based highlight if u will.. May not be accurate, but its better then nothing.


by the way.... any word on that shader from shadow gun? lightprobes are cool and all, but i mean seriously whats the point if u cant utilize your normal maps with them on?

 

It's not that you can't. You can. There just isn't a shader that comes with unity that does it.

(although, I wonder, why isn't there one built in? I mean even the one robert posted a few pages back would be fine and there would be less complaining all around)

 

@robert : Done, Case 438105
and there's a typo on it, sorry it's 2 am here.

 

hmm... i saw a package on the asset store that, and correct me if im wrong, does light probes... with normal maps and spec... and even has realtime shadows working with the lightprobes and all that on...

The only problem is it says not supported for mobile.

There light probe system also seems to have much more features. I think unity team just got outdone by their own community... lol

http://forum.unity3d.com/threads/116129-ShaderBox?highlight=shaderbox

theres the link... so correct me if im wrong, but this seems to be everything that people want.

 

Which is?

 

Well... from what ive been reading ..

1.)being able to control the colors of the probes themselves.. not just baking them.

2.)The realtime shadows working with them..

3.) the normal maps working with them... (spec.. dont know for certain, but from reading their pdf file it seems like it does have in fact have it.. along with a bunch of other features in the shader for it.)

4.) Tools to layout the probes automatically. (Which i dont really care about but seems like a really nifty feature.)

 

I dont know if the issue was commented on, but here is what dual mapping does with unitys probes.... the next image is a comparison of with the probes and without em... perhaps there was a workaround.. could have sworn i read one somewhere. Notice how with the probes the object utilizing the probes changes colors to be way darker and not match up.

Now that i really look at it ... the probes for the directional light mapping makes the object super dark compared to the baked lightmapped... check out screenshot #2 for that one...

Really at this point im not even sure im using these light probes as unity intended. I mean it was my impression that these things in a way would replace the lighting information from lights. And if not that contribute to ambience to the model when reacting with real lights. In which case i would not know how to set that one up with this pipeline since the lights sort of get disabled on bake... would be difficult. Perhaps you guys only intended for us to use lightprobes in dual light mapping mode with a super far shadow distance.

 

Aside from that ill see what i can do about the shader and your code example, but im no shader writer... im lost the moment i open it.

 

Now that i have been messing around with it.. i think the best workaround for unitys probes and directional lightmap is baking the scene with directional, switching to single light map... baking the probes with single lightmaps, then switching the mode back to directional lightmaps...

 

Here is my current BumpSpecProbed shader, you'll have to play around with the three Probe Spec parameters till you get a nice specular effect from the probe light.

 

@Zomby138 hell yea dude you are the man!

 

Glad to help

 

The lightprobes are awesome! And Zomby138 thanks for the shader, it's great! I'm kind of going about this a little backwards, I'm generating lightmaps as EXR's in Houdini, then bringing them into Unity through the lightmapper interface. But in order to bake the probes to fill them with any values that work, I have to plug the lightmap EXR image into an emissive material, assign that to my object, bake the probes, then return to my original material. Once the probes are baked with the emission, they work on other objects in the scene. Is this the way I have to do it if I bake my lightmaps elsewhere?

Sequence is as follows:
Lighting the probes with a self-illum shader with the lightmap as texture:


Room object returned to diffuse shader/lighmapping, not using probes. The crate is using the probes.


Here's the crate close up:


This is probably a really roundabout way to do things, I know, but it sort of works.

 

I was wondering about something related to the probe data too. It seems kind of hard to see which probedata file a probe component refers to. And sometimes this causes mixups.

We have a couple of levels in our game, and sometimes we have to branch a level off for testing. Or maybe we just need a duplicate to create a variation of the same level. However, when duplicating a level (or saving it with a new name), it seems that the probe data in the scene still points to the same file as the original level. Making any bakes apply to both the new and the old level. Which is a problem when the new level has dramatically different lighting, and we'd rather not have to recreate the probes for the entire level, when it's for the most part the same.

Is there any way we can force a probe system to write to a new data file?

 

Thanks, it's working now! Though with some modifications.

It seems that it doesn't automatically refer to a new lightprobe asset file when saving a new scene. When saving to a new scene in a new folder it will still default bake to the lightprobe asset from the previous scene, we can see it's still referred to under Lightmapping - Maps. If we set the lightprobe asset to None before baking in the new scene, we get a new lightprobe asset file created with the scene-name and placement etc.

 

Robert, thanks for your response.

I'm still exploring the abilities of Houdini's UV rendering implementation, but I believe it's possible to fill the unused space with something other than zero.

At the moment, I can export light position, direction, FOV, color, and intensity to Unity, so that's not a problem. I don't mind baking the probes with direct light from Unity, but I'm trying to achieve as close to 1:1 between Houdini/Mantra and Unity as I can.

Also, am I limited to Beast's light probe functionality or if I have my own method, can I write light probe information to a file usable in Unity?

 

Is there any plan to make the process of baking light probes with custom light maps(not beast) easier in unity 3.5 or future releases?
Would be good if the "hack" that Stjohn909 suggested could be implemented properly in unity instead leaving it open for the user to create their own process, or most likely wait for someone to release a tool on Asset Store.

Is the workflow with custom light maps fully considered by unity, or is it just a consequence of the beast workflow?

 

Is there a way to create new light probes in runtime?

PS
After messing around for a while, I guess the answer is no, and even if it were yes, it might be not a good idea because of performance.

 

Quick Question. Is the lightprobe use the ambient light value?

Edit: it's a yes, weird is there any ways to make the lightprobe not affected by theAmbient light? It's make the character brighter than the environment.

 

Hello all! *waves*

I just wanted to chime in really quick and mention another way of getting specular lighting with SH as a simpler alternative to Zomby138's shader. MK vs DC Mortal Kombat 9 both used a method where they basically had the view direction act as a specular-only directional light (ie. pow(dotNE, specularPower)). They then colored the light using the diffuse ambient lighting sampled from their SH probes. Finally, they used standard material parameters for adjusting the lighting (ie. specular color power).

Sadly, their technique has some limitations, as it has a limited range of specular powers before the highlight becomes too small and kills the effect. As a result, their system doesn't integrate nicely with dynamic local lights that have proper specular. Finally, it works better for round objects and normal maps with rounded details, and is much less effect for largely flat surfaces.

Bottom line, it is dirt simple and dirt cheap if all you want to do is add a glossy effect for a system dominated by ambient lighting.